Anthropic Agent隔离架构解读：比权限弹窗更可靠的是限制爆炸半径
摘要
Anthropic Engineering 在 2026 年 5 月发布的《How we contain Claude across products》中，系统复盘了 claude.ai、Claude Code 与 Claude Cowork 三类 Agent 产品的隔离架构。文章的核心判断很直接：Agent 越能干，它潜在的爆炸半径就越大；仅靠模型"听话"或用户频繁点权限弹窗，无法构成可靠安全边界。
对研发团队来说，这篇文章的价值不只是安全案例，而是给出了 Agent 产品工程化的一个分层方法：环境层先限制能做什么，模型层再引导应该做什么，外部内容层负责阻断工具返回和文件内容中的注入。本文结合该文和 Claude Code auto mode 文章，拆解其中对 AI Agent 平台研发最有参考价值的设计取舍。
背景：为什么权限弹窗不是长期答案
早期编码 Agent 常用的安全模型是 human-in-the-loop：读操作默认允许，写文件、执行命令、访问网络前询问用户。这个模型容易理解，也很适合开发者工具的早期形态。但 Anthropic 给出的数据说明了它的瓶颈：Claude Code 用户会批准大约 93% 的权限请求。请求越多，用户越容易进入审批疲劳，弹窗从安全机制变成流程噪音。
这不是用户不负责，而是交互模型本身有问题。一个强 Agent 会连续执行几十步任务，让用户逐条判断每个 bash 命令、网络请求和文件修改，现实中不可持续。更关键的是，一旦攻击通过用户本人进入，例如"帮我运行这段协作提示词"，模型层很难把它识别为异常。Anthropic 文章提到，在一次内部红队测试中，恶意提示通过用户输入进入，要求读取本地凭据并外传，模型多次完成了该动作。这个案例说明，用户意图本身并不总是可信边界。
因此，安全问题要从"是否批准这一步"上移到"这一步即使被批准，最多能造成多大损害"。这就是 containment 的工程意义。
技术要点：三类风险与三层防御
Anthropic 将 Agent 风险分成三类：用户误用或恶意使用、模型误行为、外部攻击者通过文件、工具或网络内容注入。这个分类对研发团队很实用，因为它避免把所有问题都归因于"模型不够安全"。很多失败并不是模型单点问题，而是运行时给了模型过大的权限。
对应的防御也分三层。
第一层是环境。包括进程沙箱、虚拟机、文件系统边界、网络出口控制、凭据隔离。它回答的是：Agent 物理上能访问什么。Anthropic 明确强调，如果凭据从不进入 sandbox，即便用户、模型或攻击者触发了错误路径，也无法被 exfiltrate。
第二层是模型。包括系统提示、分类器、探针、训练改进等。它能降低错误概率，但无法提供确定性保证。Claude Code auto mode 就是典型例子：它用分类器自动处理部分命令审批，减少用户审批疲劳，但本质上仍然是概率防线，不能替代环境隔离。
第三层是外部内容。MCP server、插件、网页、GitHub README、项目配置文件都可能把不可信内容送进 Agent 上下文。传统供应链审计只能检查代码是否恶意，不能保证工具返回的文本不会诱导模型越权。因此，工具输出也必须被当成攻击面处理。
三种隔离模式：按产品能力匹配边界强度
claude.ai 的代码执行采用临时容器模式。代码运行在服务端隔离环境中，文件系统按会话临时存在，不访问用户本机。这个模式爆炸半径小，适合通用聊天和轻量代码执行，但能力上限也明显：没有持久 workspace，也不能直接操作用户本地项目。
Claude Code 面向开发者，本质上需要访问本地文件、shell 和网络，否则无法完成真实编码任务。它最初依赖用户审批，后来引入 OS 级 sandbox：macOS 使用 Seatbelt，Linux 使用 bubblewrap，默认允许读，允许在 workspace 内写，网络默认拒绝。Anthropic 称这带来了 84% 的权限提示减少，并开源了 runtime，使边界更可审计。这里的关键取舍是：开发者有能力理解部分 bash 风险，所以可以保留一定人工监督，但必须用 sandbox 降低每次判断失败的后果。
Claude Cowork 面向更通用的知识工作场景，用户未必能理解命令风险，因此采用更强的本地 VM 隔离。VM 有独立内核、文件系统和进程表，只挂载用户选择的 workspace 和必要目录；凭据留在宿主机 keychain，不进入 guest。后续 Anthropic 又把 agent loop 移出 VM，只把代码执行放在 VM 中，以提升可用性。这说明安全架构不是越封闭越好，还要处理启动失败、调试、可观测性等工程问题。
研发视角：真正危险的是"边界前"的代码
文章中最值得研发团队警惕的一个细节，是 Claude Code 曾收到过"trust dialog 之前"的漏洞报告。用户尚未信任项目目录时，本地项目配置就被读取或解析，攻击者可以把恶意 hook 放进仓库配置中，在用户确认之前触发执行。
这类问题在 Agent 产品中很常见：项目打开、配置加载、本地服务发现、插件初始化，看起来都是"启动流程"，但从安全角度看，它们已经在处理不可信输入。正确设计应该是：在用户明确接受信任边界之前，不解析会执行代码的配置，不启动项目本地 hook，不把目录中的指令性文本送进模型上下文。
另一个关键点是 egress allowlist 不能只理解成"允许访问这些域名"。Anthropic 复盘了一个场景：允许访问 api.anthropic.com 看似合理，因为产品自身需要调用 API；但如果恶意文件诱导 Agent 使用攻击者的 API key 上传文件，目的域名仍然是允许域名，数据却流向攻击者账号。Anthropic 后续用 VM 内的防御代理校验请求 token 和 provenance。这给研发团队的启示是：出口控制要看能力和身份，而不只是域名。
实践建议：构建 Agent 产品的安全清单
第一，把用户类型纳入威胁模型。面向开发者的工具可以让用户理解部分命令风险；面向普通知识工作者的产品不能假设用户能判断 shell 命令。隔离强度要随用户能力变化，而不是随产品团队偏好变化。
第二，默认把 workspace 之外的文件视为不可达。凭据目录、SSH key、云厂商配置、浏览器数据、系统 keychain 都不应进入 Agent 执行环境。需要访问时，应通过短期、可撤销、范围受限的 token 暴露能力，而不是挂载真实凭据。
第三，网络出口要从"域名 allowlist"升级为"能力 allowlist"。允许访问某个域名，等价于允许该域名下所有 API 能力。对文件上传、服务端转发、外部 webhook、任意账号 token，应做更细粒度校验。
第四，工具输出进入模型上下文前要检查。MCP、连接器和网页检索不是纯数据通道，它们会把文本指令注入模型上下文。对高风险工具返回值，可以用小模型或规则层先做扫描，再决定是否传给主 Agent。
第五，持久记忆要有启动时扫描。CLAUDE.md、项目记忆、长期任务状态目录、定时 Agent 的缓存，都可能成为持久注入点。Agent 每次启动时，不应无条件信任上一轮遗留文本。
风险与限制
Containment 不是零风险方案。沙箱和 VM 会带来性能、可观测性、调试和企业合规问题。Anthropic 也提到，VM 隔离会让主机侧 EDR 难以看见 guest 内部活动，需要额外日志导出能力。隔离越强，产品体验和运维复杂度越高。
另外，本文只基于 Anthropic Engineering 公开文章做工程解读，没有使用其文中外链作为事实来源。不同企业的 Agent 产品还需要结合自身数据敏感度、部署环境、合规要求和用户能力重新建模。
参考来源
- Anthropic Engineering - How we contain Claude across products: https://www.anthropic.com/engineering/how-we-contain-claude
- Anthropic Engineering - How we built Claude Code auto mode: https://www.anthropic.com/engineering/claude-code-auto-mode