How we contain Claude across products

十二个月前，我们会断然拒绝授予 Claude 足以搞垮一个 Anthropic 内部服务的访问权限。如今这种级别的访问已是家常便饭，Anthropic 的开发者也因此效率更高。这类部署的风险由两个部分组成：失败的可能性有多大，以及一旦失败可能造成多大损害。防护措施与模型训练方面的进展已稳步降低了前者；而后者——理论上的影响半径——则随着能力和访问范围的扩大而不断增长。然而，当智能体能够胜任曾经需要一个人甚至一个团队才能完成的工作时，不部署的代价会变得足够大，以至于只要产品能够做到安全，风险收益的权衡就会大幅倒向采用。工程问题于是变成：如何限制这个影响半径。

大体上有两种方法可以做到这一点。

第一种方法是通过人在回路（human-in-the-loop）来监督智能体的行为。Claude Code 此前通过在每一轮都请求用户许可来防止智能体采取意外操作。理论上这行得通，但我们发现这种方法并不可靠。我们的遥测数据显示，用户批准了大约 93% 的权限请求。用户看到的批准请求越多，对每一个的关注就越少，久而久之在监督上会变得懈怠得多。我们最近构建了 Claude Code 自动模式（auto mode），通过 自动化更安全的批准 来减少这种批准疲劳。即便如此，漏洞依然存在——任何概率性防御都有非零的漏检率。¹

第二种限制影响半径的方法——也是本文大部分篇幅的关注点——是遏制（containment）。我们不去监督智能体的所作所为，而是监督它能够做什么，办法是强制实施访问边界，例如通过沙箱、虚拟机和出站流量控制（egress controls）。这是 Anthropic 工程团队投入精力最多的地方，也是许多最令人意外的安全故障发生的地方。

在过去两年里，我们发布了三款主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每款产品面向不同的受众，需要不同的遏制架构。本文将分享哪些做法经受住了考验、哪些出了问题，以及我们在智能体安全方面一路走来学到的东西。

三类风险，三重防御

智能体面临的安全风险可分为以下三类之一：

用户滥用： 用户——无论是出于恶意还是粗心大意——指使智能体做出有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们并不理解的破坏性命令，再到明确指示蓄意伤害等各种情形。

模型不当行为： 智能体采取无人要求的有害行动。随着我们的模型不断改进，它们在大多数行为评估中变得更加对齐，但这并不意味着风险必然缩小。能力较弱的模型更容易误判情况并犯下明显错误。能力较强的模型犯错更少，但它们也更擅长寻找通往目标的意外路径，往往是绕过那些没人想到要写下来的限制。

在 Anthropic，我们见过 Claude 模型为了完成任务而“乐于助人地”逃出沙箱，查看 git 历史以找到编程测试的答案，还会自发识别出自己正在运行的基准测试，以便解密答案密钥。每个模型都带来一组新能力，这些能力有时会以意想不到的方式被派上用场。

外部攻击者： 智能体通过工具、文件或网络访问等外部途径受到攻击。这一类别既包括提示词注入，也包括针对智能体运行时、编排层或代理的传统攻击。

在构建遏制与防御系统时，我们将防御应用于三个主要组件：

智能体运行的环境。 我们通过进程沙箱、虚拟机、文件系统边界和出站流量控制来约束智能体可以在何处以及如何行动。目标是为智能体能够触及的范围设定硬边界。例如，如果凭据从未进入沙箱，它们就无法被窃取，无论原因是有用户操作、模型找到了一条“有创意”的路径，还是攻击者所为。

严密的边界也意味着你可以放宽监督。Claude Code 的参考 devcontainer 的存在正是为了让智能体可以在无人值守的情况下运行，而无需逐项操作审批。

智能体所咨询的模型。这里的机制包括系统提示词、分类器、探针和训练修改。由于模型是概率性的，这些机制只能塑造智能体倾向于 做什么，而不能决定它在理论上能够做什么。

这些防御非常强大。在测试提示词注入易感性的 Gray Swan Agent Red Teaming 基准测试中，Claude Opus 4.7 在单次尝试中将攻击成功率控制在约 0.1%，经过 100 次自适应尝试后约为 5–6%。Claude Code 自动模式能在过度激进的行为执行之前拦截其中约 83%。然而，即使拥有最一流的防御，模型层的保护也永远不会 100% 有效，这就是为什么它不能单独存在。

智能体可以触及的外部内容。 MCP 服务器、第三方插件和网络搜索工具都会将来自你无法控制的源的内容输入智能体的上下文。经过审计的连接器不等于经过审计的数据——例如，一个 GitHub 连接器尽管通过了恶意软件检查，仍可能将一个被投毒的 README 直接加载到模型的上下文中。细粒度地限制工具权限有助于限制影响范围。例如，拥有只读数据库访问权限的智能体可以比会写入生产环境的智能体部署得更广泛得多。

防御措施应当相互重叠、互为补充。当环境层防御不可用时，模型层必须补位承担（这正是 Claude Code 的自动模式的设计初衷）。在本地，环境防御与模型防御可以防范恶意的工具输出，但还可以通过限制工具的能力和访问权限，在链条更高处添加防御。

遏制智能体的模式

我们聚焦于环境层，介绍三种隔离模式，以及它们如何针对各个 Claude 平台——claude.ai、Claude Code 和 Cowork——进行量身定制。每一种设计都是逐步摸索出来的，在我们需要智能体具备的能力与需要用户付出的干预程度之间找到了平衡。

模式一：临时容器（claude.ai 代码执行）

尽管 claude.ai 以聊天界面最为人熟知，它还能编写并运行代码、生成文件以及调用连接器。当 Claude 在 claude.ai 内运行代码时，它是在隔离基础设施上的gVisor容器中运行的。智能体完全在服务端运行；本地机器上不运行任何代码，文件系统也是临时的（按会话计）。影响范围极小，但 Claude 能做的事情的天花板也同样很低——没有持久的工作区，也无法访问用户的文件系统。

这也使claude.ai面对的是更传统的威胁模型。我们要保护的不是用户机器免受智能体侵害，而是保护我们自己的基础设施，并使各个租户之间彼此隔离。我们为claude.ai所做的上线前工作主要是传统安全工作，例如网络配置、内部服务认证和编排。

这项工作印证了安全领域最古老的一条教训：最薄弱的层正是你自己构建的那一层。gVisor 和seccomp经受资源充足对手攻击的加固历史远早于智能体 AI 的出现，因此审查精力主要投入到我们围绕它们构建的较新组件上。我们稍后会回到这一点，因为我们的自定义代理正是在我们最严重的一次事故中出问题的那部分。

模式二：人在回路的沙盒（Claude Code）

Claude Code 运行在用户的机器上，可以访问其文件系统、shell 和网络。没有这些权限，编程智能体的用处就很有限，因此必须找到一种安全授予这些访问权限的方法。

一种方法是依靠人在回路。这对 Claude Code 来说才是可行的方案，因为其典型用户是熟悉编程环境的开发者：他们能读懂 bash，明白 rm -rf 是干什么的，而且每周已经会数次从不受信任的来源运行 npm install。这一切意味着，当“允许此操作”对话框弹出时，他们很可能具备准确评估智能体正在尝试做什么以及其中所涉风险的专业知识。有鉴于此，Claude Code 上线时采用了最简单的防御方式：允许读取，写入、bash 和网络访问则需要批准。

然而，正如前文所述，批准疲劳没几周便显现了出来。 讽刺的是，这意味着一个最初旨在提供监督的功能可以说起到了相反的效果——一些用户可能干脆不再关注。作为减少草率批准的第一步，我们推出了操作系统级的沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap）来强化这一边界：允许读取，允许在工作区内写入，但默认拒绝网络访问。在沙箱内，agent 基本上可以不间断地运行。结果是权限提示减少了 84%，我们还开源了该运行时，因此这一边界是可审计的。

我们的匿名化使用数据也显示，有经验的用户自动批准的频率大约是新用户的两倍，但他们也更频繁地在 agent 执行过程中进行中断。有经验的用户不再对每一步进行把关，而更倾向于只在 agent 偏离轨道时才进行监督。虽然这可能是人们与 agent 协作偏好的一种自然演化，但这种方式同样可能出错——它首先要求用户具备足够的技术能力和专注度，才能察觉到偏差。随着模型能力的提升，以及 agent 开始编写越发雄心勃勃的 bash，察觉此类偏差变得越来越难。而随着用户转向多 agent 系统，这种方式作为有效监督策略的可能性也大大降低。

我们错过的风险：信任对话框之前的所有环节

从 2025 年年中到 2026 年 1 月，我们通过负责任披露计划收到了关于 Claude Code 漏洞的报告。其中三个漏洞针对的是在用户同意任何操作之前就执行的代码。要理解这怎么可能，请看最直接的案例：一位开发者克隆了一个仓库来审查某个 pull request，而该仓库包含一个定义了 hook 的 .claude/settings.。由于 Claude Code 在启动时就会读取项目设置——早于标准的"你信任这个文件夹吗？"提示出现——攻击者编写并提交的 hook 便会自动执行。其余案例在结构上类似：都是在信任边界建立之前，就解析了来自尚未受信任目录的输入。

每个案例的修复方式都相同：将项目本地配置的解析与执行推迟到用户接受信任提示之后。如果你正在构建类似的东西，请像对待来自互联网的任何入站请求那样对待项目打开、配置加载和 localhost 监听器。它们不应仅仅因为感觉上是本地的、并且在用户同意之前就已到达，就被隐式信任。

我们错过的风险：用户作为注入载体

2026 年 2 月，在一次受控的内部红队演练中，一名研究员成功钓鱼诱导一名员工以恶意提示启动了 Claude Code。这个钓鱼看起来像普通的协作——一封"能帮我运行一下这个吗？"的邮件，附有一段可直接粘贴的提示——而提示本身读起来就像常规的任务说明。但在设置步骤之间的某处，它委婉地要求 Claude 读取 ~/.aws/credentials，将内容编码后 POST 到一个外部端点。在针对该提示的 25 次重试中，Claude 完成了 24 次数据外传。

这是一次直接的提示词注入——攻击者的指令是通过用户传入的，而非通过工具输出或抓取的内容。我们的模型层防御以用户意图为锚点——当输入指令的正是用户本人时，分类器没有任何异常可捕捉。如果把同样的脚本交给一位人类承包商，他也会照做。

在这种情况下唯一站得住脚的防御是环境本身，具体来说是不论意图如何都会拦截该 POST 请求的出站控制，以及从一开始就让 ~/.aws 无法被触及的文件系统边界。

（当我们在内部 Slack 上分享这个可用的提示词进行讨论时，有人指出一些内部智能体会阅读 Slack。这个恶意载荷就此进入了周围环境。我们在该话题串中加入了一个金丝雀字符串，以便在任何东西拾取它时能有所察觉。在一个智能体阅读一切的世界里，调查工具本身也是一种攻击面。）

模式 3：本地 VM（Claude Cowork）

Claude Cowork 运行在用户的桌面上，可以访问用户选定的工作区文件夹。由于这个平台是为通用知识工作而非软件工程构建的，普通用户精通 bash 的可能性要小得多。

因此，人在回路中的沙箱策略可能无法照搬；不应指望非技术背景的知识工作者能判断诸如 find . -name "*.tmp" -exec rm {} \; 这样的 bash 咒语。当批准例外需要典型用户并不具备的专业知识时，管理员应该设置一个绝对且始终生效的边界。

为了实现这一点，我们的第一个版本的 Claude Cowork 运行在一个完整的虚拟机中，使用平台厂商的 hypervisor（macOS 上是 Apple 的 Virtualization 框架，Windows 上是 HCS）。这个 VM 拥有自己的 Linux 内核、自己的文件系统和自己的进程表。用户选定的工作区文件夹和 .claude 文件夹会被挂载进来；主机上的其他内容均不可见。凭据保留在主机的钥匙串中，绝不进入客户机。这一设计防范的是 Claude 在某个时刻可能以不对齐方式行事的可能。被攻陷的 Claude 仍可能损坏工作区文件夹内的内容，因此该架构的设计目标是确保那是它唯一能触及的东西（直到用户添加连接器为止），并且由用户控制挂载进来的内容。

在最初的架构——我们称之为完整 VM 模式——中，agent 循环本身运行在客户机内，因此 Claude 以一个普通 Linux 用户的身份执行，完全不知道自己处于沙箱之中。相比之下，在 Claude Code 中，一个特权进程位于沙箱之外，逐条命令地决定是否强制执行；一条有说服力的注入提示词或一次疲惫的批准点击，都可能让那个进程运行未沙箱化的内容。而在这里，不存在持有逃生舱钥匙的外层进程，因此也没有任何组件拥有授予例外的权限。

然而，我们很快意识到，以完整虚拟机（full-VM）模式运行整个智能体会带来实际问题：虚拟机启动期间的任何故障都会使 Cowork 无法使用。将智能体循环移到虚拟机外部，同时将代码执行保留在虚拟机内部，这样即使出错，Claude 仍能响应用户并帮助调试问题，而不是卡死在错误上。这一改动对安全性的影响极小，因为虚拟机仍然对智能体执行的代码实施文件系统和网络控制。

另外，我们还将本地 MCP 服务器移出了虚拟机。在虚拟机内运行它们会使其更难审计，并在虚拟机更新时产生脆弱的依赖问题，而且无法支持需要与数据库等本地进程交互的 MCP——这类服务器无论如何都必须在主机上运行。这一改动使 Claude Cowork 与本地 MCP 服务器在 Claude Desktop 中的既有工作方式保持一致：将其视为用户可能选择安装的任何软件，并委托管理员决定启用哪些本地 MCP（如果有）。远程 MCP 服务器不受影响，因为它们不在用户的机器上运行。

文件系统控制是另一个重要的架构选择。Claude 需要能够访问主机上的某些文件才能发挥作用，但我们希望将影响范围降到最低，并让用户对本地文件访问保持透明。我们发现，提供不同的文件挂载模式有助于细粒度地控制风险；Claude Cowork 提供只读、读写和读写不可删除三种模式。这里的一个潜在陷阱是，符号链接解析必须发生在路径验证之前而不是之后，否则授权文件夹内的符号链接可能指向外部并逃逸。对于企业客户，我们允许管理员通过 MDM 设置中的挂载路径白名单来控制这一点。

我们错过的风险：通过获准域名的数据外泄

通过获准域名进行数据外泄的一个典型案例来自第三方披露。Claude Cowork 的出站白名单正确地放行了发往 api.anthropic.com 的流量——该产品若不调用我们自己的 API 就无法运作。在这个案例中，放置在用户挂载工作区中的一个恶意文件携带了隐藏指令以及一个由攻击者控制的 API 密钥。Claude 按照指令读取了工作区中的其他文件，并使用攻击者的密钥调用了 Anthropic 的 Files API。出站代理检查了目标地址，看到是 api.anthropic.com，便放行了。文件被上传到了攻击者的 Anthropic 账户。沙箱运行得完美无缺，然而数据还是被外泄了。

此前，我们将白名单理解为一种目标过滤器，即告诉 Claude 这些域名可以与之通信。但将其理解为一种能力授予可能更贴切。通过白名单上任何域名可触达的每一项功能，现在都成了攻击面。允许访问 api.anthropic.com 就意味着允许向任意 Anthropic 账户上传文件。

我们通过在 VM 内部部署一个防御性的中间人（man-in-the-middle）代理来修复了这个问题，它会拦截发往我们 API 的流量。该代理只放行携带 VM 自身预置会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。它还会阻止可能启用服务器端 fetch 的请求头。代理之所以放在 VM 内部而不是我们的服务器上，是因为只有 VM 知道请求来源——从服务器的角度看，Cowork 请求与其他任何 API 客户端的请求无法区分。

这也是"你自己构建的软件往往是最薄弱的"这一原则的第二个例证。我们各产品中的 hypervisor、seccomp 和 gVisor 一直都很可靠。出问题的正是我们自定义的白名单代理。

我们遗漏的风险：VM 隔离同时也把端点检测软件挡在了外面

在评估 Claude Cowork 时，企业安全团队会问："为什么我们的 EDR 看不到内部情况？"答案是，将 Claude 限制在内的同一套隔离机制，也把基于主机的端点检测与响应挡在了外面。从 EDR 的角度来看，Claude Cowork 是一个不透明的 hypervisor 进程，它无法检查其中的客户机。

隔离会降低可见性，而对于合规姿态依赖端点可见性的团队来说，不透明是个问题。我们目前的缓解措施是使用基于拉取的 OTLP 导出，让管理员可以事后检索事件日志，但这与实时监控并不相同。如果你在构建类似的东西，请尽早把这场沟通纳入计划。

信任智能体读取的内容

企业经常问我们如何保障 MCP 连接的安全。这是个好问题，但正确的问题比 MCP 本身更宽泛。提供给智能体的任何外部资源都同时代表两种风险：传统供应链意义上的代码执行风险，以及提示注入向量。传统的依赖审计（固定版本、验证签名、审查源码）能解决第一种，却会漏掉第二种。

远程与本地之争比看起来更重要。本地安装的工具是可审计的：你可以阅读代码、固定版本，并确信它不会在你不知情的情况下更改。而远程工具——托管式 MCP 服务器、云连接器——在你批准之后的任何时刻都可能改变行为；你在安装时做出的信任决定可能不再适用。我们的 连接器目录通过持续审查来解决这个问题，但目录之外的任何东西都应被视为不可信。请先在恶意工具影响范围受到控制的环境中，用假数据进行测试。

即使工具本身可信，工具输出也是一种攻击面。前文提到的 GitHub README 示例正是这种情况；对网页所做的任何输入扫描，都需要以同样严格的标准应用于具备联网能力的工具结果。尽管这会增加延迟且并非完美的防御手段，我们仍倾向于实时检查：一旦被投毒的工具返回值已诱使智能体外泄数据，日志中只会留下一次成功且经过授权的 API 调用，事后没有任何可供追查的信号。

在 Claude Code 和 Claude Cowork 中，工具调用经由强制执行网络与文件策略的代理进行路由，并可在返回值进入模型上下文之前对其进行检查。执行检查的分类器可以是一个小巧、快速的模型；它无需是负责推理的那个模型。

展望未来

模型和产品正在快速进步。与此同时，风险也在不断变形和演化，我们的缓解措施必须同步跟上以应对它们。

持久化记忆投毒。跨会话持久保存的智能体上下文所占比例不断增长——这包括产品记忆、CLAUDE.md 文件、挂载的工作区，以及定时任务和长时间运行智能体的状态目录。落入其中任何一项的注入内容都会在智能体每次启动时被重新加载。随着越来越多的智能体状态在会话结束后留存，我们面临着经典后渗透意义上的新型持久化机制的威胁。会话启动时的良好分类器将需要变得更加普及。

多智能体信任升级。一方面，子智能体可以隔离不可信内容，向主智能体返回结构化的事实，而非原始文本。另一方面，这也可能被滥用：如果子智能体的输出因为来自“我们”而被视为比原始工具结果具有更高的信任级别，就会引入新的提示注入攻击向量。在多智能体系统中，分配不同信任级别与容易遭受信任升级之间存在权衡。

智能体身份。Claude Cowork 对智能体身份的解答非常具体：凭据保留在主机钥匙串中，VM 获得按会话缩减范围的令牌，并且该令牌可以独立于用户令牌被撤销。然而，我们正开始着手应对跨平台智能体身份这一更宏大的问题。智能体应当拥有自己的主体身份，还是应当作为用户的延伸并继承用户的权限？归根结底，答案可能是两者的结合。

随着智能体能力不断增强，攻击面也在持续变化。我们已见的这些失效类型很可能在各行各业和各个实验室中重演。我们需要对智能体专属的安全态势进行集体投入，从共享的基准测试和披露规范，到通用的身份标准和跨厂商红队演练。本文聚焦于遏制手段，但这只是智能体安全图景中的一部分。关于治理、可观测性以及技术栈的其余部分，请参阅 NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 牵头并联合 CISA 和英国 NCSC 发布的六机构智能体 AI 采纳指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中一项贡献，但我们期待与合作伙伴和竞争对手就此关键议题展开合作。

总结

简而言之，有几条我们不断回归的原则：

首先在环境层设计遏制，然后在模型层引导行为。给我们上了最深刻一课的两个事件——员工钓鱼事件和第三方允许列表泄露事件——都属于数据外发案例，即数据经由一条被允许的路径流出。在这两起事件中，模型层都帮不上忙；没有任何异常可供它捕捉。当所有概率性手段都失灵时，最终承接受到冲击的正是确定性边界。

将隔离强度与用户的监督能力相匹配。能读懂 bash 的开发者和读不懂 bash 的知识工作者，面对的并不是同一种威胁模型。用户能否评估智能体即将执行的操作，这个问题应有助于确定遏制策略；而无论朝哪个方向答错——给专家带来过多阻碍，或给非专家过多信任——本身都是一种失败。

警惕自定义组件。久经考验的虚拟机管理程序、系统调用过滤器和容器运行时，经受过的对抗性考验远超你自己构建的任何东西。在本文所述的每一次部署中，标准原语都经受住了考验，而我们围绕它们自行构建的部分反而暴露出缺陷。

归根结底，尽管智能体可能是一类新软件，但它们的系统级交互并非如此。它们仍然会读取文件、打开套接字、生成进程；这使得利用成熟工具进行遏制成为一种至关重要的可行防御手段。随着 AI 的发展，部署的风险收益平衡将不断变化，但为影响范围设定硬性上限，往往能迫使这种平衡朝着正确的方向发展。

致谢

作者：Max McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton 和 Abel Ribbink。

我们还要感谢 Hanah Ho、Hasnain Lakhani、Pedram Navid、Molly Villagra、Maya Nielan、Akila Srinivasan、Travis Szucs、Sam Attard、Alfred Xing、Mohamad El Hajj、Gabby Curtis、David Dworken、Adam Jones、Amie Rotherham、Christian Ryan、Lucas Smedley、Brett Andrews 以及其他贡献者。

特别感谢我们的安全与产品工程团队，以及向 Claude 产品报告漏洞的个人和组织。

脚注

1. Claude Code 自动模式将命令审批委托给基于模型的分类器；它将摩擦降到最低（约 0.4% 的良性命令被拦截），代价是漏掉一部分危险命令（约 17% 的过于激进的操作会被放行），因此它是沙箱内部纵深防御中的一层，而不是沙箱的替代品。