十二个月前，我们会断然否决让 Claude 拥有足以搞垮 Anthropic 某项内部服务的权限。如今这种级别的权限已是家常便饭，Anthropic 的开发者也因此效率更高。这类部署的风险包含两个部分：失败发生的可能性有多大，以及一次失败能造成多大的破坏。防护措施和模型训练方面的进展已持续压低了前者；而后者，即理论上的爆炸半径，则随着能力和权限的扩大只增不减。然而，当智能体能够完成过去需要一个人甚至一个团队才能完成的工作时，不部署的代价就会大到让风险与收益的天平明显倒向采用，前提是产品能够做到安全。于是，工程上的问题就变成了如何限制爆炸半径。
大致有两种办法。
第一种是通过人在回路（human-in-the-loop）来监督智能体的行为。Claude Code 此前通过在每一轮向用户请求许可，来防止智能体采取非预期的操作。理论上这行得通，但我们发现这种方式并不可靠。我们的遥测数据显示，用户批准了大约 93% 的权限提示。用户看到的批准请求越多，对每一条的注意力就越少，监督也会随着时间推移变得松懈得多。我们最近构建了 Claude Code 自动模式（auto mode），它能自动处理更安全的批准，以减轻这种批准疲劳。不过漏洞依然存在，任何概率性的防御都有非零的漏判率。1
限制爆炸半径的第二种方法，也是本文的重点，是隔离（containment）。我们不去监督智能体做了什么，而是通过沙箱、虚拟机和出站流量控制等手段强制设定访问边界，监督它能够做什么。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% 的过度积极行为执行之前将其拦截。然而，即便拥有一流的防御，模型层的保护也永远不可能百分之百有效，所以它不能单独依赖。
智能体能够接触到的外部内容。MCP 服务器、第三方插件和网络搜索工具，都会把来自你无法掌控的来源的内容送入智能体的上下文。经过审计的连接器并不等于经过审计的数据，例如，GitHub 连接器即便通过了恶意软件检查，也可能把一份被投毒的 README 直接加载进模型的上下文。精细地限制工具权限有助于缩小爆炸半径。例如，只有数据库只读权限的智能体，可以比能写入生产环境的智能体部署得广泛得多。
各层防御应当相互重叠、彼此补充。当环境层防御不可用时，模型层必须补上缺口（这正是 Claude Code 自动模式的设计目的）。在本地，环境和模型层防御可以抵御恶意的工具输出，但还可以通过限制工具的能力和权限，在链路更上游增加防御。
隔离智能体的几种模式
我们聚焦于环境层，介绍三种隔离模式，以及它们如何针对 Claude 的各个平台（claude.ai、Claude Code 和 Cowork）量身定制。每一种设计都是逐步形成的，我们要在智能体所需的能力与用户所需介入的程度之间找到平衡。
模式一：临时容器（claude.ai 代码执行）
claude.ai 最为人所知的是聊天界面，但它同样会编写并运行代码、生成文件、调用连接器。Claude 在 claude.ai 中运行代码时，是在隔离基础设施上的 gVisor 容器里完成的。智能体完全运行在服务端，本地机器上不运行任何代码，文件系统也是临时的（按会话划分）。爆炸半径极小，但 Claude 能做的事情的上限也随之降低：没有持久化的工作区，也无法访问用户的文件系统。
这也使得 claude.ai 适用更传统的威胁模型。我们要保护的不是用户的机器免受智能体侵害，而是我们自己的基础设施，以及各租户之间互不侵扰。我们在 claude.ai 上线前的工作主要是网络配置、内部服务认证和编排等传统安全工作。
这些工作印证了安全领域最古老的教训：最薄弱的一层，就是你自己构建的那一层。gVisor 和 seccomp 经受资源雄厚的对手考验的时间，远比智能体式 AI 存在的时间长，因此审查精力都放在了我们围绕它们新构建的部分上。稍后我们会回到这一点，因为我们的自定义代理，正是在最严重的一次事故中出问题的组件。
模式二：人在回路沙箱（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。这样一来，攻击载荷就成了环境中随处可及的东西。我们在该帖子里加了一个金丝雀字符串，以便在有任何东西读取它时能够察觉。在智能体什么都读的世界里，调查工具本身也是一个攻击面。）
模式三：本地虚拟机（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 有一个特权进程位于沙箱之外，逐条命令地决定是否强制执行沙箱；一条有说服力的注入提示词，或者一次疲劳状态下的批准点击，就可能让该进程运行未经沙箱隔离的东西。而在这里，没有持有逃生钥匙的外部进程，因此也就没有任何组件有权批准例外。
不过，我们很快意识到，在完整虚拟机模式下运行整个智能体会带来实际问题：虚拟机启动期间的任何故障都会让 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 账户上传文件。
我们的修复方法是在虚拟机内部部署一个防御性的中间人代理，拦截发往我们 API 的流量。它只放行携带虚拟机自身预置会话令牌的请求；攻击者嵌入的密钥会被代理拒绝。它还会拦截可启用服务端抓取的请求头。代理放在虚拟机内而不是我们的服务器上，是因为只有虚拟机知道请求的来源：从服务器的角度看，Cowork 的请求与任何其他 API 客户端的请求无从区分。
这也是“你自己构建的软件往往最薄弱”这一原则的第二个例证。我们各产品中的虚拟机监控程序、seccomp 和 gVisor 一直可靠。出问题的是我们自定义的允许列表代理。
我们漏掉的风险：虚拟机隔离也把端点检测软件挡在了外面
在评估 Claude Cowork 时，企业安全团队问道：“为什么我们的 EDR 看不到里面？”答案是，让 Claude 被隔离住的同一套隔离机制，也把基于宿主机的端点检测与响应（EDR）挡在了外面。在 EDR 看来，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 指南，以及 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% 的过度积极操作会被放行），所以它只是沙箱内纵深防御的一层，而不能替代沙箱。