跳转至

Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore

Ch11.128 Control where your AI agents can browse with Chrome enterprise policies on Amazon Bedrock AgentCore

📊 Level ⭐⭐ | 8.2KB | entities/control-where-your-ai-agents-can-browse-with-chrome-enterprise-policies-on-amazo.md

来源:原文存档

核心要点

  • AWS China ML 发布的技术文章,介绍 Amazon Bedrock AgentCore Browser 的 Chrome 企业策略控制能力
  • 三大能力:URL 白名单/黑名单、禁用危险浏览器功能(密码管理器、下载等)、将策略管理与 Agent 开发解耦
  • 支持自定义根 CA 证书,解决内部服务使用私有 PKI 的连接问题
  • 架构通过 S3 存储策略 JSON + Secrets Manager 管理证书,实现声明式配置

深度分析

AI Agent 浏览器控制的必要性

AI Agent 获得 web 浏览能力后,安全边界变得模糊。传统网络安全边界无法覆盖 AI Agent 的动态行为——Agent 可能根据 prompt 导航到未授权域名、在浏览器中存储凭据、或下载恶意文件。Chrome Enterprise Policies 提供了一种独立于 Agent 逻辑的防御层。

两层策略架构

Managed Policies(管理策略)

  • 存储在 S3,通过 CreateBrowser API 配置
  • 映射到 Chrome 的 /etc/chromium/policies/managed/
  • 不可被会话级设置覆盖
  • 适用于安全团队定义的全局锁定策略 Recommended Policies(推荐策略)

  • 通过 StartBrowserSession API 在会话启动时传入

  • 映射到 /etc/chromium/policies/recommended/
  • 可作为用户偏好设置
  • 当与 Managed Policy 冲突时,Managed Policy 优先 这种分层设计允许安全团队和开发团队独立运作——前者负责锁定环境,后者专注于 Agent 逻辑。

自定义根 CA 的实际价值

企业内部服务或 SSL 拦截代理使用的证书通常由私有 CA 签发,默认情况下浏览器不信任这些 CA。传统解决方案是禁用证书验证,但这会引入安全风险。 AgentCore 的方案是将组织根 CA 存储在 AWS Secrets Manager,引用时自动导入 Chrome 信任存储。无需修改代码或禁用验证,即可实现安全连接。

策略配置的工程实践

文章中的 notebook 示例展示了典型工作流: 1. 定义策略 JSON(URLBlocklist + URLAllowlist 实现白名单) 2. 存储策略文件到 S3 3. 创建 Browser 时引用 S3 位置 4. 启用会话录制用于审计 关键细节:DeveloperToolsAvailability 必须设置为 0(或省略)才能使用 Playwright/CDP 自动化——设置为 2 会禁用 CDP,导致静默失败。

实践启示

  1. 在设计 AI Browser Agent 时,策略控制应是架构决策而非事后补丁:在 Agent 层面限制 URL 即使被 prompt 注入绕过,浏览器层面的策略仍能提供保护。两者结合实现纵深防御。
  2. 推荐使用白名单而非黑名单模式:AI Agent 的行为空间巨大,黑名单难以覆盖所有风险场景。白名单(URLBlocklist=["*"] + URLAllowlist=[特定域名])提供更可预测的安全边界。
  3. 浏览器策略应与 CI/CD 流程集成:策略 JSON 存储在 S3,可通过版本控制管理,配合 AWS IAM 最小权限原则,确保只有安全团队能修改策略配置。
  4. 私有 PKI 场景下,Secrets Manager + AgentCore 是标准方案:不要为了"方便"而禁用证书验证。通过组织根 CA 导入实现安全连接是正确路径,且配置一次即可在多个 Agent 间复用。
  5. 会话录制是审计 AI Agent 行为的重要工具:当 Agent 执行敏感操作时,录制的会话可用于事后分析、异常检测和合规审计。 → 原文存档

相关实体