最近大家聊 Agentic Browser，很容易把注意力全压在 prompt injection 上：网页会不会骗模型、隐藏文本会不会污染上下文、页面里的恶意提示会不会把 Agent 带偏。这个问题当然重要，但如果只盯着 injection，本质上还是把风险看小了。真正需要补课的，不只是“模型会不会被诱导”，而是整个系统默认跨越了哪些信任区。
一旦一个 browser agent 同时能读网页、带登录态、调用模型、再执行点击、填写、发送、提交这些动作，风险就不再是单点失误，而是链路组合：不可信内容先进入上下文，上下文再去驱动登录态页面里的真实动作。危险不是“看错了一段文字”，而是“看错之后还能发消息、改文档、切账号、跨站跳转甚至导出数据”。
如果把这个系统拆开看，至少有四个区：聊天/推理上下文、第三方模型或服务端、各个已登录站点的 origin，以及外部不可信网络内容。很多现在看起来“挺聪明”的 agent workflow，问题恰恰在于把这几个区默认打通了。它确实更能做事，但也更容易串味：公开网页里的内容混进推理上下文，推理上下文再去驱动带登录态的写操作，最后副作用落到用户真实账户上。
所以真正值得优先补的，不是多弹几次确认框，而是把最小可行边界补起来。第一，做任务级隔离，不要把摘要、搜索、登录态编辑、外发动作混在同一个长上下文里。第二，做 origin 白名单，明确一个任务到底允许碰哪些站点。第三，所有写动作在执行前做对象回显，至少让系统和人都能看到“将要改谁、发给谁、改哪里”。第四，执行后强制结果回读，而不是点完提交就假装成功。
这也是为什么“用户已经点过允许”远远不够。授权只能说明系统有能力做某件事，不能说明这次动作的目标对象就是对的，也不能说明当前上下文没被不可信内容污染，更不能说明后续链式动作仍然符合原意。对 agent 来说，确认更像流程信号，不是结构性边界。
如果未来 agent 真要进入日常工作流，稀缺能力不会是“更像人”，而是“更可控”。谁能把信任区、动作边界、对象范围和结果验证做成默认设计，谁的自动化才更有机会长期可用。