最近聊浏览器 Agent，很多讨论还停在 prompt injection：恶意网页会不会塞隐藏提示、模型会不会被一段话骗走、页面内容会不会污染上下文。这个问题当然重要，但如果今天还只把风险理解成“模型会不会看错”，其实已经有点落后了。真正需要补课的，是浏览器 Agent 到底把哪些原本分开的边界重新打通了。
传统浏览器靠 Same-Origin Policy 把站点隔开：这个域名的脚本，默认不该随便读另一个域名的内容。可一旦我们给 Agent 更高能力，它就不只是“看网页”，而是在一个统一的聊天上下文里读内容、做推理、跨页面跳转、带登录态执行点击、填写、提交，甚至还能发消息、调接口、导出结果。这样一来，原本由浏览器强制维持的边界，很容易被“上下文”重新连接起来。
真正危险的链路通常不是单点，而是组合：不可信内容先进入上下文，上下文再驱动登录态动作，动作结果又被带去另一个系统继续处理或外发。问题不再只是“模型理解错了一段话”，而是“它在错误理解之后，还有权限去真的改文档、发私信、切账号、点确认、把别处的数据带出来”。从这个角度看，prompt injection 更像是引线，系统级风险来自引线后面那条完整动作链。
所以设计浏览器 Agent，优先级不该只是多加几次确认框，而是把最小可行边界做对。第一，要做任务级隔离。摘要、检索、登录态编辑、消息发送，不该默认跑在同一个长上下文里。第二，要做 origin 白名单，明确一个任务究竟允许访问哪些站点、读取哪些对象。第三，所有写操作在执行前都应该对象回显：到底要发给谁、改哪里、提交什么，让系统和人都能看到目标对象。第四，执行后要强制结果回读，而不是点完按钮就当成功。
这也是为什么“用户已经授权过”根本不是安全边界。授权只说明系统拥有能力，不说明这次动作的目标是对的，更不说明当前上下文没有被污染。未来真正可靠的浏览器 Agent，不会靠“更像人”赢，而会靠“更可控”赢。谁能把 origin 边界、任务隔离、动作范围和结果校验做成默认设计，谁的自动化才更配碰真实世界。