我们如何在各产品中管控Claude：隔离策略与安全教训

我们如何在各产品中管控Claude

十二个月前，我们曾断然拒绝让Claude拥有足以瘫痪Anthropic内部服务的访问权限。如今，这种级别的访问已是常规操作，Anthropic的开发者也因此效率更高。这些部署的风险包含两个部分：故障发生的可能性，以及可能造成的破坏程度。防护措施和模型训练的进步持续降低了前者；而后者——理论上的爆炸半径——只随着能力和访问权限的扩展而增长。然而，当代理能够完成曾经需要一个人甚至一个团队才能完成的工作时，不部署的成本变得足够大，只要产品能够保证安全，风险-收益的计算就会大幅倾向于采纳。工程问题就成了如何限制爆炸半径。

当自主代理的相对破坏程度可以被限制时——例如通过控制其环境——高实用性的能力就能推动部署。Claude Mythos Preview 是一个例子：其模型的爆炸半径在2026年4月被认为过高而无法发布。然而，我们预计随着防御方加固关键系统且防护措施日趋成熟，同等能力水平的模型将更广泛地发布——尽管某些风险始终存在。模型能力是代理部署总风险中的一个重要因素。

实现这一点大致有两种方式。

第一种是通过人工介入来监督代理的行为。Claude Code 此前通过在每一步要求用户许可来防止代理采取非预期的操作。理论上这可行，但我们发现这种方法有缺陷。我们的遥测数据显示，用户批准的许可提示约占93%。用户看到的批准越多，对每个批准的关注就越少，随着时间的推移，他们在监督上变得远不那么尽职。我们最近构建了 Claude Code 自动模式，它自动化了更安全的批准流程以减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性防御都有非零的漏报率。1

第二种限制爆炸半径的方法——也是本文的重点——是隔离。与其监督代理做什么，不如通过强制访问边界来监督它能够做什么，例如通过沙箱、虚拟机和出站控制。这是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的漏洞报告。其中三个漏洞利用了用户在同意任何操作之前就已执行的代码。要理解这是如何可能的，考虑最直接的情况：一名开发者克隆了一个仓库以审查拉取请求，该仓库包含一个 .claude/settings.json，其中定义了一个钩子。由于Claude Code在启动期间读取项目设置——在展示标准的“你信任此文件夹吗？”提示之前——攻击者编写并提交的钩子会自动执行。其余案例结构类似，在信任边界建立之前，来自尚未被信任目录的输入就被解析了。

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

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

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 framework，Windows上的HCS）在完整虚拟机内运行。虚拟机有自己的Linux内核、自己的文件系统、自己的进程表。用户选定的工作区和 .claude 文件夹被挂载；主机上的其他内容不可见。凭据留在主机的钥匙串中，从不进入客户机。这种设计防范了Claude在某个时刻表现出错误行为的可能性。被攻破的Claude仍然可能损坏工作区文件夹内的内容，因此架构设计确保那是它唯一能触及的东西（直到用户添加连接器），并且用户控制挂载的内容。

在原始架构中——我们称之为全虚拟机模式——代理循环本身在客户机内运行，因此Claude作为一个普通的Linux用户执行，不知道它被沙箱隔离。相比之下，在Claude Code中，一个特权进程位于沙箱外部，决定每个命令是否强制执行；一个说服性的注入提示或疲劳的批准点击可以使该进程运行未沙箱化的内容。而这里，没有外部进程持有逃生舱钥匙，因此没有任何组件拥有授予例外的权限。

Claude Cowork虚拟机的六个主要隔离机制。其中两个在客户机内核之外强制执行，因此即使代理在虚拟机内获得根级访问权限，它们依然有效。其他四个是客户机强制执行的，并保持最小化，因为外层承担了其余的重担。

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

另外，我们还将本地MCP服务器移到了虚拟机外部。在虚拟机内部运行它们使得审计更困难，当虚拟机更新时造成脆弱的依赖问题，并且不支持需要与本地进程（如数据库）交互的MCP——此类服务器无论如何都必须在主机上运行。这一变化使Claude Cowork与本地MCP服务器在Claude Desktop中的工作方式一致：将它们视为用户可能选择安装的任何软件，并委托管理员决定启用哪些本地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时，企业安全团队问：“为什么我们的端点检测和响应无法看到内部？”答案是，隔离Claude的同一机制也将基于主机的端点检测和响应拒之门外。从端点检测和响应的角度来看，Claude Cowork是一个不透明的虚拟化管理程序进程。它无法检查客户机。

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

| 环境 | 临时容器 (claude.ai) | 人工介入沙箱 (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的指南，以及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, 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%的良性命令被阻止），因此它是沙箱内深度防御的一层，而不是替代品。