Anthropic 如何通过多层隔离限制 Claude 代理的爆炸半径

获取开发者通讯产品更新、操作指南、社区亮点等。每月发送到您的收件箱。十二个月前，我们曾断然拒绝让 Claude 拥有足以摧毁 Anthropic 内部服务的访问权限。如今，这种级别的访问已是常态，Anthropic 的开发人员也因此效率更高。

这些部署的风险包含两个部分：故障发生的可能性，以及可能造成的损害程度。保障措施和模型训练的进展稳步降低了前者；而后者——理论上的爆炸半径——只会随着能力和访问范围的扩大而增长。

然而，当智能体能够完成曾经需要一个人甚至一个团队才能完成的工作时，不部署的成本变得足够高，只要产品能够确保安全，风险回报的计算就会强烈倾向于采用。工程问题变成了如何限制爆炸半径。大致有两种方法。

第一种是通过人在回路中监督智能体的行为。Claude Code 之前通过每次请求用户许可来防止智能体采取意外行动。理论上可行，但我们发现这种方法容易出错。我们的遥测数据显示，用户批准了大约 93% 的权限提示。

用户看到的批准越多，对每个批准的关注就越少，随着时间的推移，他们的监督会变得不那么勤勉。

我们最近构建了 Claude Code 自动模式，该模式可以自动执行更安全的审批，以减少这种审批疲劳。尽管如此，漏洞仍然存在——任何概率性防御都有非零的漏报率。限制爆炸半径的第二种方法——也是本文大部分内容的焦点——是遏制。

我们不是监督智能体做什么，而是通过强制执行访问边界来监督它能做什么，例如通过沙箱、虚拟机和出口控制。这是 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——量身定制。

我们逐步完成了每个设计，在智能体所需的能力和用户所需的干预程度之间找到了平衡。虽然最出名的是聊天界面，但 claude.ai 也编写和运行代码、生成文件并调用连接器。

当 Claude 在 claude.ai 内部运行代码时，它是在隔离基础设施上的 gVisor 容器中进行的。智能体完全是服务器端的；本地机器上不运行代码，文件系统是临时的（每个会话）。

爆炸半径很小，但 Claude 能做的事情的上限也很小——没有持久工作空间，也无法访问用户的文件系统。这也使得 claude.ai 受更传统的威胁模型影响。我们不是在保护用户机器免受智能体侵害；

我们是在保护自己的基础设施和每个租户免受彼此侵害。我们为 claude.ai 做的发布前工作主要由传统安全工作主导，如网络配置、内部服务认证和编排。这项工作强化了安全领域最古老的教训：最薄弱的层是你自己构建的那一层。

gVisor 和 seccomp 针对资源充足的对手的加固时间远长于智能体 AI 存在的时间，因此审查工作转向了我们围绕它们构建的新组件。我们稍后会回到这一点，因为我们的自定义代理也是在我们最严重的事件中崩溃的部分。

Claude Code 在用户的机器上运行，并可以访问他们的文件系统、shell 和网络。没有这一点，编码智能体的用处有限，因此必须找到一种方法来安全地授予该访问权限。一种方法是依靠人在回路中。

这对 Claude Code 来说是一个可行的解决方案，因为普通用户是熟悉编码环境的开发者：他们能读 bash，他们理解 rm -rf 的作用，并