AI Agent 正从“生成内容”走向“代替员工操作网页”：它可以跨多个 SaaS 页面检索信息、整理文档、核对发票，甚至在业务系统中创建记录。企业因此面临一个新的安全问题：当人的身份与自动化执行混合在一起时，如何确保 Agent 只能访问必要的数据，并且不能在不知情的情况下完成高风险操作？
Chrome Enterprise 的思路是把浏览器作为 Agent 与企业系统协作的安全边界。浏览器已经掌握员工的登录身份、打开的标签页、正在使用的 SaaS 应用以及组织下发的访问策略，因此可以在 Agent 执行任务时同时提供上下文和控制能力。
为什么浏览器适合承载 Agent 工作流
企业的大部分工作仍然发生在 Web 上。招聘人员可能需要从公开职业资料中筛选候选人，再把结果写入在线 ATS；财务和运营团队则可能需要登录多个供应商门户，下载 PDF 发票并完成核对。
这类任务的共同特点是：
- Agent 需要跨多个网站执行连续操作。
- 操作依赖员工已经拥有的企业身份和权限。
- 数据可能同时来自内部文档、CRM、公共网站和外部 AI 服务。
- 某些步骤可以自动完成，但提交合同、付款或群发邮件等动作必须由人确认。
如果 Agent 脱离浏览器单独运行，IT 团队很难判断它看到了哪些页面、使用了什么权限，以及数据最终流向了哪里。将 Agent 锚定在浏览器中，则可以复用现有的身份认证、访问控制、扩展管理、历史记录和数据保护策略。
这并不意味着“浏览器内运行”天然安全。Agent 仍可能被页面中的恶意内容诱导，也可能因为扩展权限过大而抓取不相关的 DOM 数据。因此，浏览器需要对 Agent 的数据流和动作边界提供持续控制。
企业级控制：DLP、扩展和上下文权限
Chrome Enterprise Premium 将数据丢失防护能力延伸到 Agent 工作流中。传统 DLP 主要关注员工主动执行的复制、上传或粘贴动作；在 Agentic Browsing 场景下，策略还需要检查自动化任务是否把敏感知识产权、个人信息或财务数据传输给公共 LLM 或其他未经批准的服务。
扩展控制同样关键。浏览器扩展可能拥有读取页面内容、访问多个站点或修改网页的权限。对于 Agent 相关扩展，企业需要了解它们如何访问和处理敏感数据，并识别可能导致未授权 DOM 抓取的风险信号。
更重要的是，Agent 不应获得超出员工本人的权限。可以将这一原则概括为：
员工没有权限访问或导出数据时，其 Agent 也不能访问或导出这些数据。
实际落地时，授权判断不能只看用户是否已经登录，还要结合目标站点、数据类型、操作类型和任务目的。例如，员工可能可以查看客户记录，但没有权限批量导出；Agent 可以帮助总结单个客户页面，却不应该把整个 CRM 数据集提交给外部模型。
三层防线：限制意图、限制来源、保留人工控制
面向 Agentic Browsing 的防护需要分层设计，而不是依赖单一的提示词过滤器。
1. 用高信任模型检查动作是否符合用户意图
Chrome auto browse 的 User Alignment Critic 可以作为独立的安全门。它不需要重新理解所有页面内容，而是分析拟执行动作的元数据，并判断动作是否仍然符合用户最初的目标。
如果页面中的间接提示注入试图改变 Agent 的任务，例如要求它忽略原始指令、访问无关的登录站点，或把秘密信息发送到外部地址，Critic 可以否决这一步动作。
这种设计的价值在于把“页面告诉 Agent 做什么”和“用户真正要求 Agent 做什么”分开处理。页面内容可以提供业务信息，却不应自动获得改变任务边界的权力。
2. 通过站点隔离限制 Agent 的活动范围
Chrome 的 Site Isolation 是浏览器安全的重要基础。针对 Agent 场景，活动范围还需要进一步收缩到与当前任务直接相关的 origin。
例如，用户要求 Agent 在供应商门户下载发票并写入内部采购系统，那么 Agent 的允许范围可以只包含：
- 指定的供应商门户。
- 企业采购系统。
- 用于保存结果的受控内部文档服务。
即使 Agent 被某个页面内容诱导，也不应因此获得访问其他已登录站点的自由。限制 origin 能够降低被攻陷 Agent 横向操作无关系统的风险。
3. 在关键节点暂停并要求明确批准
Agent 的工作日志应当让员工看到它做了什么、为什么这样做，以及下一步准备提交什么。Chrome auto browse 会在关键节点暂停，例如最终确认合同、提交财务交易或执行群发邮件。
人工审批不应只是一个形式上的“继续”按钮。审批界面至少应展示目标系统、即将提交的数据、影响范围和不可逆后果。Chrome History 也可以明确标记由 Agent 在后台访问的页面，让员工和安全团队能够区分人工浏览与自动化操作。
一个可改造的策略示例
下面是一个与浏览器 Agent 配合使用的简化策略示例。它不是 Chrome Enterprise 的官方配置格式，而是用于说明企业可以如何把任务范围、数据分类和人工审批条件写入策略系统。运行前可以将 allowed_origins、敏感字段和审批规则替换为组织的实际配置。
agent_policy:
name: reconcile_vendor_invoices
user_goal: "从指定供应商门户下载本月发票，并写入采购系统"
allowed_origins:
- "https://billing.example-vendor.com"
- "https://procurement.corp.example"
blocked_actions:
- "navigate_to_unrelated_logged_in_site"
- "upload_sensitive_data_to_public_llm"
- "scrape_full_dom_without_task_need"
data_controls:
block_upload_categories:
- "intellectual_property"
- "personal_data"
- "financial_data"
redact_before_external_processing: true
human_approval_required:
- "create_payment"
- "submit_financial_transaction"
- "send_external_email"
audit:
record_agent_pages: true
record_action_metadata: true
show_work_log: true
对应的工程实现可以从动作网关开始：每个浏览器动作先经过 origin、数据分类和风险等级检查，再决定是允许、阻断还是暂停等待人工批准。
from dataclasses import dataclass
from urllib.parse import urlparse
@dataclass
class Action:
url: str
kind: str
data_categories: set[str]
ALLOWED_ORIGINS = {
"billing.example-vendor.com",
"procurement.corp.example",
}
HIGH_RISK_ACTIONS = {
"create_payment",
"submit_financial_transaction",
"send_external_email",
}
BLOCKED_CATEGORIES = {
"intellectual_property",
"personal_data",
"financial_data",
}
def evaluate(action: Action) -> str:
origin = urlparse(action.url).netloc
if origin not in ALLOWED_ORIGINS:
return "block: origin is outside the task boundary"
if action.data_categories & BLOCKED_CATEGORIES:
return "block: sensitive data requires an approved handling path"
if action.kind in HIGH_RISK_ACTIONS:
return "pause: explicit human approval required"
return "allow"
print(evaluate(Action(
url="https://procurement.corp.example/invoices",
kind="create_payment",
data_categories=set(),
)))
这个示例只演示决策逻辑，生产环境还需要把它接入浏览器自动化框架、企业身份系统、DLP 引擎和不可篡改的审计日志。尤其要避免只在客户端隐藏按钮；真正的授权检查必须在服务端或受控的动作执行层再次验证。
安全能力还需要持续验证
Agent 安全边界会随着模型能力、浏览器功能和企业应用变化而变化。自动化机器学习红队系统可以持续构造间接提示注入、恶意页面和越权导航等合成威胁，验证防护是否仍然有效。
漏洞奖励计划也需要覆盖 Agent 的新攻击面。研究人员可能发现的并不只是传统浏览器漏洞，还包括 Agent 绕过 origin 限制、诱导高风险提交、读取不相关页面或泄露敏感数据的路径。持续测试和外部研究反馈，是验证设计假设的重要手段。
企业采用时的检查清单
部署浏览器 Agent 前，可以从以下问题开始：
- 是否明确区分用户身份、Agent 身份和具体任务上下文？
- 是否为每个任务限定允许访问的 origin，而不是默认开放所有已登录站点？
- 是否对复制、上传、跨站传输和提交动作应用 DLP？
- 是否限制 Agent 扩展的读取、脚本注入和跨站权限？
- 是否在付款、合同、群发邮件等不可逆动作前要求人工批准？
- 是否记录 Agent 访问过的页面、动作元数据和最终结果？
- 是否定期用提示注入和越权场景进行自动化红队测试？
浏览器可以成为 Agent 的高效工作台，但前提是它同时承担执行边界和安全执行器的角色。身份、站点隔离、实时 DLP、透明日志与人工审批结合起来，企业才能在提升自动化效率的同时保留必要的可见性和控制力。