核验日期：2026-07-08
内容来源：Anthropic Engineering 官方技术博客。本文先作为 Claude Code 专区后台草稿入库，发布前应由内容人员复核标题、摘要、图片、来源链接与是否需要补充本站实践说明。
我们如何在各产品中约束 Claude
随着智能体能力增强，它们潜在的影响范围也在扩大。工程问题在于如何为这个范围设上限。以下是我们在为 claude.ai、Claude Code 和 Cowork 构建约束机制时学到的经验。
来源：https://www.anthropic.com/engineering/how-we-contain-claude
发布日期：2026-05-25
十二个月前，如果有人提出给 Claude 足以让一个 Anthropic 内部服务下线的访问权限，我们会直接否决。今天，这种级别的访问已经很常见，Anthropic 开发者也因此更高效。这类部署的风险有两个组成部分：失败发生的可能性，以及一次失败可能造成的损害。防护措施和模型训练的进步，持续降低了前者；而后者，也就是理论上的影响范围，会随着能力和访问权限扩大而只增不减。不过，当智能体开始能够完成过去需要一个人甚至一个团队才能完成的工作时，不部署的成本会大到足以让风险收益计算明显倾向采用，只要产品能被做得足够安全。工程问题就变成了如何为影响范围设上限。
当可以为自主智能体的相对损害设定边界时，例如通过控制其环境，高效用能力就可能推动部署。Claude Mythos Preview 是一个例子：2026 年 4 月，我们认为它的影响范围过高，因此不适合发布。不过，随着防御方加固关键系统、防护措施成熟，我们预计具备类似能力水平的模型将更适合更广泛发布，尽管风险总会存在。模型能力是智能体部署总风险中的一个重要因素。
大体上有两种方法可以做到这一点。
第一种是通过 human-in-the-loop 监督智能体行为。Claude Code 过去通过在每一轮请求用户授权，防止智能体采取非预期操作。理论上这可行，但我们发现这种方法并不可靠。我们的遥测数据显示，用户大约会批准 93% 的权限提示。用户看到的批准请求越多，对每个请求投入的注意力就越少，随着时间推移，监督会变得远不那么认真。我们最近构建了 Claude Code auto mode，它会自动化更安全的批准，以减少这种审批疲劳。尽管如此，漏洞仍然存在，任何概率性防御都有非零漏检率。1
第二种为影响范围设上限的方法，也是本文很大一部分的重点，是 containment（约束/隔离）。我们不是监督智能体做了什么，而是通过 sandbox、virtual machine 和 egress control 等方式强制访问边界，监督它能够做什么。这是 Anthropic 工程团队投入最多精力的地方，也是许多最令人意外的安全失败发生的地方。
过去两年里，我们发布了三个主要的 agentic 产品：claude.ai、Claude Code 和 Claude Cowork。它们分别服务不同受众，因此需要不同的约束架构。本文会分享哪些东西经受住了考验，哪些东西出了问题，以及我们在智能体安全方面一路学到的经验。
三类风险，三种防御组件
智能体面临的安全风险分为三类：
用户误用： 用户出于恶意或疏忽，指示智能体做有害的事情。这包括从要求智能体绕过他们觉得烦人的检查，到运行他们并不理解的破坏性命令，再到明确指定有意伤害。
模型不当行为： 智能体采取了没人要求的有害操作。随着模型改进，它们在多数行为评估上变得更加对齐，但这并不意味着风险一定会缩小。能力较弱的模型更可能误读情境并犯明显错误。能力更强的模型犯错更少，但也更擅长找到达成目标的意外路径，往往会绕过没人想到要写下来的限制。
在 Anthropic，我们见过 Claude 模型为了完成任务而“好心地”逃出 sandbox，检查 git history 以找到编码测试答案，以及自发识别自己正在运行的 benchmark，从而解密答案密钥。每个模型都会带来一组新能力，而这些能力有时会以意想不到的方式被使用。
外部攻击者： 智能体通过工具、文件或网络访问等外部向量受到攻击。这一类包括提示注入，也包括针对智能体运行时、编排层或代理的传统攻击。
在构建约束和防御系统时，我们会把防御应用到三个主要组件上：
智能体运行的环境。 我们通过进程 sandbox、VM、文件系统边界和 egress control，限制智能体可以在哪里以及如何行动。目标是为智能体能触达的范围设置硬边界。例如，如果凭证从不进入 sandbox，那么无论原因是用户、模型找到了一条“有创意”的路径，还是攻击者，凭证都无法被外泄。
紧密的边界也意味着你可以放松监督。Claude Code 的参考 devcontainer 存在的目的，正是让智能体可以无人值守运行，而不需要逐操作批准。
智能体咨询的模型。 这里的机制包括 system prompt、classifier、probe 和训练修改。由于模型是概率性的，这些机制只能塑造智能体倾向于做什么，而不能限制它理论上能够做什么。
这些防御很强。在 Gray Swan 的 Agent Red Teaming benchmark 上，该 benchmark 测试对提示注入的易感性，Claude Opus 4.7 将单次尝试的攻击成功率控制在约 0.1%，在 100 次自适应尝试后也约为 5-6%。Claude Code auto mode 会在执行前捕捉大约 83% 的过度主动行为。然而，即使拥有同类最佳防御，模型层的保护也永远不可能 100% 有效，这就是它不能单独承担防御的原因。
智能体可以触达的外部内容。 MCP server、第三方插件和网页搜索工具都会把你无法控制来源的内容送入智能体上下文。经过审计的 connector 并不等同于经过审计的数据，例如 GitHub connector 即使通过了恶意软件检查，也可能把一个被投毒的 README 直接加载到模型上下文中。细粒度限制工具权限有助于限制影响范围。例如，一个只有只读数据库访问权限的智能体，可以比一个能写生产库的智能体更广泛地部署。
防御应当重叠并互补。当环境防御不可用时，模型层就必须补上缺口（这正是 Claude Code 的 auto mode 被设计出来要处理的事情）。在本地，环境和模型防御可以防范恶意工具输出，但也可以通过限制工具能力和访问权限，在更上游增加防御。
三个需要防御的组件：模型、它运行的环境，以及智能体可以触达的外部内容。
约束智能体的模式
聚焦于环境层，我们描述三种隔离模式，以及它们如何为每个 Claude 平台量身定制：claude.ai、Claude Code 和 Cowork。我们是在逐步找到智能体所需能力与用户所需干预程度之间的平衡后，才形成每一种设计的。
模式 1：临时容器（claude.ai 代码执行）
虽然 claude.ai 最广为人知的是聊天界面，但它也会编写和运行代码、生成文件，并调用 connector。当 Claude 在 claude.ai 内运行代码时，它会在隔离基础设施上的 gVisor 容器中执行。智能体完全位于服务端；本地机器上不会运行代码，文件系统也是临时的（按 session 隔离）。影响范围很小，但 Claude 能做的事情上限也很低，因为没有持久工作区，也没有对用户文件系统的访问。
这也让 claude.ai 面临一种更传统的威胁模型。我们不是在保护用户机器不受智能体影响；我们是在保护自己的基础设施，以及各租户彼此隔离。我们为 claude.ai 做的发布前工作，主要是网络配置、内部服务认证和编排等传统安全工作。
这些工作再次强化了安全领域最古老的教训：最薄弱的一层往往是你自己构建的那一层。gVisor 和 seccomp 在面对资源充足的对手时被加固的时间，远远长于 agentic AI 存在的时间，因此审查精力主要投向了我们围绕它们构建的更新组件。后面我们还会回到这一点，因为我们的自定义代理也是在最严重事件中出问题的组件。
模式 2：Human-in-the-loop sandbox（Claude Code）
Claude Code 运行在用户机器上，可以访问用户的文件系统、shell 和网络。没有这些访问能力，编码智能体的用途会很有限，因此必须找到一种安全授予这些访问权限的方法。
一种方法是依赖 human-in-the-loop。这对 Claude Code 来说是一个可处理的方案，只因为平均用户是熟悉编码环境的开发者：他们能读 bash，理解 rm -rf 做什么，而且每周已经会多次从不可信来源运行 npm install。这些都意味着，当“允许此操作”的对话框弹出时，他们很可能具备准确评估智能体试图做什么以及相关风险的专业能力。基于这一点，Claude Code 最初采用了最简单的防御：允许读取；写入、bash 和网络访问需要批准。
不过如前所述，审批疲劳在几周内就出现了。讽刺的是，这意味着一个原本旨在提供监督的功能，可以说反而可能产生相反效果：一些用户可能会干脆不再注意。作为缓解草率审批的第一步，我们发布了一个 OS-level sandbox（macOS 上的 Seatbelt，Linux 上的 bubblewrap）来强化边界：允许读取，允许在 workspace 内写入，但默认拒绝网络。在 sandbox 内，智能体大体可以不受打断地运行。结果是权限提示减少了 84%，并且我们开源了运行时，因此边界是可审计的。
我们的匿名化使用数据还显示，经验丰富的用户自动批准的频率大约是新用户的两倍，但他们也更常在执行中途打断智能体。经验丰富的用户不是为每一个步骤设闸，而是更可能只在智能体偏离轨道时监督它。虽然这可能是人们偏好如何与智能体协作的一种自然演化，但它同样并不可靠，因为它要求用户足够技术化、足够专注，能首先注意到偏移。随着模型能力提升，智能体开始编写越来越有野心的 bash，注意到这种偏移会变得更难。而当用户转向多智能体系统时，这种方法也远不太可能成为有效的监督策略。
我们漏掉的风险：信任对话框之前的一切
2025 年中至 2026 年 1 月期间，我们通过负责任披露计划收到了 Claude Code 中的漏洞报告。其中三个漏洞针对的是用户尚未同意任何事情之前就会执行的代码。要理解这为什么可能，考虑最直接的情况：开发者克隆一个仓库来审查 pull request，而该仓库包含一个定义了 hook 的 .claude/settings.json。由于 Claude Code 会在启动期间读取项目设置，而这发生在展示标准的“你信任此文件夹吗？”提示之前，攻击者编写并提交的 hook 就会自动执行。其余案例在结构上类似，都是在信任边界建立之前，解析来自尚未受信任目录的输入。
每个案例的修复方式形态相同：把项目本地配置的解析和执行推迟到用户接受信任提示之后。如果你在构建类似系统，请把 project-open、config-load 和 localhost listener 当作来自互联网的任何入站请求一样对待。它们不应该仅仅因为感觉上是本地的、并且在用户同意之前到达，就被隐式信任。
我们漏掉的风险：用户作为注入向量
2026 年 2 月，在一次受控内部红队演练中，一名研究员成功钓鱼让一名员工用恶意 prompt 启动 Claude Code。这个钓鱼看起来像普通协作：一封“你能帮我运行这个吗？”的邮件，附带一个可直接粘贴的 prompt；而 prompt 本身读起来像常规任务说明。但在设置步骤中，它轻描淡写地要求 Claude 读取 ~/.aws/credentials，对内容编码，并 POST 到一个外部端点。对这个 prompt 重试 25 次，Claude 完成了 24 次外泄。
这是一次直接提示注入，攻击者的指令通过用户到达，而不是通过工具输出或获取到的内容。我们的模型层防御会锚定用户意图，而当用户亲自输入指令时，分类器没有什么异常可捕捉。拿到同一脚本的人类承包商也会做同样的事。
在这种情况下唯一站得住的防御是环境，具体来说，是无论意图如何都阻止 POST 的 egress control，以及一开始就让 ~/.aws 不可触达的文件系统边界。
（当我们在内部 Slack 中分享可工作的 prompt 用于讨论时，有人指出部分内部智能体会读取 Slack。payload 现在成了环境中的背景内容。我们在该 thread 中加入了一个 canary string，以便注意到是否有什么东西拾取了它。在一个智能体会读取一切的世界里，调查工具本身也是攻击面。）
模式 3：本地 VM（Claude Cowork）
Claude Cowork 运行在用户桌面上，可以访问用户选择的 workspace folder。由于该平台面向通用知识工作，而不是软件工程，平均用户远不太可能熟悉 bash。
因此，human-in-the-loop sandbox 策略可能无法迁移；不应期望非技术知识工作者判断 find . -name "*.tmp" -exec rm {} ; 这样的 bash 咒语。当批准例外需要典型用户并不具备的专业知识时，管理员应当设置一条绝对且始终生效的边界。
为此，Claude Cowork 的第一个版本运行在一个完整 virtual machine 内，使用平台供应商的 hypervisor（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）。VM 有自己的 Linux kernel、自己的文件系统和自己的进程表。用户选择的 workspace 和 .claude folder 会被挂载；主机上的其他内容不可见。凭证保留在主机的 keychain 中，永远不会进入 guest machine。这个设计防范的是 Claude 在某个时刻可能以未对齐方式行动的可能性。被攻破的 Claude 仍然可以破坏 workspace folder 内的内容，所以该架构被设计成确保那是它唯一能触达的东西（直到用户添加 connector），并且由用户控制那里挂载什么。
在最初的架构，也就是我们所说的 full-VM mode 中，agent loop 本身运行在 guest 内，因此 Claude 作为普通 Linux 用户执行，并不知道自己处于 sandbox 中。对比 Claude Code，后者有一个特权进程位于 sandbox 外部，并逐命令决定是否强制执行 sandbox；一个有说服力的注入 prompt 或一次疲劳审批点击，都可能让该进程运行未被 sandbox 限制的东西。而在这里，没有持有逃生钥匙的外部进程，因此也没有任何组件有权授予例外。
Claude Cowork VM 的六个主要隔离机制。其中两个在 guest kernel 外部强制执行，因此即使智能体在 VM 内获得 root 级访问权限，它们仍然有效。其他四个由 guest 强制执行，并刻意保持最小化，因为外层承载了其余防御。
不过，我们很快意识到，在 full-VM mode 中运行整个智能体会造成实际问题：VM 启动期间的任何失败都会让 Cowork 无法使用。把 agent loop 移到 VM 外部，同时把代码执行保留在 VM 内部，让 Claude 在出错时仍能回复用户并帮助调试问题，而不是在错误上冻结。这个变更带来的安全影响很小，因为 VM 仍然对智能体执行的代码强制文件系统和网络控制。
另外，我们也把本地 MCP server 移到了 VM 外部。在 VM 内运行它们会让审计变得更难，在 VM 更新时造成脆弱的依赖问题，而且不支持需要与数据库等本地进程交互的 MCP，这类 server 无论如何都必须在主机上运行。这一变更让 Claude Cowork 与本地 MCP server 在 Claude Desktop 中已有的工作方式保持一致：把它们视为用户可能选择安装的任何软件，并由管理员决定启用哪些本地 MCP（如果启用的话）。远程 MCP server 不受影响，因为它们不在用户机器上运行。
让 agent loop 位于 VM 内部意味着 VM 的任何故障都会导致 Cowork 不可用。Host-mode 更可靠，因为即使 VM 崩溃，智能体仍可响应，同时它通过隔离代码执行仍然提供重要安全保证。
文件系统控制是另一个重要的架构选择。Claude 需要能够访问主机上的某些文件才有用，但我们希望最小化影响范围，并让用户清楚看到本地文件访问。我们发现，提供不同的文件挂载模式有助于细粒度控制风险；Claude Cowork 提供只读、读写和读写不可删除三种模式。这里一个潜在陷阱是，symlink resolution 必须发生在 path validation 之前，而不是之后，否则授权文件夹内的 symlink 可能指向外部并逃逸。对于企业客户，我们允许管理员通过 MDM 设置中的 mount-path allowlist 来控制这一点。
我们漏掉的风险：通过已批准域名外泄
一个通过已批准域名外泄的清晰例子来自第三方披露。Claude Cowork 的 egress allowlist 正确放行了到 api.anthropic.com 的流量，因为产品如果不调用我们自己的 API 就无法工作。在这个案例中，一个放在用户已挂载 workspace 中的恶意文件，携带隐藏指令以及由攻击者控制的 API key。Claude 按照指令读取 workspace 中的其他文件，并用攻击者的 key 调用 Anthropic 的 Files API。Egress proxy 检查目标地址，看到 api.anthropic.com，于是放行。文件被上传到攻击者的 Anthropic 账户。Sandbox 完美工作，然而数据仍然被外泄了。
之前，我们把 allowlist 概念化为一个目标过滤器，告诉 Claude 这些域名可以通信。但更好的概念化方式也许是把它看作能力授予。通过 allowlist 上任何域名可触达的每个功能，现在都是攻击面。允许 api.anthropic.com，就意味着允许把文件上传到任意 Anthropic 账户。
我们用 VM 内的防御性 man-in-the-middle proxy 修复了它，该代理会拦截到我们 API 的流量。它只放行携带 VM 自己预置 session token 的请求；嵌入攻击者 key 的请求会被代理拒绝。它还会阻止可能启用 server-side fetch 的 header。该代理位于 VM 内，而不是我们的服务器上，因为只有 VM 知道 provenance，从服务器角度看，一个 Cowork 请求与其他 API client 无法区分。
上图：到 api.anthropic.com 的流量被放行，导致外泄。下图：通过 man-in-the-middle proxy 拦截到我们 API 的流量来修复。
这也是“你自己构建的软件往往最薄弱”这一原则的第二个实例。我们各产品中的 hypervisor、seccomp 和 gVisor 都很可靠。失败的是我们的自定义 allowlist proxy。
我们漏掉的风险：VM 隔离也把端点检测软件挡在外面
在评估 Claude Cowork 时，企业安全团队会问：“为什么我们的 EDR 看不到里面？”答案是，同样用于约束 Claude 的隔离，也把基于主机的 endpoint detection and response 挡在了外面。从 EDR 的视角看，Claude Cowork 是一个不透明的 hypervisor 进程。它无法检查 guest。
隔离会降低可见性，而对于合规姿态依赖端点可见性的团队来说，不透明是个问题。我们当前的缓解措施是使用 pull-based OTLP exports，让管理员可以事后获取事件日志，但这不同于实时监控。如果你在构建类似系统，请尽早为这场对话预留时间。
| 环境 | 临时容器（claude.ai） | HITL sandbox（Claude Code） | 密封 VM（Claude Cowork） |
|---|---|---|---|
| 成本：隔离开销 | 容器启动 | 低延迟原生 sandbox | 完整 VM 启动 |
| 成本：用户依赖 | 不适用 | 必须理解 bash | 不适用 |
| 风险：影响范围 | 服务端容器（由 gVisor + host infra boundary 保护） | 本地 workspace | 已挂载 workspace（由 vsock + hypervisor boundary 保护） |
信任智能体读取的内容
企业经常问我们如何保护 MCP 连接。这是个好问题，但正确的问题比 MCP 本身更宽。提供给智能体的任何外部资源都会同时代表两种风险：传统供应链意义上的代码执行风险，以及提示注入向量。传统依赖审计（固定版本、验证签名、审查源代码）可以处理前者，但会漏掉后者。
远程与本地之分比看起来更重要。 本地安装的工具是可审计的。你可以阅读代码、固定版本，并知道它不会在你不知情的情况下改变。远程工具，例如托管 MCP server 或云 connector，则可能在你批准后的任意时间点改变行为；你在安装时做出的信任决策可能不再适用。我们的 connector directory 通过持续审查来处理这一点，但目录外的任何东西都应被视为不可信。请先在假数据上运行它，并放在一个恶意工具影响范围受约束的环境中。
即使工具可信，工具输出也是攻击面。 前面提到的 GitHub README 例子正是这种情况；任何应用于网页的输入扫描，都需要以同样严格程度应用于启用网络的工具结果。尽管这会增加延迟，也不是完美防御，我们仍倾向于实时检查：一旦被投毒的工具返回值引导智能体外泄数据，日志里只会显示一次成功的、已授权的 API 调用。事后没有信号可供发现。
在 Claude Code 和 Claude Cowork 中，工具调用会通过代理路由，这些代理强制执行网络和文件策略，并且可以在返回值进入模型上下文之前检查它们。执行检查的 classifier 可以是一个小而快的模型；它不需要是负责推理的那个模型。
展望
模型和产品正在快速进步。随之而来，风险会变形和演化，我们的缓解措施也必须跟上。
持久记忆投毒。 跨 session 持久存在的智能体上下文比例在不断增长，包括产品记忆、CLAUDE.md 文件、已挂载 workspace，以及 scheduled 和 long-running agent 的状态目录。落入其中任何位置的注入，都会在每次智能体启动时重新加载。随着更多智能体状态在 session 之后存活下来，我们正受到经典后渗透意义上新持久化机制的威胁。Session 启动时的优秀 classifier 将需要变得更常见。
多智能体信任升级。 一方面，sub-agent 可以隔离不可信内容，把结构化事实而不是原始文本返回给 main agent。另一方面，这也可能被滥用：如果 sub-agent 的输出因为来自“我们”而被视为比原始工具结果更高信任，就会引入一种新的提示注入向量。在多智能体系统中，分配不同信任级别与承担信任升级风险之间存在权衡。
智能体身份。 Claude Cowork 对智能体身份的回答是具体的：凭证保留在主机 keychain 中，VM 获得一个按 session 缩小范围的 token，而该 token 可以独立于用户 token 被撤销。不过，我们开始面对更广泛的跨平台智能体身份问题。智能体应该拥有自己的 principal identity，还是应该作为用户的延伸并继承用户权限？最终答案可能是两者的混合。
随着智能体能力增强，攻击面在不断移动。我们见过的失败类型，很可能会在各行业和实验室中重复出现。我们需要在智能体专属安全姿态上共同投入，从共享 benchmark 和披露规范，到共同身份标准和跨供应商 red-teaming。本文聚焦于约束，但这只是智能体安全图景的一部分。对于治理、可观测性和栈的其余部分，请参阅 NIST 关于 AI agent identity and authorization 的项目、由澳大利亚 ACSC 联合 CISA 和英国 NCSC 牵头的六机构关于采用 agentic AI 的指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing initiative 是其中一项贡献，但我们期待与合作伙伴和竞争对手一起，在这个关键问题上协作。
总结
简而言之，我们反复回到几个原则：
首先在环境层设计约束，然后在模型层引导行为。 最让我们受教的两个事件，即员工钓鱼事件和第三方 allowlist 披露，都是 egress 案例，数据通过被允许的路径离开。在这两个案例中，模型层帮不上忙；没有异常可供它捕捉。当所有概率性防御都漏掉时，被命中的就是确定性边界。
让隔离强度匹配用户的监督能力。 能读懂 bash 的开发者和读不懂 bash 的知识工作者，不处于同一个威胁模型。用户是否能评估智能体即将做什么，应当帮助决定约束策略；在任一方向上答错，也就是给专家太多摩擦，或给非专家太多信任，本身都是一种失败。
警惕自定义组件。 经受战斗考验的 hypervisor、syscall filter 和 container runtime，已经承受过比你将构建的任何东西都更多的对抗性关注。在这里描述的每一种部署中，标准原语都站住了，而我们围绕它们自己构建的部分暴露了缺陷。
归根结底，虽然智能体可能是一类新的软件，但它们在系统层面的交互并不新。它们仍然会读取文件、打开 socket、启动进程；这使得使用成熟工具进行约束成为一种至关重要且可行的防御。随着 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 auto mode 将命令审批委托给基于模型的 classifier；它以漏掉一小部分风险操作为代价（约 17% 的过度主动操作会通过），最小化摩擦（约 0.4% 的良性命令被阻止），因此它是 sandbox 内纵深防御的一层，而不是 sandbox 的替代品。
