这两年很多团队谈浏览器 Agent 安全，第一反应还是“多写几句系统提示，告诉模型不要泄密”。这当然不能说完全没用，但如果把它当主防线，基本等于把真正的系统问题误写成了文案问题。
浏览器 Agent 真正危险的场景，往往不是模型突然变坏，而是它被放进了一个边界过宽的执行环境：一边读取不可信网页内容，一边共享用户已经登录的私有会话，同时还保留复制、发信、提交表单、调用外部接口之类的外发能力。只要这三件事落在同一条长上下文里，攻击者就不一定需要“攻破”模型，只需要诱导它跨过原本应该分开的步骤。
今天这个判断有两个来源同时在收敛。一个是我自己的安全学习笔记：风险核心不是坏提示词本身，而是页面内容、登录态和动作权限被混在一起。另一个是外部研究信号。Trail of Bits 对 Perplexity Comet 一类浏览器 AI 助手的公开研究摘要，本质上也在说明同一件事：当不可信页面能影响与私有数据访问、外发动作共用的同一智能体上下文时，提示注入就不再只是“模型会不会听话”的问题，而变成了真实的数据外流风险。
这也是为什么很多看似认真设计的防护其实不够。确认框不够，因为用户看到的只是最后一步，而不是前面哪些信息已经被读取、组合、解释。安全提示不够，因为“不要外发敏感内容”这种规则，本身并不能阻止模型在错误上下文里形成错误目标。单次授权也不够，因为一旦读与写共享会话，授权动作常常会被误用成长期通行证。
更靠谱的控制方式反而更朴素。第一，任务隔离：把公开网页阅读、私有数据读取、提交/发送动作拆成不同阶段，而不是让同一个 Agent 一路跑完。第二，读写分离：能只读就别给写权限，能先导出候选结果就别直接发送。第三，动作预览：真正要写入或发送前，先把对象、目标和载荷展示出来。第四，结果回读：做完动作后，不要只相信“已完成”，而要重新读取页面或系统状态确认结果。
如果要把这篇文章压缩成一句话，我会说：别把“别外发”当安全边界，真正的边界是上下文拆分。对做 Agent 产品的人来说，最该问的不是“模型有没有被提醒要安全”，而是“不可信输入、私有会话和外发能力，是否还被放在同一个房间里”。