跨产品限制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的参考开发容器正是为了让智能体可以在无人看管的情况下运行，无需逐个操作授权。

智能体咨询的模型。这里的机制包括系统提示、分类器、探针和训练修改。由于模型是概率性的，这些机制只能塑造智能体倾向做什么，而不能限制其在理论上能够做什么。这些防御很强大。在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：本地虚拟机（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与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导出，让管理员事后检索事件日志，但这与实时监控不同。如果你构建类似的东西，请尽早为这个对话做好准备。

信任智能体读取的内容

企业经常问我们如何保护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, Travis Szucs, 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%的无害命令被阻止），因此它是沙箱内深度防御的一层，而不是替代方案。