Anthropic 如何在不同产品中隔离 Claude 并限制风险范围

Twelve months ago，我们会断然拒绝授予 Claude 足以使 Anthropic 内部服务瘫痪的访问权限。如今，这种级别的访问权限已是常态，Anthropic 开发者也因此提高了工作效率。这些部署的风险包含两个部分：发生故障的可能性，以及一次故障可能造成的损害程度。防护措施和模型训练的进步持续降低了前者；而后者——理论上的影响范围——只会随着能力和访问权限的扩展而增大。然而，随着智能体能够完成过去需要一个人甚至一个团队才能完成的工作，不部署的代价也变得足够高，以至于只要能确保产品安全，风险与收益的权衡就会明显倾向于采用智能体。工程问题随之变为如何限制影响范围。

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

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

限制影响范围的第二种方法——也是本文大部分内容的重点——是隔离。我们不再监督智能体做什么，而是通过沙箱、虚拟机和出站流量控制等手段强制实施访问边界，监督它能够做什么。这是 Anthropic 工程团队投入精力最多的领域，也是许多最出人意料的安全失效发生的领域。

过去两年，我们推出了三款主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每款产品面向不同的用户群体，需要不同的隔离架构。本文将分享哪些措施经受住了考验、哪些出了问题，以及我们在此过程中学到的智能体安全经验。

三类风险，三项防御组成部分

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

用户滥用：用户出于恶意或疏忽，指示智能体执行有害操作。这包括要求智能体绕过用户觉得烦人的检查、运行用户并不理解的破坏性命令，以及明确要求故意造成伤害等各种情况。

模型的不当行为：智能体采取了无人要求的有害行动。随着我们的模型不断改进，它们在大多数行为评估中表现得更加符合预期，但这并不意味着风险必然降低。能力较弱的模型更容易误判情况，犯下明显错误。能力更强的模型犯错更少，但也更善于找到达成目标的意外路径，往往会绕过那些没人想到要明确写下的限制。

在 Anthropic，我们曾见过 Claude 模型为了完成任务而“热心地”逃出沙箱，查看 git 历史记录来寻找编程测试的答案，以及自发识别正在接受的基准测试，以便解密其标准答案。每个模型都会带来一组新能力，而这些能力有时会被用于意想不到的用途。

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

在构建隔离与防御系统时，我们会针对三个主要组成部分实施防御：

智能体运行的环境。我们通过进程沙箱、虚拟机、文件系统边界和出站访问控制，限制智能体可以在何处以及以何种方式采取行动。目标是为智能体可触及的范围设定一道硬性边界。例如，如果凭证从未进入沙箱，就不可能被窃取外传，无论起因是用户、找到了“创造性”路径的模型，还是攻击者。

严密的边界也意味着可以放宽监督。Claude Code 的参考开发容器正是为此而设计，让智能体能够在无人值守的情况下运行，无需逐项操作审批。

智能体调用的模型。这里的机制包括系统提示、分类器、探针和训练调整。由于模型具有概率性，这些机制只能影响智能体倾向于做什么，而不能决定它在理论上能做什么。

这些防御措施很强大。在测试提示注入易感性的 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 漏洞的报告。其中三个漏洞针对的是在用户同意任何事项之前就会执行的代码。要理解这是如何发生的，可以看一个最直接的案例：开发者克隆一个代码仓库以审查拉取请求，而该仓库包含一个定义了钩子的 .claude/settings.json。由于 Claude Code 会在启动期间读取项目设置——此时尚未显示标准的“你信任此文件夹吗？”提示——攻击者编写并提交的钩子就会自动执行。其余案例在结构上也类似，都是在信任边界尚未建立之前，就解析了来自尚未受信任目录的输入。

每个案例的修复方式都相同：将项目本地配置的解析与执行推迟到用户接受信任提示之后。如果你正在构建类似的系统，请像对待任何来自互联网的入站请求一样，对待项目打开、配置加载和 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 使用平台厂商的虚拟机监控程序（macOS 上的 Apple Virtualization framework、Windows 上的 HCS），在完整的虚拟机中运行。该 VM 拥有自己的 Linux 内核、文件系统和进程表。用户选定的工作区和 .claude 文件夹会被挂载；主机上的其他内容均不可见。凭据保留在主机的钥匙串中，绝不进入客户机。这一设计旨在防范 Claude 在某个时刻出现不符合预期目标的行为。遭到入侵的 Claude 仍可能破坏工作区文件夹内的内容，因此，该架构旨在确保那是它唯一能够访问的内容（直到用户添加连接器），并确保用户能够控制挂载到其中的内容。

在最初的架构——我们称之为完整 VM 模式——中，智能体循环本身在客户机内部运行，因此 Claude 以普通 Linux 用户的身份执行，并不知道自己处于沙箱中。相比之下，在 Claude Code 中，一个位于沙箱之外的特权进程会逐条命令决定是否实施沙箱限制；一段具有说服力的注入提示，或一次因疲劳而作出的批准点击，都可能让该进程在没有沙箱保护的情况下运行某些内容。而在这里，并不存在持有逃生通道钥匙的外部进程，因此也没有任何组件有权批准例外。

然而，我们很快意识到，以完整虚拟机模式运行整个智能体会带来实际问题：虚拟机启动期间的任何故障都会导致 Cowork 无法使用。将智能体循环移到虚拟机外部，同时仍在虚拟机内部执行代码，让 Claude 仍能响应用户并帮助排查问题，而不是遇到错误就卡住。这项变更对安全性的影响很小，因为虚拟机仍会对智能体执行的代码实施文件系统和网络控制。

另外，我们还将本地 MCP 服务器移到了虚拟机外部。在虚拟机内部运行这些服务器会使其更难审计，在虚拟机更新时产生脆弱的依赖关系问题，而且无法支持需要与数据库等本地进程交互的 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 客户端的请求都无法区分。

这也是第二个印证以下原则的例子：自己构建的软件往往是最薄弱的一环。我们各款产品中的虚拟机监控程序、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 对智能体身份问题给出了具体方案：凭据保留在宿主机的钥匙串中，虚拟机获得一个每会话独立、权限范围受限的令牌，且该令牌可以独立于用户令牌被撤销。不过，我们开始着手应对跨平台智能体身份这一更广泛的问题。智能体应该拥有自己的主体身份，还是应该作为用户的延伸，继承用户的权限？最终答案可能是两者的结合。

随着智能体能力增强，攻击面也在不断变化。我们见过的故障类型，很可能会在不同行业和实验室中重演。我们需要共同投入，提升面向智能体的安全防护水平，从共享基准和披露规范，到通用身份标准和跨厂商红队测试，都是如此。本文重点讨论遏制措施，但这只是智能体安全全貌的一部分。有关治理、可观测性以及技术栈其他部分的内容，请参阅NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 牵头并与 CISA 和英国 NCSC 共同制定的六机构关于采用智能体式 AI 的指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中一项贡献，但我们也期待在这一关键问题上与合作伙伴及竞争对手携手合作。

总结

简而言之，有几条原则是我们反复强调的：

先在环境层设计遏制措施，再在模型层引导行为。让我们收获最多教训的两起事件——针对员工的网络钓鱼事件和第三方白名单披露事件——都属于数据外流，即数据通过获准的路径离开。在这两起事件中，模型层都无能为力，因为没有任何异常可供它捕捉。当所有概率性防线都未能拦截时，最终承受冲击的就是确定性边界。

让隔离强度与用户的监督能力相匹配。能读懂 bash 的开发者与读不懂 bash 的知识工作者，所适用的威胁模型并不相同。用户能否评估智能体即将执行的操作，应当成为确定遏制策略的依据之一；而无论向哪个方向判断失误——给专家设置过多阻碍，或对非专家给予过多信任——本身都是一种失败。

警惕自定义组件。久经考验的虚拟机监控器、系统调用过滤器和容器运行时，经受过的对抗性检验远多于你自行构建的任何东西。在本文描述的每一种部署中，标准基础组件都守住了防线，而我们围绕它们自行开发的部分却暴露出了缺陷。

归根结底，尽管智能体可能是一类新型软件，但它们在系统层面的交互方式并不新鲜。它们仍然要读取文件、打开套接字、创建进程；因此，使用成熟工具对其进行隔离限制，是一种至关重要且切实可行的防御手段。随着 AI 的发展，部署的风险与收益之间的平衡将不断变化，但为影响范围设定硬性上限，往往能推动这种平衡朝着正确的方向发展。