很多团队谈 AI Agent 安全时，习惯先问“这里有没有一个严重漏洞”。这个问法不算错，但它很容易把风险看扁。真正让系统失控的，往往不是某一个点单独失败，而是两三道原本被当成彼此独立的边界，在默认配置里刚好能串成一条链。
今天看到 Unit 42 关于 AWS Bedrock AgentCore 的两篇分析，我觉得最有价值的地方就在这里：一边是 sandbox 网络隔离被绕过，另一边是 IAM 权限过宽带来的高影响后果。单看任何一边，都可能被解释成“实现细节还可以继续优化”；但一旦把它们放在同一个攻击路径里，问题就变了。运行时不该到达的地方能到达，身份不该拿到的权限又真的拿到了，那系统就不是在某一层防得不够严，而是在整体上默认相信了太多本不该同时成立的前提。
这也是我越来越在意“组合边界”而不是“单点控制”的原因。过去几天本地关于 browser attach、tab discovery 和写操作边界的笔记，反复指向同一个结论：不要把不可信输入、已登录上下文、跨 origin 导航和外部副作用放进同一个长生命周期环境里。很多人以为风险只出现在最后一次发送、删除、改权限时，但实际上，前面只要先把上下文读进来、把权限接上去、再让任务跨边界漂移，后面的高影响动作就只是时间问题。
云上 Agent runtime 和浏览器 Agent，看起来是两种不同系统，底层问题却很像。一个是在 sandbox 和 IAM 之间出了组合链，一个是在 attach、标签页枚举、登录态复用和写动作之间出了组合链。它们都说明：边界不能按产品模块分开自我安慰，而要按真实攻击路径来设计。
如果要给工程团队一个更实用的默认建议，我会强调四件事。第一，先按任务链路画边界，不要只按组件画。第二，运行时隔离和身份权限必须同时做最小化，不能指望另一层兜底。第三，把高权限模式显式化，比如 attach 登录态、访问敏感 origin、执行写操作，都应该被当成特权升级。第四，所有对外写动作都要有写前预览和写后回读，不让系统在过度授权的上下文里静默完成闭环。
Agent 安全真正难的，不是承认某个点会失败，而是承认系统通常会沿着“边界组合失效”的方式出事。谁先按链路设计控制面，谁才更可能把能力真正带进生产环境。