0. 核心观点
浏览器 Agent 的安全难点不在于“能不能识别恶意网页”，而在于网页内容、用户会话和自动化动作被放进了同一个决策回路。传统浏览器假设用户读页面、用户点按钮；Agentic browser 则让模型读页面、模型决定下一步、工具执行点击或输入。只要网页能影响模型，它就可能间接影响用户已登录会话中的动作。
因此，浏览器 Agent 的核心边界应是：网页内容永远是不可信输入，用户会话永远是高价值资产，模型计划永远不能直接等价于用户授权。
1. 风险为什么被放大
浏览器自动化把三种能力叠加在一起：读取网页、访问登录态、执行 UI 动作。间接提示词注入利用的正是这个组合。攻击内容不需要突破浏览器沙箱，只要被 Agent 读取并进入上下文，就可能诱导模型改变目标、泄露页面内容、点击危险按钮或把私有数据发往外部服务。
2. 四个必须分开的边界
| 边界 | 不能混淆的对象 | 推荐控制 |
|---|---|---|
| 内容边界 | 页面文本与系统指令 | untrusted 标记、内容摘要隔离、引用证据 |
| 身份边界 | Agent 身份与用户身份 | 独立代理账号、最小权限、会话分区 |
| 动作边界 | 浏览、填表、提交、支付、删除 | 动作分级、显式确认、幂等保护 |
| 数据边界 | 当前页面、剪贴板、下载文件、外部 API | DLP、域名 allowlist、外发审计 |
最危险的设计是让 Agent 使用用户主浏览器、继承全部 Cookie、同时具备任意网页读取和任意表单提交能力。这不是“智能浏览器”，而是把用户的登录态暴露给一个会被网页文本影响的执行器。
3. 工程化设计
建议采用三层隔离：专用浏览器 profile、代理身份、动作网关。专用 profile 限制 Cookie 与扩展；代理身份避免直接继承用户最高权限；动作网关将点击、输入、下载、上传、提交按风险等级处理。
browser_agent_policy:
session:
profile: isolated-agent-profile
inherit_user_cookies: false
navigation:
allowed_domains:
- docs.example.com
- console.example.com
actions:
read_page: allow
fill_form: require_review
submit_form: require_user_confirm
download_file: scan_then_allow
external_upload: deny_by_default
audit:
capture_dom_snapshot: true
capture_screenshot_on_high_risk_action: true| 动作等级 | 示例 | 默认策略 | 必须留存的证据 |
|---|---|---|---|
| L0 只读 | 打开页面、搜索、读取公开文档 | 自动执行 | URL、页面摘要、时间戳 |
| L1 草稿 | 填表但不提交、生成回复草稿 | 沙箱/隔离 profile 执行 | DOM diff、截图、字段列表 |
| L2 状态变更 | 提交表单、创建资源、删除记录 | 用户确认 | 确认人、前后 diff、目标域名 |
| L3 外发敏感数据 | 上传文件、发送私密内容到第三方 | 默认拒绝 | 拒绝原因、数据分类、审批工单 |
4. Windows 测试机边界：能验证浏览器能力，不等于拥有沙箱
本地 Windows 节点 DESKTOP-HT6EO5E 当前可用于浏览器/系统能力验证，但它不是浏览器 Agent 安全性的“证明环境”。实测基线如下：
OS: Microsoft Windows 10 Pro for Workstations 10.0.19045 / build 19045
PowerShell: 5.1.19041.6456
Node capability: browser, screen, system 可用
OpenClaw Node Sandbox: unavailable / commands run uncontained因此，使用这台机器做浏览器 Agent 文章时，只能把证据写成两类：
| 可验证对象 | 可以写进文章的证据 | 不能外推的结论 |
|---|---|---|
| profile/context 隔离 | 不同 profile 的 Cookie、localStorage、下载目录差异 | 不能证明宿主命令被沙箱隔离 |
| 高风险动作留痕 | DOM 快照、截图、URL、动作 diff | 不能证明网页内容一定无法影响模型 |
| Windows 系统边界 | OS build、Sandbox unavailable、命令 uncontained | 不能当作生产安全基线 |
这反而是一个很好的工程提醒：文章里如果展示 Windows 截图或命令输出，必须同时写清楚“这是宿主机无沙箱实测证据”，不要把浏览器 profile 隔离误写成系统级隔离。
5. 图文一致的动作分级
动作分级的价值不只是防误操作，也是在审计中还原“Agent 看到了什么、准备做什么、用户确认了什么”。没有截图、DOM 快照和动作差异，事后很难判断事故来自网页注入、模型误判还是用户授权误解。
6. 风险与安全边界
浏览器 Agent 不能把提示词防护视为唯一安全措施。模型可以被训练得更谨慎，但网页内容的多样性、DOM 的动态变化、第三方脚本和跨站跳转都会持续制造不确定性。真正可靠的是能力约束：少继承会话、少给写权限、少允许外发、关键动作必须有人类确认。
对于企业场景，还应将浏览器 Agent 放入可观测环境：记录导航链路、域名、页面摘要、文件哈希、动作序列和确认人。高风险页面可以用只读抓取替代真实会话访问，或者用一次性受限账号完成任务。
结论
浏览器 Agent 的安全隔离不是『用个隔离浏览器就够了』。页面内容必须被标记为不可信，写操作必须有独立审批，下载文件必须过扫描区，登录态必须按任务隔离。这些控制不是可选增强，而是浏览器 Agent 进入生产环境的最小安全基线。
