我们如何在各产品中约束 Claude

十二个月前，我们会断然拒绝赋予 Claude 足以关停某个 Anthropic 内部服务的权限这一想法。如今，这种级别的访问权限已成常态，Anthropic 的开发者也因此更加高效。这类部署的风险包含两个方面：故障发生的可能性，以及故障可能造成的损害程度。安全措施和模型训练的进步稳步降低了前者；而后者——理论上的爆炸半径——只会随着能力和访问权限的扩大而增长。然而，随着智能体开始能够完成过去需要一个人甚至一个团队才能完成的工作，不部署它们的代价变得如此之高，以至于只要产品能够做到安全，风险回报的权衡就严重倾向于采用。工程上的问题就变成了如何限制爆炸半径。

大致有两种方法可以做到这一点。

第一种是通过人在回路（human-in-the-loop）来监督智能体的行为。Claude Code 此前通过在每一轮操作时向用户请求许可来防止智能体采取非预期行动。理论上这行得通，但我们发现这种方法存在缺陷。我们的遥测数据显示，用户批准了大约 93% 的权限提示。用户看到的批准请求越多，对每一个的注意力就越少，随着时间的推移，他们在监督上变得远不那么尽责。我们最近构建了 Claude Code 自动模式，它自动执行更安全的批准，以减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性防御都有非零的漏检率。¹

限制爆炸半径的第二种方法——也是本文的重点——是遏制（containment）。我们不是监督智能体做什么，而是监督它能做什么，通过例如沙箱、虚拟机和出站流量控制来强制执行访问边界。这是 Anthropic 工程团队投入最多精力的地方，也是许多最令人意外的安全故障发生的地方。

在过去两年中，我们发布了三个主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每个产品面向不同的受众，需要不同的遏制架构。本文分享了哪些做法经受住了考验，哪些失败了，以及我们在此过程中对智能体安全的所学所得。

三类风险，三重防御

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

用户滥用：用户出于恶意或疏忽，指示智能体做一些有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们不理解的破坏性命令，再到蓄意造成伤害。

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

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

外部攻击者：智能体通过工具、文件或网络访问等外部向量受到攻击。这一类别既包括提示注入，也包括针对智能体运行时、编排层或代理的传统攻击。

在构建遏制和防御系统时，我们将防御应用于三个主要组成部分：

智能体运行的环境。我们通过进程沙箱、虚拟机、文件系统边界和出站流量控制来限制智能体的行动范围和方式。目标是为智能体能够触及的内容设定硬性边界。例如，如果凭据从不进入沙箱，它们就无法被泄露，无论原因是用户、模型找到了一条“有创意”的路径，还是攻击者所为。

严密的边界也意味着你可以放松监督。Claude Code 的参考 devcontainer正是为了让智能体能够在无人值守的情况下运行，无需对每个操作进行审批。

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

这些防御是强大的。在 Gray Swan 的智能体红队测试基准（测试对提示注入的易感性）中，Claude Opus 4.7在单次尝试中将攻击成功率控制在约 0.1%，在 100 次自适应尝试后约为 5–6%。Claude Code 自动模式在执行前拦截了约 83% 的过度积极行为。然而，即使拥有最顶级的防御，模型层的保护也永远不会 100% 有效，这就是为什么它不能单独发挥作用。

智能体能够触及的外部内容。MCP 服务器、第三方插件和网络搜索工具都会从你无法控制的来源向智能体的上下文中输入内容。经过审计的连接器并不等同于经过审计的数据——例如，一个 GitHub 连接器可以在通过恶意软件检查后，直接将被篡改的 README 加载到模型的上下文中。细粒度地限制工具权限有助于限制影响范围。例如，具有只读数据库访问权限的智能体可以比能够写入生产环境的智能体部署得广泛得多。

防御措施应当相互重叠、互为补充。当环境层防御不可用时，模型层就必须补位（这正是 Claude Code 的 auto mode 所设计的目的）。在本地，环境和模型防御可以抵御恶意工具输出，但也可以通过限制工具的能力和访问权限，在链条的更高层级增加防御。

约束智能体的模式

聚焦环境层，我们描述了三种隔离模式，以及它们如何针对每个 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 和网络。如果没有这些，编码智能体的用处就很有限，因此必须找到一种安全授予这些访问权限的方法。

一种方法是依赖人在回路中（human-in-the-loop）。这之所以对 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。此时载荷已经无处不在。我们在该讨论串中添加了一个 金丝雀字符串，以便一旦有东西拾取了它我们就能察觉。在一个智能体读取一切的世界里，调查工具本身也是攻击面。）

模式三：本地虚拟机（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 客户端的请求无法区分。

这再次印证了一个原则：你自己构建的软件往往是最薄弱的环节。我们各产品中的 hypervisor、seccomp 和 gVisor 一直都很可靠，出问题的恰恰是我们自定义的允许列表代理。

我们遗漏的风险：虚拟机隔离同样将终端检测软件拒之门外

在评估 Claude Cowork 时，企业安全团队会问：“为什么我们的 EDR 看不到内部？”答案是，将 Claude 困在其中的同一套隔离机制，也把基于主机的终端检测与响应（EDR）挡在了外面。在 EDR 看来，Claude Cowork 只是一个不透明的 hypervisor 进程，它无法检查客户机内部。

隔离降低了可见性，而对于合规态势依赖于终端可见性的团队来说，这种不透明性是个问题。我们目前的缓解措施是使用拉取式的 OTLP 导出，让管理员事后检索事件日志，但这与实时监控不同。如果你正在构建类似系统，请尽早为这场对话预留预算。

信任智能体读取的内容

企业经常问我们如何保护 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 的开发者和不能的普通知识工作者，其面临的威胁模型是不同的。用户是否能够评估智能体即将执行的操作，这一问题应有助于确定遏制策略，而在任一方向上判断错误——对专家来说摩擦过多，对非专家来说信任过多——本身就是一种失败。

警惕自定义组件。经过实战检验的虚拟机监控程序、系统调用过滤器和容器运行时，所经受的对抗性关注远超你将构建的任何东西。在本文所述的每一次部署中，标准原语都经受住了考验，而我们围绕它们所做的工作反而暴露了缺陷。

总而言之，虽然智能体可能是一个新的软件类别，但它们的系统级交互并非新事物。它们仍然会读取文件、打开套接字并生成进程；这使得使用成熟工具进行隔离成为一种至关重要的可行防御手段。随着人工智能的发展，部署的风险回报平衡将不断变化，但对爆炸半径施加硬性限制通常会将这种平衡推向正确的方向。