我们如何在多个产品中管控Claude

# 我们如何跨产品对 Claude 进行安全管控 来源：https://www.anthropic.com/engineering/how-we-contain-claude 十二个月前，我们绝不会考虑授予 Claude 足以搞垮 Anthropic 内部服务的权限。如今，这种级别的权限已是常态，Anthropic 的开发者也因此更加高效。这些部署的风险包含两个要素：故障发生的概率有多大，以及故障可能造成多大损害。安全防护措施和模型训练的进步稳步降低了前者；而后者——理论上的爆炸半径——随着能力与访问权限的扩展只会越来越大。然而，当智能体开始能完成曾经需要一个人甚至一个团队才能完成的工作时，*不*部署的代价就会增长到足以让风险评估强烈倾向于采用——前提是产品能够确保安全。工程问题就变成了如何限制爆炸半径。 *当自主智能体的相对损害可以被设定边界时——例如通过对其环境的控制——高实用性的能力就可以推动部署。Claude Mythos 预览版就是一个例子，该模型在 2026 年 4 月被认为爆炸半径过大而未能发布。然而，随着防御方加固关键系统、安全防护措施逐渐成熟，我们预计具有类似能力水平的模型将适合更广泛的发布——尽管某些风险将始终存在。模型能力是智能体部署总风险中的重要因素。* 限制爆炸半径大致有两种方法。 第一种是通过人类介入来监督智能体的行为。Claude Code 之前通过在每个步骤征求用户许可来防止智能体采取非预期行动。理论上这可行，但我们发现这种方法存在缺陷。我们的遥测数据显示，用户批准了大约 93% 的权限提示。用户看到的批准请求越多，对每个请求的关注就越少，久而久之监督的认真程度就会大幅下降。我们最近构建了 Claude Code auto 模式，该模式能够*自动化更安全的审批流程*（https://www.anthropic.com/engineering/claude-code-auto-mode），以减少这种审批疲劳。不过，漏洞依然存在——任何概率性防御都有非零的漏报率¹。 第二种限制爆炸半径的方法——也是本文的大部分焦点——是**隔离**。不是监督智能体*做*什么，而是监督它*能*做什么，通过实施访问边界，例如沙箱、虚拟机和出口控制。这是 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 auto 模式在执行前能捕获大约 83% 的过度积极行为。然而，即使拥有同类最佳的防御，模型层的保护也永远不会达到 100% 有效，这就是为什么它不能单独存在。 **智能体可以触及的外部内容。** MCP 服务器、第三方插件和网络搜索工具都会将你不控制来源的内容输入到智能体的上下文中。经过审计的连接器并不等于经过审计的数据——例如，一个 GitHub 连接器可以将一个被投毒的 README 文件直接加载到模型的上下文中，即使通过了恶意软件检查。细粒度地限制工具权限有助于限制爆炸半径。例如，一个只有数据库只读权限的智能体，其部署范围可以比能写入生产数据库的智能体广泛得多。 防御措施应该相互重叠和补充。当环境防御不可用时，模型层必须补上（这正是 Claude Code 的 auto 模式的设计目的）。在本地，环境和模型防御可以抵御恶意工具输出，但可以通过限制工具的能力和访问权限在更上游添加防御。 *需要防御的三个组件：模型、模型运行的环境，以及智能体可以触及的外部内容。* ## **隔离智能体的模式** 聚焦于环境层，我们描述三种隔离模式，以及它们如何为每个 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。此时 payload 已经存在于环境中。我们在该线程中添加了一个蜜罐字符串，以便如果什么东西读取了它我们能注意到。在一个智能体读取一切的世界里，调查工具本身也是一个攻击面。） ### **模式 3：本地虚拟机（Claude Cowork）** Claude Cowork 在用户的桌面上运行，可以访问用户选择的工作文件夹。由于该平台是为通用知识工作者而非软件工程师构建的，普通用户对 bash 的熟悉程度要低得多。 因此，人机协作沙箱策略可能无法移植；一个非技术背景的知识工作者不应该被要求判断诸如 `find . -name "*.tmp" -exec rm {} \;` 这样的 bash 咒语。当批准一个例外需要典型用户不具备的专业知识时，管理员应该设置一个绝对且始终开启的边界。 为了实现这一点，我们的第一个版本的 Claude Cowork 运行在一个完整的虚拟机内，使用平台的厂商虚拟机管理程序（macOS 上的 Apple Virtualization.framework，Windows 上的 HCS）。该 VM 拥有自己的 Linux 内核、自己的文件系统和自己的进程表。用户选定的工作文件夹和 `.claude` 文件夹被挂载；主机上的其他内容都是不可见的。凭据保留在主机钥匙串中，永远不会进入客户机。这种设计防护了 Claude 在某些时候可能会表现