我们如何在各产品中管控Claude

十二个月前，我们还会断然拒绝让 Claude 拥有足以关闭 Anthropic 内部服务的访问权限。如今，这种级别的访问已是常态，Anthropic 的开发者也因此效率更高。这类部署的风险包含两个部分：故障发生的可能性有多大，以及可能造成多大的损害。安全防护和模型训练方面的进展稳步降低了前者；后者——即理论上的爆炸半径——则随着能力和访问权限的扩展而不断增大。然而，当 agent 能够完成曾经需要一个人甚至一个团队才能完成的工作时，只要产品能够确保安全，_不_部署的成本就会变得足够高，以至于风险回报的天平会明显倾向于采用。工程问题就变成了如何限制爆炸半径。

当自主 agent 的相对损害可以被限定（例如通过控制其运行环境）时，高实用性的能力可以推动部署。Claude Mythos Preview 是一个例子，其爆炸半径在 2026 年 4 月被认为过高而无法发布。然而，我们预计随着防御方加固关键系统且安全防护措施日趋成熟，即使风险始终存在，发布具有类似能力水平的模型将变得合适。模型能力是 agent 部署总风险中的一个重要因素。

大致有两种方法可以实现这一点。

第一种是通过人在回路中（human-in-the-loop）来监督 agent 的行为。Claude Code 之前通过在每一步向用户请求许可来防止 agent 采取非预期的行动。理论上这可行，但我们发现这种方法容易出错。我们的遥测数据显示，用户批准了大约 93% 的许可提示。用户看到的批准请求越多，对每个请求的关注就越少，久而久之，他们的监督就会变得非常松懈。我们最近构建了 Claude Code 的自动模式（auto mode），它自动化了更安全的批准流程，以减少这种批准疲劳。尽管如此，漏洞依然存在——任何概率性的防御都有非零的漏报率¹。

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

在过去两年中，我们发布了三款主要的 agent 产品：claude.ai、Claude Code 和 Claude Cowork。每款产品服务于不同的用户群体，需要不同的隔离架构。本文分享了哪些方案行之有效，哪些方案出了问题，以及我们在此过程中学到的关于 agent 安全的知识。

三种风险，三个防御组件

agent 面临的安全风险分为三类：

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

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

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

外部攻击者： agent 通过外部向量（如工具、文件或网络访问）受到攻击。此类别包括 prompt 注入（prompt injection）以及对 agent 运行时、编排层或代理（proxy）的传统攻击。

在构建隔离和防御系统时，我们对三个主要组件应用防御措施：

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

一个严密的边界也意味着你可以放松监督。Claude Code 的参考开发容器（devcontainer）的存在正是为了让 agent 可以在无人值守的情况下运行，无需逐操作批准。

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

这些防御措施很强大。在 Gray Swan 的 Agent Red Teaming benchmark（测试对 prompt 注入的敏感性）上，Claude Opus 4.7 在单次尝试中将攻击成功率控制在约 0.1%，在 100 次自适应尝试后约为 5-6%。Claude Code 的自动模式在过度行为执行之前能捕获约 83%。然而，即使拥有最先进的防御，模型层的保护也永远不会达到 100% 有效，这就是为什么它不能单独存在。

agent 可以访问的外部内容。 MCP 服务器、第三方插件和网络搜索工具都会从你无法控制的来源向 agent 的上下文（context）提供内容。经过审计的连接器（connector）不等于经过审计的数据——例如，一个 GitHub 连接器可以将一个被投毒的 README 直接加载到模型的上下文中，尽管它通过了恶意软件检查。精细地限制工具权限有助于限制爆炸半径。例如，一个只有数据库读取权限的 agent 可以比一个能写入生产环境的 agent 部署得更广泛。

防御措施应该重叠并相互补充。当环境防御不可用时，模型层必须弥补（这正是 Claude Code 的自动模式的设计目的）。在本地，环境和模型防御可以防范恶意工具输出，但可以通过限制工具的能力和访问权限在更上层添加防御。

三个需要防御的组件：模型、模型运行的环境，以及 agent 可以访问的外部内容。

隔离 agent 的模式

聚焦于环境层，我们描述三种隔离模式以及它们如何针对每个 Claude 平台——claude.ai、Claude Code 和 Cowork——进行定制。我们是在逐步找到 agent 所需能力与用户所需干预程度之间的平衡后，才得出每种设计的。

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

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

这也使得 claude.ai 受制于更传统的威胁模型。我们不是在保护用户机器免受 agent 侵害；而是在保护我们自己的基础设施以及各个租户之间相互隔离。我们为 claude.ai 做的发布前工作主要是传统的安全工作，如网络配置、内部服务认证和编排。

这项工作强化了安全领域最古老的教训：最薄弱的环节是你自己构建的那部分。gVisor 和 seccomp 在对抗资源充足的对手方面已经经过了比 agentic AI 存在时间长得多的考验，因此审查工作集中在它们周围我们构建的较新组件上。我们稍后会回到这一点，因为我们定制的代理（proxy）也是在我们最严重的事件中出问题的部分。

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

Claude Code 在用户的机器上运行，可以访问用户的文件系统、shell 和网络。没有这些，编码 agent 的实用性就非常有限，因此找到一种安全地授予这种访问权限的方法至关重要。

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

然而，如前所述，批准疲劳在几周内就出现了。具有讽刺意味的是，这意味着一个原本设计用于提供监督的功能可能产生相反的效果——一些用户可能干脆不再注意。作为减少不谨慎批准的第一步，我们发布了一个操作系统级别的沙箱（macOS 上的 Seatbelt，Linux 上的 bubblewrap）来强化边界：允许读取，允许在工作空间内写入，但默认拒绝网络访问。在沙箱内，agent 基本上可以无中断地运行。结果是权限提示减少了 84%，并且我们开源了运行时，因此边界是可审计的。

我们的匿名使用数据还显示，有经验的用户自动批准的频率大约是新手用户的两倍，但他们也更频繁地在 agent 执行过程中中断它。有经验的用户不是对每一步进行把关，而是更倾向于只在 agent 偏离轨道时才进行监督。虽然这可能是人们与 agent 协作方式的自然演变，但这同样容易出错，需要用户具备足够的技术能力和注意力才能首先注意到偏离。随着模型能力的提升和 agent 开始编写越来越复杂的 bash 命令，注意到这种偏离会变得更加困难。而且，随着用户转向多 agent 系统，这种方法作为有效监督策略的可能性也大大降低。

我们遗漏的风险：信任对话框之前的一切

在 2025 年中到 2026 年 1 月期间，我们通过负责任披露计划收到了关于 Claude Code 漏洞的报告。其中三个漏洞利用了在用户同意任何操作_之前_执行的代码。要理解这是如何可能的，考虑最直接的情况：一个开发者克隆一个仓库来审查 pull request，而该仓库包含一个定义了 hook 的 .claude/settings.json 文件。因为 Claude Code 在启动期间——在显示标准的“你信任此文件夹吗？”提示之前——就会读取项目设置，所以攻击者编写并提交的 hook 会自动执行。其余案例在结构上类似，即来自尚未被信任目录的输入在信任边界建立之前就被解析了。

每个案例的修复方案形式相同：将项目本地配置的解析和执行推迟到用户接受信任提示之后。如果你正在构建类似的东西，请像对待来自互联网的任何入站请求一样对待项目打开、配置加载和 localhost 监听器。它们不应该仅仅因为感觉是本地且在用户同意之前到达就被隐式信任。

我们遗漏的风险：用户作为注入向量

在 2026 年 2 月，一次受控的内部红队演练中，一名研究员成功通过钓鱼手段让一名员工使用恶意 prompt 启动了 Claude Code。这次钓鱼看起来像普通的协作——一封“你能帮我运行这个吗？”的邮件，附带一个可以直接粘贴的 prompt——而 prompt 本身读起来像常规的任务指令。但在设置步骤的某处，它温和地要求 Claude 读取 ~/.aws/credentials，对内容进行编码，然后通过 POST 发送到一个外部端点。在 25 次对该 prompt 的重试中，Claude 完成了 24 次数据窃取。

这是一个_直接_的 prompt 注入——攻击者的指令是通过用户传递的，而不是通过工具输出或获取的内容。我们的模型层防御锚定在用户意图上——当用户是输入指令的人时，分类器没有任何异常可以捕捉。一个人类合同工拿到同样的脚本也会做同样的事情。

在这种情况下唯一有效的防御是环境，特别是阻止 POST 请求（无论意图如何）的出口控制，以及首先将 ~/.aws 目录置于 agent 无法触及范围的文件系统边界。

（当我们在内部 Slack 中分享这个有效的 prompt 进行讨论时，有人指出一些内部 agent 会读取 Slack。这个 payload 现在已经存在于环境中了。我们在该讨论串中添加了一个金丝雀字符串，以便在有任何东西拾取它时我们能注意到。在一个 agent 读取所有内容的世界里，调查工具本身也是一个攻击面。）

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

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

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

为了实现这一点，我们的第一个 Claude Cowork 版本运行在一个完整的虚拟机内，使用了平台的供应商 hypervisor（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）。虚拟机拥有自己的 Linux 内核、自己的文件系统和自己的进程表。用户选择的工作空间和 .claude 文件夹被挂载；主机上的其他任何东西都不可见。凭据保留在主机钥匙串中，永远不会进入客户机。这种设计防止了 Claude 在某个时刻出现行为失调的可能性。一个被攻破的 Claude 仍然可能损坏工作空间文件夹内的内容，因此架构设计确保那是它_唯一_能触及的东西（直到用户添加连接器），并且用户控制着挂载在那里的内容。

在最初的架构中——我们称之为全虚拟机模式——agent 循环本身运行在客户机内部，因此 Claude 作为一个普通的 Linux 用户执行，不知道它被沙箱化了。相比之下，Claude Code 中有一个特权进程位于沙箱外部，决定每个命令是否强制执行沙箱；一个有说服力的注入 prompt 或一次疲劳的批准点击可以让该进程运行未沙箱化的命令。在这里，没有外部进程持有逃生舱钥匙，因此没有任何组件有权授予例外。

Claude Cowork 虚拟机的六种主要隔离机制。其中两种在客户机内核之外强制执行，因此即使 agent 在虚拟机内获得 root 级别访问权限，它们也能存活。另外四种由客户机强制执行，并刻意保持最小化，因为外层承担了其余工作。

然而，我们很快意识到，在全虚拟机模式下运行整个 agent 会导致实际问题：虚拟机启动期间的任何故障都会使 Cowork 无法使用。将 agent 循环移动到虚拟机_外部_，同时将代码执行保留在虚拟机内部，使得 Claude 仍然能够响应用户并帮助调试问题，而不是在错误上冻结。此更改对安全性的影响最小，因为虚拟机仍然对 agent 执行的代码强制执行文件系统和网络控制。

另外，我们还将本地 MCP 服务器移到了虚拟机外部。在虚拟机内部运行它们使得审计更加困难，在虚拟机更新时会产生脆弱的依赖问题，并且不支持需要与本地进程（如数据库）交互的 MCP——此类服务器无论如何都必须在主机上运行。这一更改使 Claude Cowork 与本地 MCP 服务器在 Claude Desktop 中的工作方式保持一致：将它们视为用户可能选择安装的任何软件，并委托管理员决定启用哪些本地 MCP（如果有的话）。远程 MCP 服务器不受影响，因为它们不在用户机器上运行。

将 agent 循环放在虚拟机内部意味着虚拟机中的任何故障都会导致 Cowork 无法使用。主机模式更可靠，因为如果虚拟机崩溃，agent 仍然可以响应，并且它通过隔离代码执行来提供重要的安全保证。

文件系统控制是另一个重要的架构选择。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 的流量。它只允许携带虚拟机自身配置的会话令牌的请求通过；攻击者嵌入的密钥会被代理拒绝。它还会阻止那些会启用服务端 fetch 的头部。代理位于虚拟机内部而不是我们的服务器上，因为只有虚拟机知道来源——从服务器的角度来看，Cowork 的请求与任何其他 API 客户端是无法区分的。

上图：发往 api.anthropic.com 的流量被放行，导致数据外泄。下图：通过中间人代理拦截发往我们 API 的流量进行修复。

这也是“你自己构建的软件往往是最薄弱的”这一原则的第二个实例。我们产品中的 hypervisor、seccomp 和 gVisor 一直很可靠。我们定制的白名单代理是出问题的部分。

我们遗漏的风险：虚拟机隔离也阻止了端点检测软件

在评估 Claude Cowork 时，企业安全团队问道：“为什么我们的 EDR 看不到内部？”答案是，隔离 Claude 的同一机制也阻止了基于主机的端点检测和响应（EDR）进入。从 EDR 的角度来看，Claude Cowork 是一个不透明的 hypervisor 进程。它无法检查客户机。

隔离降低了可见性，而对于合规态势依赖于端点可见性的团队来说，不透明性是个问题。我们当前的缓解措施是使用基于拉取的 OTLP 导出，让管理员事后检索事件日志，但这与实时监控不同。如果你正在构建类似的东西，请尽早为这方面的沟通做好准备。

环境	临时容器 (claude.ai)	人在回路中沙箱 (Claude Code)	密封虚拟机 (Claude Cowork)
成本：隔离开销	容器启动	低延迟原生沙箱	完整虚拟机启动
成本：用户依赖	不适用	必须能解释 bash	不适用
风险：爆炸半径	服务端容器（由 gVisor + 主机基础设施边界保护）	本地工作空间	挂载的工作空间（由 vsock + hypervisor 边界保护）

信任 agent 读取的内容

企业经常问我们如何保护 MCP 连接。这是个好问题，但更准确的问题比 MCP 本身更广泛。提供给 agent 的任何外部资源都同时代表两种风险：传统供应链意义上的代码执行风险，以及 prompt 注入向量。传统的依赖审计（锁定版本、验证签名、审查源代码）解决了第一个问题，但忽略了第二个。

远程与本地的重要性比看起来更大。 本地安装的工具是可审计的。你可以阅读代码、锁定版本，并知道它不会在你不知情的情况下改变。远程工具——托管的 MCP 服务器、云连接器——可以在你批准后的任何时间点改变行为；你安装时的信任决定可能不再适用。我们的连接器目录通过持续审查来解决这个问题，但目录之外的任何东西都应被视为不受信任的。首先在恶意工具的爆炸半径被限制的环境中，用假数据运行它。

即使工具是可信的，工具输出也是一个攻击面。 前面提到的 GitHub README 例子正是这种情况；应用于网页的任何输入扫描都需要以同样的严格程度应用于启用网络的工具结果。尽管这会增加延迟并且不是完美的防御，但我们倾向于实时检查：一旦被投毒的工具返回结果将 agent 引导至窃取数据，日志只会显示一个成功、已授权的 API 调用。事后没有任何信号可以找到。

在 Claude Code 和 Claude Cowork 中，工具调用通过执行网络和文件策略的代理进行路由，并且可以在返回值进入模型上下文之前对其进行检查。执行检查的分类器可以是一个小型、快速的模型；它不需要是进行推理的那个模型。

展望未来

模型和产品正在快速发展。与此同时，风险也在变化和演变，我们的缓解措施必须跟上步伐以应对它们。

持久性记忆投毒。 跨会话持久化的 agent 上下文份额持续增长——这包括产品记忆、CLAUDE.md 文件、挂载的工作空间，以及定时和长期运行 agent 的状态目录。任何注入到这些位置的内容都会在 agent 每次启动时重新加载。随着更多 agent 状态在会话结束后存活，我们面临着经典后渗透意义上的新型持久化机制的威胁。会话启动时的良好分类器将需要变得更加普遍。

多 agent 信任升级。 一方面，子 agent 可以隔离不受信任的内容，向主 agent 返回结构化事实而非原始文本。另一方面，这可能会被滥用：如果子 agent 的输出被视为比原始工具结果更可信，因为该输出来自“我们”，那么就会引入一个新的 prompt 注入向量。在多 agent 系统中，在分配不同信任级别和容易受到信任升级影响之间存在权衡。

Agent 身份。 Claude Cowork 对 agent 身份的答案是具体的：凭据保留在主机钥匙串中，虚拟机获得一个每个会话的、权限范围缩小的令牌，并且该令牌可以独立于用户的令牌被撤销。然而，我们开始应对跨平台 agent 身份这个更广泛的问题。一个 agent 应该拥有自己的主体身份，还是应该作为用户的扩展并继承用户的权限？最终，答案可能是两者的结合。

随着 agent 能力越来越强，攻击面也在不断变化。我们看到的故障类型很可能在整个行业和实验室中重复出现。我们需要在 agent 特定的安全态势上进行集体投入，从共享的 benchmark 和披露规范，到通用的身份标准和跨厂商的红队演练。我们在本文中专注于隔离，但这只是 agent 安全图景的一部分。关于治理、可观测性以及其余技术栈，请参阅 NIST 关于 AI agent 身份和授权的项目、由澳大利亚 ACSC 与 CISA 和英国 NCSC 联合领导的六机构关于采用 agentic AI 的指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中一项贡献，但我们期待与合作伙伴和竞争对手在这个关键问题上合作。

总结

简而言之，有几个我们反复回归的原则：

首先在环境层设计隔离，然后在模型层引导行为。 让我们学到最多的两起事件——员工钓鱼和第三方白名单披露——都是出口问题，数据通过允许的路径离开。在这两种情况下，模型层都无能为力；没有异常可供它捕捉。当所有概率性防御都失效时，确定性边界就是最后的防线。

将隔离强度与用户的监督能力相匹配。 一个能读懂 bash 的开发者与一个不能的知识工作者，运行的不是同一个威胁模型。用户能否评估 agent 即将做什么这个问题，应该有助于确定隔离策略，而在任何一个方向上答错——对专家来说摩擦太大，对非专家来说信任太多——本身就是一种失败。

警惕自定义组件。 经过实战考验的 hypervisor、系统调用过滤器和容器运行时比你构建的任何东西都承受过更多的对抗性关注。在本文描述的每一个部署中，标准原语都保持稳定，而我们围绕它们构建的自身工作却暴露了缺陷。

最终，虽然 agent 可能是一种新型软件，但它们的系统级交互并非如此。它们仍然读取文件、打开套接字和生成进程；这使得使用成熟工具进行隔离成为一种至关重要的可行防御。随着 AI 的发展，部署的风险回报平衡将继续变化，但对爆炸半径设置硬限制往往能迫使这种平衡朝着正确的方向发展。

致谢

作者：Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, 和 Abel Ribbink。

我们还要感谢 Hanah Ho, Hasnain Lakhani, Pedram Navid, Molly Villagra, Maya Nielan, Akila Srinivasan, Sam Attard, Alfred Xing, Mohamad El Hajj, Gabby Curtis, David Dworken, Adam Jones, Amie Rotherham, Christian Ryan, Lucas Smedley, Brett Andrews 以及其他人的贡献。

特别感谢我们的安全和产品工程团队，以及报告 Claude 产品漏洞的个人和组织。

脚注

1. Claude Code 的自动模式将命令批准委托给一个基于模型的分类器；它以错过一小部分风险命令（约 17% 的过度行为会通过）为代价，最大限度地减少了摩擦（约 0.4% 的良性命令被阻止），因此它只是沙箱内纵深防御的一层，而不是替代品。