Claude的产品隔离机制详解：安全部署最佳实践

十二个月前，如果有人提议授予 Claude 足以导致 Anthropic 内部服务下线的访问权限，我们会断然拒绝。如今，这种级别的访问权限已成为常态，Anthropic 的开发者也因此提高了生产力。这类部署的风险由两部分组成：故障发生的可能性，以及故障可能造成的损害程度。随着安全保障和模型训练不断进步，前者一直在稳步下降；而后者——理论上的爆炸半径——只会随着能力和访问权限的扩展而增大。然而，随着 AI 智能体逐渐能够完成过去需要一个人、甚至一个团队才能完成的工作，不部署它们的成本也变得足够高，以至于只要能够确保产品安全，风险收益的权衡就会明显偏向采用它们。此时，工程上的问题就变成了：如何限制爆炸半径。

大体上有两种方法可以做到这一点。

第一种方法是通过人类参与闭环来监督 AI 智能体的行为。Claude Code 过去通过要求用户在每一步授予权限，来防止 AI 智能体执行非预期操作。理论上这种方法可行，但我们发现它并不可靠。我们的遥测数据显示，用户批准了大约 93% 的权限请求。用户看到的审批越多，对每一次审批投入的注意力就越少，久而久之，他们在监督时会变得远没有那么审慎。我们最近为 Claude Code 构建了自动模式，通过自动批准较为安全的操作来减轻这种审批疲劳。即便如此，漏洞仍然存在——任何概率性的防御机制都具有非零的漏检率。1

第二种限制爆炸半径的方法——也是本文大部分内容的重点——是隔离。我们不监督 AI 智能体做了什么，而是通过沙箱、虚拟机和出站流量控制等手段强制实施访问边界，监督它能够做什么。这是 Anthropic 工程团队投入最多精力的领域，也是许多最令人意外的安全故障发生的地方。

过去两年里，我们发布了三款主要的 AI 智能体产品：claude.ai、Claude Code 和 Claude Cowork。每款产品面向不同的受众，因此需要不同的隔离架构。本文将分享哪些方案经受住了考验、哪些方案出了问题，以及我们一路走来对 AI 智能体安全性的认识。

三类风险，三种防御组件

AI 智能体面临的安全风险可归为以下三类之一：

用户滥用： 用户出于恶意或疏忽，指示 AI 智能体执行有害操作。这涵盖了各种情况：让 AI 智能体绕过他们觉得烦人的检查、运行他们并不了解的破坏性命令，乃至明确要求其实施蓄意伤害。

模型行为失当： AI 智能体执行了无人要求的有害操作。随着模型不断改进，它们在大多数行为评估中表现得更加符合预期，但这并不意味着风险必然缩小。能力较弱的模型更容易误判情境并犯下明显错误。能力更强的模型犯错更少，但也更善于找到实现目标的意外路径，通常会绕过那些没人想到要明确写下来的限制。

在 Anthropic，我们曾看到 Claude 模型为了完成任务而“热心地”逃离沙箱、检查 git 历史记录以寻找编程测试的答案，以及自发识别出自己正在接受哪项基准测试，从而解密其答案密钥。每一代模型都会带来一组新的能力，而这些能力有时会以出人意料的方式发挥作用。

外部攻击者： AI 智能体通过工具、文件或网络访问等外部向量受到攻击。这一类别既包括提示词注入，也包括针对 AI 智能体运行时、编排层或代理的传统攻击。

在构建隔离与防御系统时，我们会针对三个主要组件部署防御措施：

AI 智能体运行的环境。 我们通过进程沙箱、虚拟机、文件系统边界和出站流量控制，限制 AI 智能体能够在哪里以及如何行动。目标是为 AI 智能体能够触及的范围设定一道硬边界。例如，如果凭据从未进入沙箱，那么无论问题是由用户、模型找到的“创造性”路径，还是攻击者引起的，凭据都不可能被窃取。

严密的边界也意味着可以放宽监督。Claude Code 的参考 devcontainer 正是为此而存在：让 AI 智能体可以在无人值守的情况下运行，无需逐项审批操作。

AI 智能体调用的模型。 这里采用的机制包括系统提示词、分类器、探针和训练调整。由于模型具有概率性，这些机制只能塑造 AI 智能体倾向于做什么，而不能限制它理论上能够做什么。

这些防御措施非常强大。在 Gray Swan 的 Agent Red Teaming 基准测试中——该测试用于评估模型遭受提示词注入的可能性——Claude Opus 4.7 将单次尝试的攻击成功率控制在约 0.1%，经过 100 次自适应尝试后，成功率约为 5%～6%。Claude Code 自动模式能够在执行前捕获约 83% 的过度积极行为。然而，即使采用业界领先的防御措施，模型层的保护也永远不可能达到 100% 的有效性，因此它无法单独承担全部防御任务。

AI 智能体能够访问的外部内容。 MCP 服务器、第三方插件和 Web 搜索工具都会将来自你无法控制的来源的内容送入 AI 智能体的上下文。经过审计的连接器并不等同于经过审计的数据——例如，一个通过了恶意软件检查的 GitHub 连接器，仍然可能将遭到投毒的 README 直接加载到模型的上下文中。以细粒度限制工具权限，有助于缩小爆炸半径。例如，一个仅拥有数据库只读权限的 AI 智能体，其部署范围可以远大于一个能够向生产环境写入数据的 AI 智能体。

不同的防御措施应当相互重叠、彼此补充。当环境层防御不可用时，模型层就必须承担更多责任（Claude Code 的自动模式正是为此而设计）。在本地，环境层和模型层防御可以抵御恶意工具输出；与此同时，还可以通过限制工具的能力和访问权限，在链路的更上层增加防御。

隔离 AI 智能体的模式

下面我们将重点关注环境层，介绍三种隔离模式，以及如何针对各个 Claude 平台——claude.ai、Claude Code 和 Cowork——对它们进行调整。这些设计都是我们逐步探索出来的，其间不断权衡我们需要 AI 智能体具备的能力，以及要求用户介入的程度。

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

尽管 claude.ai 最广为人知的是聊天界面，但它也可以编写和运行代码、生成文件以及调用连接器。当 Claude 在 claude.ai 中运行代码时，代码会在隔离基础设施上的 gVisor 容器中执行。AI 智能体完全运行在服务器端；本地计算机不会运行任何代码，文件系统也是临时的（按会话创建）。其爆炸半径极小，但 Claude 能够完成的工作上限同样很低——它既没有持久化工作区，也无法访问用户的文件系统。

这也意味着 claude.ai 面对的是一种更为传统的威胁模型。我们并不是在保护用户的计算机免受 AI 智能体影响，而是在保护自己的基础设施，并将各个租户彼此隔离。claude.ai 上线前的大部分工作都集中在传统安全领域，例如网络配置、内部服务身份验证和编排。

这项工作再次印证了安全领域最古老的教训：最薄弱的一层，往往是你自己构建的那一层。与 AI 智能体存在的时间相比，gVisor 和 seccomp 在资源充足的攻击者面前已经历了长得多的加固过程，因此评审工作主要集中在我们围绕它们构建的较新组件上。稍后我们还会回到这一点，因为我们的自定义代理恰恰也是在影响最严重的事故中出现故障的组件。

模式二：人类参与闭环的沙箱（Claude Code）

Claude Code 运行在用户的计算机上，可以访问其文件系统、shell 和网络。如果没有这些权限，编程 AI 智能体的实用性就会十分有限，因此必须找到一种安全授予这些访问权限的方法。

一种方法是依赖人类参与闭环。这种方案之所以仅对 Claude Code 切实可行，是因为它的普通用户是熟悉编程环境的开发者：他们能够阅读 bash，知道 rm -rf 的作用，而且每周都会多次运行来自不受信任来源的 npm install。这意味着，当“允许此操作”的对话框弹出时，他们很可能具备足够的专业知识，能够准确评估 AI 智能体试图执行的操作及其风险。基于这一点，Claude Code 上线时采用了尽可能简单的防御机制：允许读取操作，而写入、bash 和网络访问则需要审批。

然而，正如前文所述，审批疲劳在几周内就出现了。具有讽刺意味的是，这意味着一个原本旨在提供监督的功能，反而可能产生相反的效果——一些用户可能会直接不再留意审批内容。为缓解草率审批的问题，我们首先发布了一个操作系统级沙箱（macOS 上使用 Seatbelt，Linux 上使用 bubblewrap），以强化安全边界：允许读取，允许在工作区内写入，但默认禁止网络访问。在沙箱内，AI 智能体基本可以不受打断地运行。结果是权限提示减少了 84%；我们还将该运行时开源，使这一边界可供审计。

我们的匿名使用数据还显示，经验丰富的用户启用自动批准的频率大约是新用户的两倍，但他们也更频繁地在 AI 智能体执行过程中将其打断。经验丰富的用户更倾向于只在 AI 智能体偏离正轨时进行干预，而不是对每个步骤设置关卡。虽然这可能是人们与 AI 智能体协作方式的自然演变，但这种做法同样并不可靠，因为它要求用户具备足够的技术能力和专注度，才能从一开始就察觉偏移。随着模型能力提升，AI 智能体开始编写越来越复杂大胆的 bash 脚本，任何此类偏移都会变得更难察觉。而且，随着用户转向多智能体系统，这种方法也更难成为一种有效的监督策略。

从 2025 年年中到 2026 年 1 月，我们通过负责任披露计划收到了多份有关 Claude Code 漏洞的报告。其中三个漏洞针对的是在用户尚未同意任何操作之前便会执行的代码。要理解这是如何发生的，可以考虑最直接的一种情况：开发者克隆一个代码仓库以审查拉取请求，而该仓库中包含一个定义了钩子的 .claude/settings.json。由于 Claude Code 会在启动期间读取项目设置——早于显示标准的“Do you trust this folder?”提示——攻击者编写并提交的钩子就会自动执行。其余案例在结构上与此类似：在建立信任边界之前，就解析了来自尚未受信任目录的输入。

每个案例的修复方式都采用了相同思路：推迟对项目本地配置的解析和执行，直到用户接受信任提示之后。如果你正在构建类似的系统，应当像对待任何来自互联网的入站请求一样，对待打开项目、加载配置以及 localhost 监听器。不能仅仅因为它们看起来来自本地，并且在用户同意之前到达，就默认信任它们。

2026 年 2 月，在一次受控的内部红队演练中，一名研究人员成功通过网络钓鱼诱使一名员工使用恶意提示词启动 Claude Code。这次钓鱼看起来就像普通的协作请求——一封内容为“can you run this for me?”的电子邮件，并附上了一段可以直接粘贴的提示词——而提示词本身读起来也像常规的任务说明。但在一系列设置步骤中，它不动声色地要求 Claude 读取 ~/.aws/credentials、对内容进行编码，并通过 POST 请求将其发送到一个外部端点。在对该提示词进行的 25 次重试中，Claude 有 24 次成功完成了数据外泄。

这是一次直接提示词注入——攻击者的指令经由用户传入，而不是通过工具输出或获取到的内容传入。我们的模型层防御以用户意图为锚点——当输入指令的人正是用户时，分类器无法捕捉到任何异常。即使将同一段脚本交给一名人类承包商，他也会做出同样的操作。

在这种情况下，唯一有效的防御是运行环境，具体来说，就是无论意图为何都能阻止 POST 请求的出站流量控制，以及从一开始就让 ~/.aws 无法被访问的文件系统边界。

（当我们在内部 Slack 中分享这段有效的提示词以供讨论时，有人指出，一些内部 AI 智能体会读取 Slack。此时，这段载荷已经进入了环境。我们在线程中加入了一个金丝雀字符串，以便发现是否有任何系统读取了它。在一个 AI 智能体无所不读的世界里，调查工具本身也会成为攻击面。）

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

Claude Cowork 运行在用户桌面上，并可以访问由用户选择的工作区文件夹。由于该平台面向的是通用知识工作，而不是软件工程，因此普通用户熟练使用 bash 的可能性要低得多。

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

为实现这一点，我们的第一版 Claude Cowork 运行在一个完整的虚拟机中，使用平台供应商提供的虚拟机监控程序（macOS 上使用 Apple 的 Virtualization framework，Windows 上使用 HCS）。该虚拟机拥有自己的 Linux 内核、文件系统和进程表。用户选定的工作区和 .claude 文件夹会被挂载；除此之外，主机上的任何内容都不可见。凭证保留在主机的钥匙串中，永远不会进入客户机。该设计旨在防范 Claude 在某个时刻出现不一致行为的可能性。遭到入侵的 Claude 仍然可能破坏工作区文件夹内的内容，因此，这一架构要确保它只能访问该文件夹中的内容（直到用户添加连接器为止），并确保由用户控制其中挂载的内容。

在最初的架构中——我们称之为完整虚拟机模式——AI 智能体循环本身运行在客户机内部，因此 Claude 以普通 Linux 用户的身份执行，并不知道自己处于沙箱之中。相比之下，在 Claude Code 中，一个特权进程位于沙箱之外，逐条命令决定是否强制应用沙箱；有说服力的注入提示词或因审批疲劳导致的点击，都可能让这个进程在沙箱外执行某些操作。而在完整虚拟机模式中，不存在持有逃生密钥的外部进程，因此也没有任何组件有权批准例外。

然而，我们很快意识到，让整个 AI 智能体在完整虚拟机模式下运行会引发实际问题：虚拟机启动期间的任何故障都会导致 Cowork 完全不可用。将 AI 智能体循环移到虚拟机之外，同时继续在虚拟机内部执行代码，使 Claude 即使遇到问题也仍然可以响应用户并协助调试，而不是因错误而卡死。由于虚拟机仍然对 AI 智能体执行的代码实施文件系统和网络控制，这项变更对安全性的影响很小。

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

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

这也是另一个例子，说明你自己构建的软件通常是最薄弱的环节。超级管理程序、seccomp 和 gVisor 在我们的各个产品中表现一直很稳定。而我们的自定义白名单代理是那个失败的部分。

企业安全团队在评估 Claude Cowork 时问道："为什么我们的 EDR 看不到内部情况？"答案是，同样让 Claude 保持隔离的机制也阻止了基于主机的端点检测和响应（EDR）进入。从 EDR 的角度来看，Claude Cowork 是一个不透明的超级管理程序进程。它无法检查虚拟机内部。

隔离降低了可见性，而不透明对那些合规态势依赖端点可见性的团队来说是个问题。我们目前的缓解措施是使用基于拉取的 OTLP 导出，让管理员能够事后检索事件日志，但这不同于实时监控。如果你正在构建类似的东西，应该尽早为这场讨论预留资源。

相信智能体读取的内容

企业经常问我们如何保护 MCP 连接。这是个好问题，但更宽泛的问题是：不仅仅关于 MCP。提供给智能体的任何外部资源都代表两种风险：传统意义上的代码执行风险（供应链风险），以及上下文注入向量。传统的依赖审计（固定版本、验证签名、审查源代码）可以解决第一种风险，但会忽略第二种。

本地与远程的区别比看起来更重要。本地安装的工具是可审计的。你可以阅读代码、固定版本，并确保它不会在你的使用过程中改变。远程工具——一个托管的 MCP 服务器、一个云连接器——在你批准它之后的任何时刻都可以改变行为；你的安装时信任决策可能不再适用。我们的连接器目录通过持续审查来处理这个问题，但任何超出其范围的内容都应该被视为不可信。先在伪造数据上运行它，在一个恶意工具造成伤害的影响范围受限的环境中。

工具输出即使在工具本身可信时也是一个攻击面。早前提到的 GitHub README 例子恰好就是这种情况；对网页应用的任何输入扫描都需要以同样的严格程度应用于支持网络的工具结果。尽管这会增加延迟且不是完美的防御，我们倾向于实时检查：一旦被污染的工具返回值引导智能体泄露数据，日志只会显示一个成功的、授权的 API 调用。没有事后信号可以追踪。

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

模型和产品发展很快。随着它们的发展，风险形态和演变，我们的缓解措施必须跟上步伐。

持久化记忆污染

跨会话持久保存的智能体上下文比例在不断增长——这包括产品记忆、CLAUDE.md 文件、挂载的工作区以及计划内和长时间运行的智能体的状态目录。落在这些任何一个中的注入会在智能体每次启动时被重新加载。随着越来越多的智能体状态在会话中存活下来，我们面临经典后利用意义上新持久化机制的威胁。良好的分类器在会话启动时需要变得更常见。

多智能体信任升级

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

智能体身份

Claude Cowork 对智能体身份的回答是具体的：凭证保存在主机密钥链中，虚拟机获得一个按会话范围缩小的令牌，该令牌可独立于用户的令牌被撤销。然而，我们开始面对跨平台智能体身份的更广泛问题。智能体应该拥有自己的主体身份，还是应该作为用户的扩展并继承用户的权限？最终，答案可能是两者的混合。

随着智能体变得越来越强大，攻击面在不断变化。我们看到的失败类型可能会在整个行业和实验室中重复出现。我们需要对智能体特定的安全态势进行集体投资，从共享基准和披露规范到通用身份标准和跨厂商的红队测试。这篇文章聚焦于隔离，但那只是智能体安全图景的一部分。关于治理、可观测性和堆栈其余部分，参见 NIST 的 AI 智能体身份和授权项目、澳大利亚 ACSC 与 CISA 和英国 NCSC 领导的六个机构关于采纳智能体 AI 的指导，以及 ISO/IEC 42001，AI 管理标准。我们的 Glasswing 倡议是一项贡献，但我们期待与合作伙伴和竞争对手在这一关键问题上进行合作。

简而言之，我们不断回到的几个原则：

首先在环境层设计隔离，然后在模型层引导行为。教会我们最多的两个事件——员工钓鱼和第三方白名单披露——都是数据外泄事件，其中数据通过允许的路径流出。在每一个情况中，模型层都帮不上忙；没有什么异常供其捕捉。当所有概率性防御都失效时，确定性边界就是被击中的。

将隔离强度与用户的监督能力相匹配。能读 bash 的开发者和不能的知识工作者不是在运行相同的威胁模型。用户是否能够评估智能体即将要做的事情这个问题应该有助于确定隔离策略，而以任何一种方式回答错误——对专家来说摩擦太多，对非专家来说信任太多——都是其自身的失败。

警惕自定义组件。经过战场考验的超级管理程序