跨产品如何控制Claude：环境隔离与爆炸半径管理

跨产品如何控制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的Agent红队基准测试中（测试对提示注入的敏感性），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。载荷现在存在于环境中。我们在线程中添加了一个蜜罐字符串，以便注意到是否有任何东西拾取它。在一个代理读取一切的世界里，调查工具本身也是攻击面。）

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

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

因此，人机协同沙箱策略可能不适用；非技术知识工作者不应被期望判断诸如find . -name "*.tmp" -exec rm {} \;这样的bash咒语。当批准异常需要典型用户不具备的专业知识时，管理员应当设定一个绝对且始终打开的边界。

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

在原始架构中——我们称之为全虚拟机模式——代理循环本身在客户端内运行，因此Claude作为一个普通Linux用户执行，没有意识到自己被沙箱化。相比之下，Claude Code中有一个特权进程位于沙箱之外，决定每个命令是否执行；一个有说服力的注入提示或一次疲劳的批准点击可以让该进程运行未沙箱化的内容。在这里，没有外部进程持有逃生按钮，因此没有任何组件有权授予例外。

Claude Cowork虚拟机的六种主要隔离机制。其中两种在客户端内核之外强制执行，因此即使代理在虚拟机内达到root级访问权限也能存活。其他四种由客户端强制执行，并且故意保持最小化，因为外层承担了其余部分。

然而，我们很快意识到在全虚拟机模式下运行整个代理会导致实际问题：虚拟机启动期间的任何故障都会使Cowork无法使用。将代理循环移出虚拟机，同时将代码执行保留在虚拟机内，使得Claude仍然可以响应用户并帮助调试问题，而不是在错误时冻结。这一变化对安全影响最小，因为虚拟机仍然对代理执行的代码强制执行文件系统和网络控制。

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

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

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

我们遗漏的风险：通过已批准域名的窃取

一个通过已批准域名窃取的清晰例子来自第三方披露。Claude Cowork的出口白名单正确放行了发往api.anthropic.com的流量——产品必须调用我们自己的API才能运行。在这个案例中，一个恶意文件被放置到用户挂载的工作区中，其中包含隐藏指令以及攻击者控制的API密钥。Claude遵循指令，读取工作区中的其他文件，并使用攻击者的密钥调用Anthropic的Files API。出口代理检查了目标地址，看到api.anthropic.com，就放行了。文件被上传到攻击者的Anthropic账户。沙箱工作完美，但数据仍然被窃取。

之前，我们将白名单概念化为一个目标过滤器，告诉Claude这些域名可以通信。但或许更好的概念化是能力授予。白名单上任何域名可访问的每个函数现在都是攻击面。允许api.anthropic.com意味着允许向任意Anthropic账户上传文件。

我们通过在虚拟机内设置一个防御性中间人代理来拦截发往我们API的流量进行修复。它只传递携带虚拟机自身预配会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。代理还阻止会启用服务器端获取的头部。代理位于虚拟机内部而不是我们的服务器上，因为只有虚拟机知道来源——从服务器的角度看，Cowork请求与其他任何API客户端无法区分。

上：发往api.anthropic.com的流量被放行，导致出口。下：使用中间人代理拦截发往我们API的流量的修复。

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

我们遗漏的风险：虚拟机隔离也挡住了端点检测软件

在评估Claude Cowork时，企业安全团队问道：“为什么我们的EDR看不到内部？”答案是，用于隔离Claude的同一个隔离措施也挡住了基于主机的端点检测。从EDR的视角看，Claude Cowork是一个不透明的虚拟机管理程序进程。它无法检查客户端。

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

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

信任代理读取的内容

企业经常问我们如何保护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的开发者和不能读懂的知识工作者面临不同的威胁模型。用户是否能够评估代理即将采取的行动应该帮助决定隔离策略，而回答错误——对专家来说太多摩擦，对非专家来说太多信任——本身就是一种失败。

- 警惕自定义组件。 经过实战考验的虚拟机管理程序、系统调用过滤器和容器运行时比你将构建的任何东西经受住了更多的对抗性关注。在本文描述的每个部署中，标准原语一直可靠，而围绕它们构建的自有组件暴露了缺陷。

归根结底，虽然代理可能是一种新类别的软件，但它们与系统级别的交互并非全新。它们仍然读取文件、打开套接字、生成进程；这使得使用成熟工具进行隔离成为一种至关重要的可行防御。随着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产品漏洞的个人和组织。

---

¹ Claude Code自动模式将命令批准委托给基于模型的分类器；它最小化摩擦（大约0.4%的良性命令被阻止），代价是遗漏一小部分风险命令（约17%的过度积极操作未被捕获），因此它是沙箱内深度防御的一层，而非替代品。