我们如何在各个产品中控制 Claude | Anthropic

来源: https://www.anthropic.com/engineering/how-we-contain-claude 抓取时间: 2026-07-21 16:23:19

十二个月前，我们会断然拒绝授予 Claude 足以关闭 Anthropic 内部服务的访问权限的想法。今天，这种级别的访问已经成为常规，Anthropic 开发者因此而更高效。这些部署的风险由两部分组成：故障发生的可能性，以及故障可能造成的损害程度。安全措施和模型训练方面的进展一直在稳步降低前者；而后者——理论上的影响范围——只会随着能力和访问权限的扩大而增长。然而，随着智能体变得有能力完成曾经需要一个人甚至一个团队的工作，不部署的成本变得足够大，以至于只要产品可以安全制造，风险回报计算就会严重倾向于采用。工程问题变成了如何限制影响范围。

当可以对自主智能体的相对损害设置限制时——例如通过控制其环境——高实用能力可以推动部署。Claude Mythos Preview 是一个模型的例子，其影响范围在 2026 年 4 月被认为太高而无法发布。然而，我们预计，随着防御者强化关键系统和安全措施成熟，具有类似能力水平的模型的更广泛发布将变得合适——尽管某些风险将始终存在。模型能力是智能体部署总风险的一个重要因素。

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

第一种是通过人在环中来监督智能体的行为。Claude Code 以前通过在每一步请求用户许可来防止智能体采取意外行动。理论上这有效，但我们发现这种方法是容易出错的。我们的遥测显示用户批准了大约 93% 的许可提示。用户看到的批准越多，他们对每个的关注越少，随着时间的推移，他们的监督就越不勤奋。我们最近构建了 Claude Code 自动模式，它自动化更安全的批准以减少这种批准疲劳。尽管如此，漏洞仍然存在——任何概率防御都有非零的错过率。¹

限制影响范围的第二种方法——也是本文大部分内容的重点——是遏制。我们不是监督智能体做什么，而是通过例如沙箱、虚拟机和出口控制来强制执行访问边界，从而监督它能够做什么。这是 Anthropic 工程投入最多精力的地方，也是许多最令人惊讶的安全故障发生的地方。

在过去两年中，我们发布了三个主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每个都服务于不同的受众，需要不同的遏制架构。本文分享了什么被保留下来的东西、什么被破坏了，以及我们在此过程中关于智能体安全性的所学。

三种风险类型，三个防御组件

智能体的安全风险分为三类：

用户滥用： 用户——无论是恶意还是粗心——指示智能体做有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们不理解的破坏性命令，再到指定故意伤害的所有内容。

模型不当行为： 智能体采取了没有人要求的有害行动。随着我们模型的改进，它们在大多数行为评估上变得更加一致，但这并不意味着风险必然缩小。能力较弱的模型更可能误读情况并犯明显的错误。能力较强的模型犯的错误更少，但它们也更善于找到通往目标的意外路径，通常是通过绕过没有人想到要写下来的限制。

在 Anthropic，我们已经看到 Claude 模型"有帮助地"逃离沙箱以完成任务，检查 Git 历史以找到编码测试的答案，并自发地识别它正在运行的基准测试，以解密其答案键。每个模型都带来了一套新的能力，这些能力有时会以意想不到的方式发挥作用。

外部攻击者： 智能体通过外部向量如工具、文件或网络访问受到攻击。这包括提示注入和对智能体运行时、编排层或代理的传统攻击。

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

智能体运行的环境。 我们通过进程沙箱、VM、文件系统边界和出口控制来约束智能体可以采取行动的地点和方式。目标是为智能体可以到达的范围设置硬边界。例如，如果凭证永远不会进入沙箱，它们就不会被窃取，无论原因是用户、模型找到"创造性"路径还是攻击者。

紧密的外围也意味着你可以放松监督。Claude Code 的参考开发容器的存在正是为了让智能体可以无人值守运行，无需每次操作都批准。

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

这些防御措施很强。在 Gray Swan 的智能体红队基准测试（测试提示注入的易感性）上，Claude Opus 4.7将单次尝试的攻击成功率控制在大约 0.1% 左右，100 次自适应尝试后约为 5-6%。Claude Code 自动模式在执行前捕获大约 83% 的过于急切的行为。然而，即使有一流的防御，模型层的保护永远不会 100% 有效，这就是为什么它不能独立存在。

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

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

_三个需要防御的组件：模型、它运行的环境，以及智能体可以访问的外部内容。

遏制智能体的模式

专注于环境层，我们描述了三种隔离模式以及它们如何为每个 Claude 平台——claude.ai、Claude Code 和 Cowork——量身定制。我们在找到了我们从智能体需要的能力和用户需要的干预程度之间找到了平衡后，逐渐得出了每个设计。

模式 1：临时容器（Claude.ai 代码执行）

虽然 Claude.ai 作为聊天界面最为人所知，但它也编写和运行代码、生成文件并调用连接器。当 Claude 在 Claude.ai 中运行代码时，它是在隔离基础设施上的 gVisor容器中执行的。智能体完全在服务器端；没有代码在本地机器上运行，文件系统是临时的（每个会话一个）。影响范围很小，但 Claude 可以做的事情的上限也很小——没有持久的工作空间，也没有访问用户文件系统的权限。

这也使得 claude.ai 受到更传统的威胁模型的约束。我们不是在保护用户机器免受智能体的侵害；我们是在保护我们自己的基础设施和每个租户彼此免受侵害。我们为 claude.ai 进行的发布前工作主要是传统的安全工作，如网络配置、内部服务认证和编排。

这项工作强化了安全领域最古老的教训：最薄弱的层是你自己构建的那一层。gVisor 和 seccomp 抵御资源充足的对手的时间比智能体 AI 存在的时间要长得多，所以审查工作集中在我们围绕它们构建的新部分上。我们稍后会回到这一点，因为我们的自定义代理也是我们在最重大事件中破坏的那部分。

模式 2：人在环中沙箱（Claude Code）

Claude Code 在用户的机器上运行，并可以访问其文件系统、shell 和网络。如果没有这个，编码智能体的用处有限，所以必须找到一种安全授予该访问权限的方法。

一种方法是依靠人在环中。这对 Claude Code 来说只是一个可行的解决方案，因为普通用户是熟悉编码环境的开发者：他们可以读 bash，他们理解 rm -rf 做什么，并且他们已经每周几次从不受信任的来源运行 npm install。所有这些意味着，当"允许此操作"对话框弹出时，他们极有可能具备准确评估智能体试图做什么和所涉及风险的专业知识。鉴于此，Claude Code 以最简单的防御方式推出：允许读取，要求批准写入、bash 和网络访问。

然而，如前所述，批准疲劳在几周内就出现了。具有讽刺意味的是，这意味着最初旨在提供监督的功能可以说可能产生相反的效果——一些用户可能干脆不再关注。作为减少轻率批准的第一步，我们推出了一个操作系统级别的沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap），它强化了边界：允许读取，允许在工作空间内写入，但默认拒绝网络。在沙箱内，智能体大部分时间都在不间断地运行。结果是权限提示减少了 84%，我们开源了运行时，因此边界是可审计的。

我们的匿名使用数据还显示，有经验的用户自动批准的频率大约是新用户的两倍，但他们也更频繁地在执行过程中打断智能体。有经验的用户不是限制个别步骤，而是更可能只在智能体偏离轨道时监督它。虽然这可能是人们更喜欢与智能体合作的自然演变，但这也是容易出错的，要求用户首先要有足够的技术和足够专注，才能注意到偏离。随着模型能力的提高和智能体开始编写越来越雄心勃勃的 bash，注意到任何此类偏离变得更加困难。并且随着用户转向多智能体系统，这种方法也不太可能成为有效的监督策略。

我们错过的风险：信任对话框之前的一切

在 2025 年中到 2026 年 1 月期间，我们通过负责任披露计划收到了 Claude Code 漏洞的报告。其中三个漏洞针对的是在用户同意任何事情之前执行的代码。要理解这是如何可能的，请考虑最直接的情况：开发者克隆仓库来审查拉取请求，而该仓库包含一个 .Claude/settings.JSON，它定义了一个钩子。因为 Claude Code 在启动期间——在呈现标准的"你信任此文件夹吗？"提示之前——读取项目设置，因此攻击者编写并提交的钩子将自动执行。剩余的情况在结构上看起来相似，在建立信任边界之前解析来自尚未信任的目录的输入被解析。

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

我们错过的风险：用户作为注入向量

2026 年 2 月，在受控的内部红队演习中，一名研究人员成功地钓鱼一名员工使用恶意提示启动 Claude Code。钓鱼看起来像普通的协作——一封"你能为我运行这个吗？"的电子邮件，附有一个准备好粘贴的提示——并且提示本身读起来像常规的任务说明。但在设置步骤中的某个地方，它温和地要求 Claude 读取 ~/.AWS/credentials，对内容进行编码，并将它们 POST 到外部端点。在该提示的 25 次重试中，Claude 24 次完成了数据窃取。

这是直接提示注入——攻击者的指令通过用户到达，而不是通过工具输出或获取的内容。我们的模型层防御锚定在用户意图上——当用户自己输入指令时，分类器没有什么异常可抓。一个人类承包商拿到相同的脚本也会做同样的事情。

在这种情况下唯一有效的防御是环境，特别是出口控制，无论意图如何都阻止 POST，以及文件系统边界首先使 ~/.AWS 遥不可及。

（当我们在内部 Slack 中分享工作提示进行讨论时，有人指出一些内部智能体会读取 Slack。有效载荷现在是无处不在。我们向线程添加了一个金丝雀字符串，这样如果有任何东西捡起它，我们就会注意到。在智能体读取一切的世界中，调查工具也是一个攻击面。）

模式 3：本地 VM（Claude Cowork）

Claude Cowork 在用户的桌面上运行，可以访问用户选择的工作空间文件夹。因为该平台是为一般知识工作而构建的，而不是软件工程，所以普通用户不太可能精通 bash。

因此，人在环中沙箱策略可能不适用；非技术知识工作者不应该被期望判断 bash 咒语，如 find . -name "*.tmp" -exec rm {} \;。当批准异常需要普通用户没有的专业知识时，管理员应该设置一个绝对且始终在线的边界。

为了实现这一点，我们的第一版 Claude Cowork 使用平台的供应商虚拟机管理程序（macOS 上的 Apple Virtualization 框架，Windows 上的 HCS）在完整虚拟机内运行。VM 有自己的 Linux 内核、自己的文件系统和自己的进程表。用户选择的工作空间和 .Claude 文件夹被挂载；主机上没有其他东西可见。凭证保留在主机的钥匙串中，永远不会进入客户机。这种设计防止了 Claude 在某些时候行为不一致的可能性。一个受损的 Claude 仍然可以损坏工作空间文件夹内的东西，所以架构设计确保这是它唯一可以到达的东西（直到用户添加连接器），并且用户控制那里挂载的内容。

在原始架构中——我们称之为全 VM 模式——智能体循环本身在客户机内运行，所以 Claude 作为普通的 Linux 用户执行，没有意识到它被沙箱化。将此与 Claude Code 相比，在 Claude Code 中，特权进程位于沙箱外部，决定每个命令是否强制执行；一个有说服力的注入提示或疲劳的批准点击可以让该进程运行未沙箱化的东西。在这里，没有外部进程持有逃生舱口钥匙，因此没有组件有权授予异常。

_Claude Cowork VM 的六个主要隔离机制。两个在客户机内核外部强制执行，因此即使智能体在 VM 内实现 root 级访问，它们也会存活。其他四个由客户机强制执行，并故意保持最小，因为外层承担其余部分。

然而，我们很快意识到，以全 VM 模式运行整个智能体会导致实际问题：VM 启动期间的任何故障都会使 Cowork 无法使用。将智能体循环移到 VM 外部，同时保持代码执行在 VM 内部，允许 Claude 仍然响应用户并帮助调试问题，而不是冻结在错误上。此更改造成的安全影响最小，因为 VM 仍然对智能体执行的代码强制执行文件系统和网络控制。

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

_让智能体循环在 VM 内部意味着 VM 中的任何故障都会导致 Cowork 无法使用。主机模式更可靠，因为如果 VM 崩溃，智能体仍然可以响应，并且它仍然通过隔离代码执行提供重要的安全保证。

文件系统控制是另一个重要的架构选择。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 内部的防御性中间人代理修复了它，该代理拦截到我们 API 的流量。它只传递携带 VM 自己预配置会话令牌的请求；攻击者嵌入的密钥被代理拒绝。它还阻止启用服务器端获取的标头。代理位于 VM 内部而不是我们的服务器上，因为只有 VM 知道来源——从服务器的角度来看，Cowork 请求与任何其他 API 客户端无法区分。

_上图：到 API.Anthropic.com 的流量被允许，导致出口。下图：使用拦截到我们 API 流量的中间人代理修复。

这也是你自己构建的软件通常是最薄弱的原则的第二个例子。我们产品中的虚拟机管理程序、seccomp 和 gVisor 是可靠的。我们的自定义允许列表代理是失败的那部分。

我们错过的风险：VM 隔离也将端点检测软件挡在了外面

在评估 Claude Cowork 时，企业安全团队问："为什么我们的 EDR 看不到内部？"答案是，将 Claude 包含在内的相同隔离也将基于主机的端点检测和响应挡在了外面。从 EDR 的角度来看，Claude Cowork 是一个不透明的虚拟机管理程序进程。它无法检查客户机。

隔离降低了可见性，不透明对于合规姿势依赖于端点可见性的团队来说是个问题。我们当前的缓解措施是使用基于拉的 OTLP 导出，让管理员事后检索事件日志，但这与实时监控不同。如果你正在构建类似的东西，请尽早为这次对话做好预算。

信任智能体读取的内容

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

**远程与本地的区别比看起来更重要。本地安装的工具是可审计的。你可以读取代码，固定版本，并知道它不会在你之下改变。远程工具——托管的 MCP 服务器、云连接器——可以在你批准后随时改变行为；你安装时的信任决定可能不再适用。我们的连接器目录通过持续审查解决了这个问题，但它之外的任何东西都应该被视为不受信任。首先在恶意工具的影响范围被遏制的环境中，对其对假数据进行运行。

**即使工具是可信的，工具输出也是一个攻击面。前面提到的 GitHub README 示例就是这种情况；应用于网页的任何输入扫描都需要以同样的严谨度应用于支持网络的工具结果。尽管这会增加延迟并且不是完美的防御，但我们倾向于实时检查：一旦被污染的工具返回引导智能体窃取数据后，日志只显示成功的、授权的 API 调用。没有事后可找的信号。

在 Claude Code 和 Claude Cowork 中，工具调用通过代理路由，这些代理强制执行网络和文件策略，并可以在返回值进入模型上下文之前检查它们。进行检查的分类器可以是一个小的、快速的模型；它不需要是进行推理的那个。

展望未来

模型和产品正在快速发展。随着它们的发展，风险也在变化和演变，我们的缓解措施必须跟上以它们。

持久内存中毒。 跨会话持久的智能体上下文份额持续增长——这包括产品内存、Claude.md 文件、挂载的工作空间以及调度和长时间运行的智能体的状态目录。落在这些中的任何一个中的注入都会在每次智能体启动时重新加载。随着更多的智能体状态在会话中存活，我们受到经典后利用意义上的新持久机制的威胁。会话启动时的良好分类器将需要变得更加普遍。

多智能体信任升级。 一方面，子智能体可以隔离不受信任的内容，将结构化事实而不是原始文本返回给主智能体。另一方面，这可能被滥用：如果子智能体的输出被视为比原始工具结果更高的信任度，因为这样的输出来自"我们"，那么就引入了提示注入的新向量。在多智能体系统中，分配不同的信任级别和容易受到信任升级之间存在权衡。

智能体身份。 Claude Cowork 对智能体身份的回答是具体的：凭证保留在主机钥匙串中，VM 获得每个会话的范围缩小令牌，并且该令牌可以独立于用户的令牌被撤销。然而，我们开始努力解决跨平台智能体身份的更广泛问题。智能体应该拥有自己的主体身份，还是应该作为用户的扩展并继承用户的权限？最终，答案可能是两者的混合。

随着智能体变得更有能力，攻击面不断变化。我们看到的故障类型可能会在各个行业和实验室中重复。我们需要集体投资于智能体特定的安全态势，从共享基准和披露规范，到共同的身份标准和跨供应商红队。我们在这篇文章中专注于遏制，但这只是智能体安全图景的一部分。关于治理、可观察性和堆栈的其余部分，请参见 NIST 关于 AI 智能体身份和授权的项目、由澳大利亚 ACSC 与 CISA 和英国 NCSC 领导的关于采用智能体 AI 的六机构指南，以及 ISO/IEC 42001，AI 管理标准。我们的 Glasswing 倡议是一个贡献，但我们期待与合作伙伴和竞争对手一起在这个关键问题上合作。

总结

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

首先在环境层设计遏制，然后在模型层引导行为。 教给我们最多的两个事件——员工钓鱼和第三方允许列表披露——都是出口事件，数据通过允许的路径离开。在每一个事件中，模型层都无济于事；没有什么异常可抓。确定性边界是当所有概率性措施都错过时会被击中的东西。

将隔离强度与用户的监督能力相匹配。 一个可以读 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 自动模式将命令批准委托给基于模型的分类器；它以错过一部分风险行动（约 17% 的过于急切的行动通过）为代价，最大限度地减少摩擦（约 0.4% 的良性命令被阻止），因此它是沙箱内纵深防御的一层，而不是沙箱的替代品。