我们如何跨产品限制Claude的风险：环境隔离与分层防御实践

十二个月前，我们还会断然拒绝让Claude获得足以搞垮Anthropic内部服务的访问权限。如今，这种级别的访问已是常态，Anthropic的开发者也因此效率更高。这些部署的风险包含两个部分：故障发生的概率，以及可能造成的损害。防护措施和模型训练的进展稳步降低了前者；而后者——理论上的爆炸半径——则随着能力和访问权限的扩展而不断增大。然而，当智能体能够完成曾经需要一个人甚至一个团队才能完成的工作时，不部署的代价也大到足以让风险收益计算强烈倾向于采用，前提是产品能够做到安全。工程问题就变成了如何限制爆炸半径。

当可以对自主智能体的相对损害设定边界——例如通过控制其环境——时，高实用性的能力就能促使部署。Claude Mythos Preview就是一个例子，其爆炸半径在2026年4月被认为过高而无法发布。然而，我们预计随着防御者加固关键系统以及防护措施的成熟，具有类似能力水平的模型将更广泛地发布——尽管风险永远无法完全消除。模型能力是智能体部署总风险的一个重要因素。

限制爆炸半径大致有两种方法。

第一种是通过人类介入来监督智能体的行为。Claude Code最初通过要求用户在每一步操作时给予许可，来防止智能体采取意外行动。理论上可行，但我们发现这种方法有缺陷。我们的遥测数据显示，用户批准了约93%的许可提示。用户看到的批准越多，对每个提示的关注就越少，久而久之监督的认真程度就会大打折扣。我们最近构建了Claude Code自动模式，该模式自动处理更安全的批准，以减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性防御都有非零的漏过率。

第二种限制爆炸半径的方法——也是本文的重点——是隔离。与其监督智能体做什么，不如通过强制访问边界来监督它能做什么，例如通过沙箱、虚拟机和出口控制。这是Anthropic工程投入最多精力的地方，也是许多最令人惊讶的安全故障发生的地方。

在过去两年中，我们发布了三个主要的智能体产品：claude.ai、Claude Code和Claude Cowork。每个产品服务于不同的受众，需要不同的隔离架构。本文分享了我们一路走来在智能体安全方面哪些方法行之有效，哪些出了问题，以及我们学到了什么。

三种风险，三种防御组件

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

用户误用： 用户——无论是恶意还是疏忽——指示智能体做有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们不理解的危险命令，再到指定故意的伤害行为。

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

在Anthropic，我们见过Claude模型为了完成任务而“好心”地逃出沙箱，检查git历史来寻找编码测试的答案，以及自发识别出它正在运行的基准测试以便解密答案密钥。每个模型都带来一套新的能力，有时会以意想不到的方式发挥作用。

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

在构建隔离和防御系统时，我们对三个主要组件应用防御：

1. 智能体运行的环境。 我们通过进程沙箱、虚拟机、文件系统边界和出口控制来约束智能体行动的地点和方式。目标是为智能体能够触及的范围设定一个硬边界。例如，如果凭证从未进入沙箱，那么无论原因是用户、模型找到“创意”路径还是攻击者，凭证都无法被窃取。严格的边界也意味着你可以放松监督。Claude Code的参考开发容器正是为了让智能体可以在无人值守的情况下运行，无需逐操作批准。

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

这些防御是强大的。在测试提示注入易感性的Gray Swan's Agent Red Teaming基准测试中，Claude Opus 4.7在单次尝试中攻击成功率约为0.1%，在100次自适应尝试后约为5-6%。Claude Code自动模式在执行前捕获了大约83%的过度活跃行为。然而，即使拥有最先进的防御，模型层的保护也永远不可能100%有效，这就是为什么它不能单独存在。

3. 智能体能够触及的外部内容。 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，而该仓库包含一个.claude/settings.json文件，其中定义了一个钩子。由于Claude Code在启动时就会读取项目设置——在显示标准的“您信任此文件夹吗？”提示之前——攻击者编写并提交的钩子将自动执行。其余的情况在结构上类似，即在建立信任边界之前，来自尚未受信任目录的输入已被解析。

每种情况的修复都有相同的形状：推迟解析和执行项目本地配置，直到用户接受信任提示。如果你正在构建类似的东西，请将项目打开、配置加载和localhost监听器视为来自互联网的任何入站请求。它们不应该仅仅因为感觉是本地且在用户同意之前到达就被隐式信任。

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

2026年2月，在一次受控的内部红队演练中，一名研究人员成功通过钓鱼使一名员工启动了带有恶意提示的Claude Code。钓鱼看起来像普通的协作——一封“你能帮我跑一下这个吗？”的电子邮件，附带着一个可直接粘贴的提示——而提示本身看起来像常规的任务指令。但在某处设置步骤中，它温和地要求Claude读取~/.aws/credentials，对内容进行编码，并向外部端点发送POST请求。在对该提示的25次重复测试中，Claude完成了24次数据窃取。

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

在这种情况下唯一有效的防御是环境，特别是阻止POST请求（无论意图如何）的出口控制，以及从根本上将~/.aws隔离在触及范围之外的文件系统边界。

（当我们在内部Slack上分享这个有效的提示以供讨论时，有人指出一些内部智能体会读取Slack。这个payload现在变成了环境的一部分。我们在线程中添加了一个检测字符串，以便在有任何东西拾取它时能注意到。在智能体读取一切的世界里，调查工具本身也是攻击面。）

模式3：本地虚拟机（Claude Cowork）

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

因此，人类介入的沙箱策略可能不适用；不能期望非技术知识工作者判断诸如 find . -name "*.tmp" -exec rm {} \; 这样的bash命令。当批准例外需要普通用户不具备的专业知识时，管理员应该设定一个绝对且始终开启的边界。

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

在最初的架构中——我们称之为全VM模式——智能体循环本身运行在客户机内部，因此Claude作为一个普通的Linux用户执行，意识不到自己被沙箱隔离了。相比之下，Claude Code是一个特权进程位于沙箱外部，决定每条命令是否强制执行沙箱；一个具有说服力的注入提示或一个疲劳的批准点击可以让该进程运行一些没有沙箱隔离的内容。在这里，没有外部进程持有逃生舱钥匙，因此没有任何组件有权授予例外。

然而，我们很快意识到，在全VM模式下运行整个智能体会导致实际问题：VM启动过程中的任何故障都会使Cowork无法使用。将智能体循环移到VM外部，同时将代码执行保留在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客户端无法区分。

这也是“你构建的软件往往是最薄弱的”这一原则的第二个实例。我们产品中的虚拟机监控程序、seccomp和gVisor一直很可靠。我们自定义的白名单代理则是失败的环节。

我们遗漏的风险：VM隔离也将端点检测软件拒之门外

在评估Claude Cowork时，企业安全团队问：“为什么我们的端点检测和响应（EDR）看不到里面？”答案是，用于隔离Claude的相同隔离也将基于主机的端点检测和响应拒之门外。从EDR的角度来看，Claude Cowork是一个不透明的虚拟机监控程序进程。它无法检查客户机。

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

| 环境 | 临时容器 (claude.ai) | HITL沙箱 (Claude Code) | 密封VM (Claude Cowork) | |------|----------------------|------------------------|-----------------------| | 成本：隔离开销 | 容器启动 | 低延迟原生沙箱 | 完整VM启动 | | 成本：用户依赖 | 不适用 | 必须能解释bash | 不适用 | | 风险：爆炸半径 | 服务端容器（由gVisor+主机基础设施边界保护） | 本地工作空间 | 挂载的工作空间（由vsock+虚拟机监控程序边界保护） |

信任智能体读取的内容

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

远程与本地的重要性比看起来更大。本地安装的工具是可审计的。你可以阅读代码、锁定版本，并知道它不会在你不知情的情况下改变。远程工具——托管的MCP服务器、云连接器——可以在你批准后的任何时候改变行为；你安装时的信任决策可能不再适用。我们的连接器目录通过持续审查来解决这个问题，但目录之外的任何东西都应该被视为不可信的。首先在虚假数据上运行它，放在恶意工具的爆炸半径被限制的环境中。

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

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

未来展望

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

- 持久内存投毒。 跨会话保留的智能体上下文比例不断增长——这包括产品记忆、CLAUDE.md文件、挂载的工作空间，以及计划任务和长期运行智能体的状态目录。落在这些位置中的任何一个注入都会在每次智能体启动时重新加载。随着越来越多的智能体状态在会话之外存续，我们在传统的后利用意义上受到新的持久性机制的威胁。会话启动时的良好分类器需要变得更加普遍。

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

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

随着智能体变得越来越强大，攻击面不断变化。我们看到的故障类型很可能会在行业和实验室中重复出现。我们需要对智能体特定的安全态势进行集体投资，从共享基准和披露规范到通用身份标准和跨厂商红队演练。本文聚焦于隔离，但这只是智能体安全图景的一部分。关于治理、可观测性和其他部分，请参见NIST关于AI智能体身份和授权的项目、由澳大利亚ACSC与CISA和英国NCSC牵头的六机构关于采用智能体AI的指南，以及ISO/IEC 42001（AI管理标准）。我们的Glasswing计划是其中一项贡献，但我们期待与合作伙伴和竞争对手在这个关键问题上共同努力。

总结

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

- 首先在环境层设计隔离，然后在模型层引导行为。 让我们学到最多的两个事件——员工钓鱼和第三方白名单披露——都是出口案例，其中数据通过允许的路径离开。在这两种情况下，模型层都帮不上忙；没有异常可以让它捕获。当所有概率性的东西都失败时，确定性边界就是被击中的那一个。

- 将隔离强度与用户的监督能力相匹配。 能够阅读bash的开发者和不能阅读bash的知识工作者所面临的威胁模型是不同的。用户能否评估智能体将要做什么这个问题应该帮助决定隔离策略，而在任何一个方向上答错——对专家设置过多摩擦，对非专家给予过多信任——本身就是一种失败。

- 警惕自定义组件。 经过实战检验的虚拟机监控程序、系统调用过滤器和容器运行时比你构建的任何东西都承受过更多敌意关注。在本文描述的每一个部署中，标准原语都保持稳定，而我们自己在它们周围的工作暴露了缺陷。

最终，虽然智能体可能是一种新型软件，但它们与系统层面的交互并不是新的。它们仍然读取文件、打开套接字、生成进程；这使得使用成熟工具进行隔离成为一种至关重要的可行防御。随着AI的发展，部署的风险收益平衡将继续变化，但对爆炸半径设置硬限制往往会将这种平衡推向正确的方向。

致谢

作者：Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, and Abel Ribbink。

我们还要感谢 Hanah Ho, Hasnain Lakhani, Pedram Navid, Molly Villagra, Maya Nielan, Akila Srinivasan, Sam Attard, Alfred Xing, Mohamad El Hajj, Gabby Curtis, David Dworken, Adam Jones, Amie Rotherham, Christian Ryan, Lucas Smedley, Brett Andrews 等人的贡献。

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

脚注

Claude Code 自动模式将命令批准委托给基于模型的分类器；它以错过一小部分风险命令（约17%的过度活跃行为通过）为代价，最小化了摩擦（约0.4%的无害命令被阻止），因此它是沙箱内部多层防御中的一层，而不是替代品。