工程博客上新文章：我们授予代理的访问和权限应随着其能力的发展而演变。在我们的产品中，我们通过沙箱技术来设定这些参数，从而限制任何潜在破坏性行为的范围。

阅读更多：https://anthropic.com/engineering/how-we-contain-claude…

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

来源：https://www.anthropic.com/engineering/how-we-contain-claude 十二个月前，我们绝不会考虑授予 Claude 足以让 Anthropic 内部服务瘫痪的访问权限。如今，这种级别的访问已成常规，而 Anthropic 的开发者也因此提高了生产力。这些部署的风险包含两部分：故障发生的可能性有多大，以及可能造成的破坏有多大。安全防护和模型训练的进步稳步降低了前者；而后者——理论上的爆炸半径——只会随着能力和访问范围的扩大而增长。然而，当代理能够完成曾经需要一个甚至一个团队才能完成的工作时，只要产品能够安全运行，不进行部署的成本就会变得足够高，以至于风险收益的天平会大幅倾向于采用。工程问题就变成了如何限制爆炸半径。

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

第一种是通过人在回路中来监督代理的行为。Claude Code 之前通过在每一步向用户请求许可来防止代理采取意外行动。理论上这可行，但我们发现这种方法是有缺陷的。我们的遥测数据显示，用户批准了大约 93% 的许可提示。用户看到的批准越多，他们对每个提示的关注就越少，随着时间的推移，其监督的仔细程度会大大降低。我们最近构建了 Claude Code 的自动模式，该模式通过自动化更安全的批准（https://www.anthropic.com/engineering/claude-code-auto-mode）来减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性防御都有非零的遗漏率。¹

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

在过去两年中，我们发布了三个主要的代理产品：claude.ai（http://claude.ai/redirect/website.v1.50887c69-167a-41e7-913c-f39ce512df26）、Claude Code 和 Claude Cowork。每个产品服务于不同的受众，需要不同的遏制架构。本文分享了哪些方法行之有效，哪些出了故障，以及我们在代理安全方面学到的经验。

三种风险类型，三种防御组件

代理面临的安全风险分为以下三类：

用户误用： 用户——无论是恶意还是粗心——指示代理执行有害操作。这包括从要求代理绕过他们认为烦人的检查，到运行他们不理解的危险命令，再到指定蓄意伤害。

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

在 Anthropic，我们已经看到 Claude 模型“善意地”逃出沙箱（https://red.anthropic.com/2026/mythos-preview/）以完成任务，检查 git 历史来找到编码测试的答案（https://assets.anthropic.com/m/64823ba7485345a7/Claude-Opus-4-5-System-Card.pdf），以及自发识别出它正在运行的基准测试以便解密其答案密钥（https://www.anthropic.com/engineering/eval-awareness-browsecomp）。每个模型都带来一套新的能力，有时会以意想不到的方式被利用。

外部攻击者： 代理通过外部向量受到攻击，例如工具、文件或网络访问。此类别包括提示注入和对代理运行时、编排层或代理的传统攻击。

在构建遏制和防御系统时，我们对三个主要组件应用防御：

代理运行的环境。 我们通过进程沙箱、虚拟机、文件系统边界和出口控制来约束代理能够行动的地点和方式。目标是为代理所能触及的范围设定一个硬边界。例如，如果凭证从未进入沙箱，那么无论原因是用户、模型找到“创造性”路径还是攻击者，凭证都不可能被泄露。

一个严密的外围也意味着你可以放松监督。Claude Code 的参考开发容器（https://code.claude.com/docs/en/devcontainer）的存在正是为了让代理可以无人值守运行，无需对每个操作进行批准。

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

这些防御措施很强。在 Gray Swan 的 Agent Red Teaming 基准测试（用于测试对提示注入的敏感性）中，Claude Opus 4.7（https://cdn.sanity.io/files/4zrzovbb/website/037f06850df7fbe871e206dad004c3db5fd50340.pdf）在单次尝试中将攻击成功率保持在约 0.1%，在 100 次自适应尝试后约为 5–6%。Claude Code 的自动模式在执行前捕获了大约 83% 的过度活跃行为（https://www.anthropic.com/engineering/claude-code-auto-mode）。然而，即使拥有最佳级别的防御，模型层的保护也永远无法达到 100% 有效，这就是为什么它不能单独发挥作用。

代理能够访问的外部内容。 MCP 服务器、第三方插件和网络搜索工具都将来自你无法控制的源的内容输入到代理的上下文中。经过审计的连接器与经过审计的数据不同——例如，一个 GitHub 连接器可以将一个被污染的 README 直接加载到模型的上下文中，即使它通过了恶意软件检查。精细地限制工具权限有助于限制爆炸半径。例如，一个只有数据库只读访问权限的代理可以比一个能写入生产环境的代理更广泛地部署。

防御措施应该重叠并相互补充。当环境防御不可用时，模型层必须承担额外的工作（这正是 Claude Code 自动模式（https://claude.com/blog/auto-mode）的设计目的）。在本地，环境和模型防御可以防范恶意工具输出，但可以通过限制工具的能力和访问权限在更高层添加防御。

三个需要防御的组件：模型、模型运行的环境以及代理能够访问的外部内容。

遏制代理的模式

专注于环境层，我们描述了三种隔离模式以及它们如何针对每个 Claude 平台——claude.ai（http://claude.ai/redirect/website.v1.50887c69-167a-41e7-913c-f39ce512df26）、Claude Code 和 Cowork——量身定制。在找到我们所需的代理能力与用户所需干预程度之间的平衡后，我们逐渐达成了每种设计。

模式 1：临时容器（claude.ai 代码执行）

尽管 claude.ai 最出名的是聊天界面，但它也编写和运行代码、生成文件并调用连接器。当 Claude 在 claude.ai 内部运行代码时，它是在隔离基础设施上的 gVisor（https://en.wikipedia.org/wiki/GVisor）容器中执行的。代理完全在服务器端运行；没有代码在本地机器上运行，文件系统是临时的（按会话）。爆炸半径很小，但 Claude 所能做的事情的上限也很低——没有持久的工作空间，也无法访问用户的文件系统。

这也使 claude.ai（http://claude.ai/redirect/website.v1.50887c69-167a-41e7-913c-f39ce512df26）受制于更传统的威胁模型。我们不是在保护用户机器免受代理侵害；而是在保护我们自己的基础设施和每个租户免受彼此侵害。我们为 claude.ai（http://claude.ai/redirect/website.v1.50887c69-167a-41e7-913c-f39ce512df26）进行的发布前工作主要由传统安全工作主导，如网络配置、内部服务身份验证和编排。

这些工作强化了安全领域最古老的教训：最薄弱的层是你自己构建的。gVisor 和 seccomp（https://en.wikipedia.org/wiki/Seccomp）在对抗资源充足的攻击者方面已经经过了比代理式 AI 存在时间长得多的验证，因此审查工作集中在它们周围我们构建的较新组件上。我们稍后会回到这一点，因为在我们最严重的事件中，正是我们自定义的代理出了问题。

模式 2：人在回路中的沙箱（Claude Code）

Claude Code 在用户机器上运行，可以访问用户的文件系统、shell 和网络。没有这一点，编码代理的实用性就有限，因此必须找到一种方法安全地授予这种访问权限。

一种方法是依赖人在回路中。这对 Claude Code 来说是一个可处理的解决方案，因为普通用户是熟悉编码环境的开发者：他们能读懂 bash，他们理解 rm -rf 的作用，而且他们每周已经多次从不受信任的来源运行 npm install。所有这些意味着，当“允许此操作”对话框弹出时，他们极有可能具备准确评估代理试图做什么以及相关风险的专业知识。因此，Claude Code 发布时采用了最简单的防御：允许读取，需要批准写入、bash 和网络访问。

然而，如前所述，批准疲劳在几周内就显现了（https://www.reddit.com/r/ClaudeAI/comments/1rru8zw/just_picked_up_a_new_keyboard_cant_wait_to_write/）。具有讽刺意味的是，这意味着一个原本旨在提供监督的功能可能产生相反的效果——一些用户可能干脆不再注意。作为减少不谨慎批准的第一步，我们推出了操作系统级沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap），它强化了边界：允许读取，允许在工作空间内写入，但默认拒绝网络访问。在沙箱内，代理基本上不受干扰地运行。结果是权限提示减少了 84%，并且我们开源了运行时（https://github.com/anthropic-experimental/sandbox-runtime），因此边界是可审计的。

我们的匿名使用数据（https://www.anthropic.com/news/measuring-agent-autonomy）还显示，经验丰富的用户自动批准的频率大约是新手的两倍，但他们也更频繁地在代理执行过程中中断它。与其限制单个步骤，经验丰富的用户更倾向于仅在代理偏离轨道时才进行监督。虽然这可能是人们更愿意与代理合作方式的自然演变，但这同样是有缺陷的，要求用户首先具备足够的技术和注意力才能注意到偏差。随着模型能力的提高和代理开始编写越来越雄心勃勃的 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。现在载荷已处于环境中。我们在线程中添加了一个 canary 字符串（https://www.fortinet.com/resources/cyberglossary/what-is-canary-in-cybersecurity），以便在有人拾取它时能注意到。在一个代理读取所有内容的世界里，调查工具本身也是一个攻击面。）

模式 3：本地虚拟机（Claude Cowork）

Claude Cowork 在用户桌面上运行，可以访问用户选择的工作文件夹。由于该平台是为通用知识工作而非软件工程构建的，普通用户不太可能精通 bash。

因此，人在回路中的沙箱策略可能无法迁移；不能期望非技术知识工作者能够判断诸如 find。 -name "*.tmp" -exec rm {} \; 之类的 bash 咒语。当批准例外需要典型用户不具备的专业知识时，管理员应该设置一个绝对且始终有效的边界。

为了实现这一点，我们的第一个 Clauth Cowork 版本运行在完整的虚拟机内，使用平台厂商的 hypervisor（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）。虚拟机拥有自己的 Linux