Anthropic 如何在 Claude 各产品中实施智能体隔离

12个月前，我们会断然否决这样一种想法：赋予 Claude 足以让一个 Anthropic 内部服务下线的访问权限。如今，这种级别的访问已成常态，而 Anthropic 开发者也因此更加高效。这类部署的风险有两个组成部分：失败发生的可能性，以及一旦失败可能造成多大破坏。防护措施和模型训练的进展稳步压低了前者；后者——理论上的爆炸半径——却只会随着能力和访问权限的扩张而不断增大。然而，随着智能体开始能够完成过去需要一个人甚至一个团队才能完成的工作，不部署它们的成本变得足够高，以至于只要产品能够做到安全，风险收益权衡就会明显倒向采用。工程上的问题于是变成了如何限制爆炸半径。

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

第一种是通过人工在环来监督智能体的行为。Claude Code 之前通过在每一步都请求用户许可，来防止智能体采取非预期行动。从理论上讲这行得通，但我们发现这种方法并不可靠。我们的遥测数据显示，用户大约批准了 93% 的权限提示。用户看到的批准请求越多，他们对每一次请求投入的注意力就越少，久而久之，在监督上会变得远没有那么尽责。我们最近构建了 Claude Code 自动模式，通过自动化更安全的批准来减少这种批准疲劳。尽管如此，漏洞仍然存在——任何概率性的防御都有非零的漏检率。¹

第二种限制爆炸半径的方法——也是本文大部分内容关注的重点——是隔离。与其监督智能体做了什么，我们更关注通过例如沙箱、虚拟机和出口控制来强制执行访问边界，从而监督它能够做什么。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——进行定制。在找到我们对代理所需能力与用户所需介入程度之间的平衡之后，我们才逐步形成了每一种设计。

模式 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 漏洞的报告。其中有三个漏洞针对的是在用户尚未同意任何事情之前就会执行的代码。要理解这为何可能发生，来看最直接的情况：开发者克隆一个仓库来审查 pull request，而该仓库包含一个定义了 hook 的 .claude/settings.json。由于 Claude Code 会在启动期间读取项目设置——而这发生在标准的“Do you trust this folder?”提示出现之前——攻击者编写并提交的 hook 就会自动执行。其余案例在结构上也很相似：在信任边界尚未建立之前，来自这个尚未被信任目录的输入就已经被解析了。

每个案例中的修复方式都具有同一种形态：把对项目本地配置的解析和执行推迟到用户接受信任提示之后。如果你也在构建类似的东西，应当像对待来自互联网的任何入站请求一样，对待打开项目、加载配置以及 localhost 监听器。不能因为它们看起来像本地的、又是在用户同意之前到达，就默认信任它们。

我们遗漏的风险：用户作为注入向量

2026 年 2 月，在一次受控的内部红队演练中，一名研究人员成功钓鱼诱骗一名员工用恶意提示启动 Claude Code。这次钓鱼看起来就像普通协作——一封“can you run this for me?”的邮件，附带一段可直接粘贴的提示——而提示本身读起来也像是常规的任务说明。但在设置步骤的某处，它不动声色地要求 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 运行在一个完整的虚拟机中，使用平台供应商的虚拟机监控程序（macOS 上是 Apple's Virtualization framework，Windows 上是 HCS）。这个 VM 拥有它自己的 Linux 内核、它自己的文件系统，以及它自己的进程表。用户选定的工作区和 .claude 文件夹会被挂载进去；主机上的其他任何东西都不可见。凭证保留在主机的钥匙串中，绝不会进入客户机。这种设计是为了防范这样一种可能性：Claude 在某个时刻会以一种未对齐的方式行事。一个被攻陷的 Claude 仍然可能破坏工作区文件夹里的内容，因此这套架构被设计成确保那是它唯一能够触及的东西（直到用户添加连接器），并且由用户来控制那里挂载了什么。

在最初的架构中——我们称之为 full-VM 模式——代理循环本身运行在客户机内部，因此 Claude 作为一个普通的 Linux 用户执行，并不知道自己正处于沙箱中。把这和 Claude Code 对比一下：在那里，一个特权进程位于沙箱之外，按命令决定是否强制执行沙箱；一条有说服力的注入提示，或者一次疲惫中的批准点击，都可能让该进程运行某些未被沙箱约束的东西。而在这里，并不存在一个手握逃生舱门钥匙的外部进程，因此也就不存在任何有权批准例外的组件。

然而，我们很快意识到，以完整 VM 模式运行整个代理会带来实际问题：VM 启动期间的任何故障都会使 Cowork 无法使用。将代理循环移到 VM 外部，同时将代码执行保留在其中，使 Claude 仍然能够响应用户并帮助调试问题，而不是在出错时卡住。此更改带来的安全影响极小，因为 VM 仍然对代理执行的代码实施文件系统和网络控制。

另外，我们还将本地 MCP 服务器移到了 VM 外部。在 VM 内运行它们会让审计更困难，在 VM 更新时造成脆弱的依赖问题，而且也不支持那些需要与数据库等本地进程交互的 MCP——无论如何，这类服务器都必须在主机上运行。此更改使 Claude Cowork 与 Claude Desktop 中本地 MCP 服务器的现有工作方式保持一致：将它们视为用户可能选择安装的任何其他软件，并将决定启用哪些本地 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 内部部署一个防御性的中间人代理来修复这个问题，该代理会拦截发往我们 API 的流量。它只放行携带 VM 自身预配会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。它还会阻止那些会启用服务器端抓取的请求头。代理位于 VM 内部而不是我们的服务器上，因为只有 VM 知道来源——从服务器的角度看，来自 Cowork 的请求与任何其他 API 客户端都无法区分。

这也是“自己构建的软件往往最薄弱”这一原则的第二个例子。我们各个产品中的 hypervisor、seccomp 和 gVisor 一直都很可靠。出问题的是我们自定义的允许列表代理。

我们忽略的风险：VM 隔离也把端点检测软件挡在了外面

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

隔离会降低可见性，而对于合规态势依赖端点可见性的团队来说，这种不透明性会带来问题。我们当前的缓解措施是使用基于拉取的 OTLP 导出，让管理员能够事后提取事件日志，但这与实时监控并不相同。如果你正在构建类似的东西，请尽早为这类讨论预留空间。

信任 agent 读取的内容

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

远程与本地的区别，比看上去更重要。 本地安装的工具是可审计的。你可以阅读代码、固定版本，并且知道它不会在你不知情的情况下发生变化。远程工具——托管的 MCP 服务器、云连接器——在你批准之后的任何时刻都可能改变行为；你在安装时做出的信任判断可能不再适用。我们的 连接器目录 通过持续审查来应对这一点，但任何不在其中的东西都应被视为不可信。先用假数据运行它，并把它放在恶意工具影响范围被控制住的环境中。

即使工具本身可信，工具输出也仍然是一个攻击面。 前面提到的 GitHub README 示例正是这种情况；任何应用于网页的输入扫描，也需要以同样严格的标准应用到启用了网络功能的工具结果上。尽管这会增加延迟，而且并不是完美的防御，我们仍倾向于实时检查：一旦被污染的工具返回结果引导 agent 开始外传数据，日志里显示的就只是一条成功且经过授权的 API 调用。事后根本找不到任何可供追查的信号。

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

展望未来

模型和产品正在快速发展。随着它们发展，风险也在变化和演进，而我们的缓解措施必须跟上，才能应对这些风险。

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

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

智能体身份。 Claude Cowork 对智能体身份的答案是具体的：凭证保留在主机钥匙串中，虚拟机获得一个按会话范围缩减权限的令牌，而该令牌可以独立于用户的令牌被撤销。然而，我们正开始应对一个更广泛的问题：跨平台的智能体身份。智能体是否应该拥有自己的主体身份，还是应当作为用户的延伸并继承用户的权限？最终，答案可能是两者的结合。

随着智能体能力不断增强，攻击面也在持续变化。我们已经看到的失败类型，很可能会在各个行业和实验室中反复出现。我们需要对智能体特定的安全态势进行集体投入，从共享基准和披露规范，到通用身份标准和跨厂商红队测试。本文重点讨论隔离，但这只是智能体安全图景中的一部分。关于治理、可观测性以及其余技术栈，请参见 NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 联合 CISA 和英国 NCSC 牵头的 六家机构关于采用智能体式 AI 的指导，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是一项贡献，但我们也期待就这一关键问题与合作伙伴和竞争对手共同努力。

总结

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

首先在环境层设计隔离机制，然后在模型层引导行为。 给我们带来最多经验教训的两起事件——员工钓鱼攻击和第三方允许名单披露——都属于数据外流案例，也就是数据通过被允许的路径离开。在这两起事件中，模型层都无能为力；没有任何异常可供它捕捉。当一切概率性机制都失效时，真正会被触发的是确定性边界。

让隔离强度与用户的监督能力相匹配。 一个能读懂 bash 的开发者，与一个不能的知识工作者，面对的威胁模型并不相同。用户是否能够评估智能体即将执行的操作，这个问题应当有助于决定隔离策略；而在任何一个方向上回答错误——对专家施加过多摩擦，或对非专家给予过多信任——本身就是一种失败。

要警惕自定义组件。 经受过实战考验的虚拟机监控程序、系统调用过滤器和容器运行时，承受过的对抗性审视比你将构建的任何东西都更多。在这里描述的每一种部署中，标准原语都经受住了考验，而我们围绕它们所做的自研工作却暴露出了缺陷。

归根结底，尽管智能体可能是一类新的软件，但它们在系统层面的交互并不是新的。它们仍然会读取文件、打开套接字并生成进程；这使得借助成熟工具进行隔离成为一种至关重要且可行的防御。随着 AI 的发展，部署的风险回报平衡会持续变化，但对影响半径设定一个硬性上限，往往会迫使这种平衡朝着正确的方向发展。