我们如何在各产品中对 Claude 实施隔离约束

#我们如何在各产品中对 Claude 实施隔离约束

随着智能体（agent）能力越来越强，其潜在的影响范围（blast radius）也随之扩大。真正的工程问题在于：如何为这一影响范围设一个上限。下面是我们在为 claude.ai、Claude Code 和 Cowork 构建隔离约束（containment）机制时积累的经验。

十二个月前，如果有人提出要授予 Claude 足以搞垮 Anthropic 某项内部服务的访问权限，我们会毫不犹豫地拒绝。而今天，这种级别的访问权限已成常态，Anthropic 的开发者也因此更加高效。这类部署的风险由两部分组成：一是故障发生的可能性，二是一旦发生能造成多大破坏。安全防护（safeguards）与模型训练的进步，已经稳步压低了第一部分；而第二部分——理论上的影响范围——却随着能力与访问权限的扩张只会越来越大。然而，当智能体能够完成过去需要一个人甚至一个团队才能做的工作时，"不部署"的代价就大到足以让风险—收益的天平明显倒向采用一侧，前提是产品能够被做到安全。于是工程问题就变成了：如何为影响范围设一个上限。

_当能够为自主智能体的相对破坏程度设定边界时——例如通过对其运行环境的控制——高效用的能力就会成为部署的理由。Claude Mythos Preview 就是一个例子：2026 年 4 月，它的影响范围被判定为过高，因而没有发布。不过我们预计，随着防御方加固关键系统、防护手段日渐成熟，具备类似能力水平的模型将会逐步适合更广泛地发布——尽管某些风险始终会存在。模型能力是决定智能体部署总风险的一个重要因素。_

大体上有两条路径可以做到这一点。

第一条是通过人在回路（human-in-the-loop）来监督智能体的行为。Claude Code 过去靠在每一轮向用户请求许可，来防止智能体采取意料之外的动作。理论上这行得通，但我们发现这种方式并不可靠。我们的遥测数据显示，用户批准了大约 93% 的许可请求。用户看到的批准请求越多，对每一条投入的注意力就越少，久而久之，其监督的审慎程度会大幅下降。我们最近构建了 Claude Code 的自动模式（auto mode），用以将较安全的批准动作自动化，从而缓解这种"批准疲劳"（approval fatigue）。尽管如此，漏洞依然存在——任何概率性防御都有非零的漏报率。¹

第二条为影响范围设上限的路径——也是本文大部分内容的重点——是隔离约束。我们不去监督智能体做了什么，而是通过强制设定访问边界来监督它"能够"做什么，例如借助沙箱（sandbox）、虚拟机（virtual machine）和出站流量控制（egress control）。这正是 Anthropic 工程团队投入精力最多的地方，也是许多最令人意外的安全故障发生的地方。

过去两年里，我们发布了三款主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。它们各自面向不同的受众，因此需要不同的隔离约束架构。本文分享哪些做法经受住了考验、哪些出了问题，以及我们在此过程中对智能体安全的认识。

三类风险，三个防御组件

针对智能体的安全风险可归入三类之一：

用户滥用（User misuse）： 用户——无论是出于恶意还是疏忽——指使智能体去做有害的事情。这包括从要求智能体绕过某个他觉得碍事的检查，到运行一条他并不理解的破坏性命令，再到明确指定要造成损害，不一而足。

模型失当行为（Model misbehavior）： 智能体采取了无人要求的有害动作。随着我们的模型不断改进，它们在大多数行为评测上变得更加对齐，但这并不意味着风险必然会缩小。能力较弱的模型更容易误判形势、犯下明显错误。能力更强的模型犯错更少，但它们也更擅长找到通往目标的意外路径，往往是绕过那些没人想到要写下来的限制。

在 Anthropic，我们见过 Claude 模型为了完成某项任务而"好心"地逃出沙箱，见过它查看 git 历史以找到某道编程测试题的答案，也见过它自发地识别出自己正在被哪个基准测试运行，从而去解密该测试的答案密钥。每一款模型都会带来一组新的能力，而这些能力有时会被以出人意料的方式派上用场。

外部攻击者（External attackers）： 智能体通过工具、文件或网络访问等外部途径遭到攻击。这一类既包括提示注入（prompt injection），也包括针对智能体运行时、编排层或代理（proxy）的传统攻击。

在构建隔离约束与防御系统时，我们把防御措施应用到三个主要组件上：

智能体运行的环境。 我们通过进程沙箱、虚拟机、文件系统边界和出站流量控制，来约束智能体能在何处、以何种方式行动。目标是为智能体能触及的范围设定一条硬边界。举例来说，如果凭据从不进入沙箱，那么无论成因是用户、是模型找到了一条"有创意"的路径，还是攻击者，这些凭据都无法被窃取。

一个严密的边界还意味着你可以放松监督。Claude Code 的参考 devcontainer 之所以存在，正是为了让智能体能够在无人值守的情况下运行，而无需对每一个动作逐一批准。

智能体咨询的模型。 这里的机制包括系统提示、分类器、探针以及训练层面的改动。由于模型是概率性的，这些手段只能塑造智能体"倾向于"做什么，而不能决定它在理论上能够做什么。

这些防御很强大。在 Gray Swan 的智能体红队基准测试（该测试检验对提示注入的易感程度）中，Claude Opus 4.7 在单次尝试下把攻击成功率压制在大约 0.1%，在 100 次自适应尝试之后约为 5—6%。Claude Code 的自动模式能在约 83% 的"过度积极"行为执行之前将其拦下。然而，即便拥有最一流的防御，模型层的保护也永远不会 100% 有效，这正是它无法独当一面的原因。

智能体能触及的外部内容。 MCP 服务器、第三方插件和网络搜索工具，都会从你无法控制的来源把内容喂入智能体的上下文。一个经过审计的连接器（connector）并不等同于经过审计的数据——举例来说，一个 GitHub 连接器完全可以把一份被投毒的 README 直接加载进模型上下文，尽管它通过了恶意软件检查。细粒度地限制工具权限有助于收窄影响范围。例如，一个只有只读数据库访问权限的智能体，其可部署范围要远比一个能向生产环境写入数据的智能体广泛得多。

各层防御应当相互重叠、彼此补充。当环境层防御不可用时，模型层就必须顶上（这正是 Claude Code 自动模式的设计初衷）。在本地，环境与模型防御可以抵御恶意的工具输出，但还可以在链路更上游通过限制工具的能力与访问权限来增加防御。

_需要防御的三个组件：模型、模型运行的环境，以及智能体能触及的外部内容。_

约束智能体的若干模式

聚焦于环境层，我们描述三种隔离模式，以及它们如何针对每一款 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 的漏洞报告。其中三个漏洞针对的是在用户尚未同意任何事情"之前"就执行的代码。要理解这为何可能，请看最直接的一个案例：某开发者克隆一个代码仓库以审查一个拉取请求（pull request），而该仓库里包含一个 .claude/settings.json，其中定义了一个钩子（hook）。由于 Claude Code 在启动期间——也就是在弹出标准的"你信任这个文件夹吗？"提示之前——就会读取项目设置，攻击者预先编写并提交的那个钩子便会被自动执行。其余几个案例在结构上与此类似：来自尚未被信任目录的输入，在信任边界建立之前就被解析了。

每一个案例的修复方式都呈同样的形态：把对项目本地配置的解析与执行，推迟到用户接受信任提示之后。如果你在构建类似的东西，请像对待任何来自互联网的入站请求那样，去对待"打开项目""加载配置"和"本地监听端口"这些动作。它们不应仅仅因为感觉上是本地的、且发生在用户同意之前，就被隐式地信任。

#### 我们漏掉的风险：用户本身作为注入途径

2026 年 2 月，在一次受控的内部红队演练中，一名研究者成功地通过钓鱼，让一位员工用一个恶意提示启动了 Claude Code。那封钓鱼邮件看起来就像普通的协作——一封"能帮我跑一下这个吗？"的邮件，附带一段可直接粘贴的提示——而提示本身读起来也像常规的任务说明。但在若干准备步骤中间的某处，它不动声色地要求 Claude 读取 ~/.aws/credentials、对内容进行编码，然后 POST 到一个外部端点。在那个提示的 25 次重试中，Claude 有 24 次完成了数据窃取。

这是一次"直接"的提示注入——攻击者的指令是通过用户送达的，而非通过工具输出或抓取的内容。我们的模型层防御锚定于用户意图——当敲下这条指令的正是用户本人时，分类器根本无从捕捉到任何异常之处。换成一个拿到同一份脚本的人类承包商，也会做出同样的事。

在这种情况下唯一站得住脚的防御是环境层，具体而言就是无论意图如何都能拦截那次 POST 的出站流量控制，以及一开始就把 ~/.aws 挡在可及范围之外的文件系统边界。

（当我们把那个可用的提示分享到内部 Slack 供讨论时，有人指出某些内部智能体会"读取"Slack。此时该载荷已经变成了环境中弥漫的存在。我们在那条讨论串里加了一个金丝雀字符串（canary string），以便一旦有任何东西把它捡走，我们就能察觉。在一个智能体无所不读的世界里，用于调查的工具本身也是一种攻击面。）

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

Claude Cowork 运行在用户的桌面上，可访问由用户选定的一个工作区文件夹。由于该平台是为通用知识工作、而非软件工程而构建的，其普通用户精通 bash 的可能性要低得多。

因此，人在回路沙箱这一策略未必能照搬过来；不应指望一位非技术背景的知识工作者去判断诸如 find . -name "\*.tmp" -exec rm {} \\; 这样的 bash 咒语。当批准一个例外所需的专业能力是普通用户并不具备的时候，管理员就应当设定一条绝对的、始终生效的边界。

为实现这一点，我们第一版的 Claude Cowork 运行在一个完整的虚拟机里，使用平台厂商提供的虚拟机监控程序（hypervisor）（macOS 上是苹果的 Virtualization 框架，Windows 上是 HCS）。这个虚拟机有自己的 Linux 内核、自己的文件系统和自己的进程表。用户选定的工作区和 .claude 文件夹被挂载进来；宿主机上的其他任何东西都不可见。凭据留在宿主机的密钥链（keychain）中，从不进入客户机。这一设计防的是这样一种可能：Claude 在某个时刻会以不对齐的方式行事。一个被攻陷的 Claude 仍然可能破坏工作区文件夹内部的东西，因此该架构的设计目标就是确保那是它"唯一"能够触及的范围（在用户添加连接器之前），并且由用户控制那里挂载了什么。

在最初的架构里——我们称之为完整虚拟机模式（full-VM mode）——智能体循环本身就运行在客户机内部，因此 Claude 是作为一个普通的 Linux 用户执行的，并不知道自己身处沙箱之中。把这和 Claude Code 对比一下：在 Claude Code 中，有一个特权进程位于沙箱之外，逐条命令地决定是否强制执行沙箱；一段有说服力的注入提示，或一次因疲劳而点下的批准，都可能让那个进程去运行某些未经沙箱隔离的东西。而在完整虚拟机模式里，外部并没有哪个进程握着"逃生舱"的钥匙，因此也就没有哪个组件拥有授予例外的权限。

_Claude Cowork 虚拟机的六大隔离机制。其中两项在客户机内核之外强制执行，因此即便智能体在虚拟机内部取得了 root 级访问权限，它们依然能够存活。另外四项由客户机内部强制执行，并被刻意保持极简，因为其余的重担由外层承担。_

不过，我们很快意识到，让整个智能体都跑在完整虚拟机模式里会带来一些实际问题：虚拟机启动过程中的任何故障都会让 Cowork 变得无法使用。把智能体循环移到虚拟机"外部"，同时把代码执行留在虚拟机"内部"，这样即便出错，Claude 也仍能响应用户、协助排查问题，而不是卡死在一个错误上。这一改动对安全的影响极小，因为虚拟机仍然对智能体所执行的代码强制实施文件系统与网络控制。

另外，我们也把本地 MCP 服务器移到了虚拟机外部。让它们运行在虚拟机内部会使其更难审计，在虚拟机更新时造成脆弱的依赖问题，而且无法支持那些需要与本地进程（例如数据库）交互的 MCP——这类服务器无论如何都得跑在宿主机上。这一改动使 Claude Cowork 与本地 MCP 服务器在 Claude Desktop 中已有的工作方式保持一致：把它们当作用户可能选择安装的任何软件来对待，并把"启用哪些本地 MCP（如果有的话）"的决定权交给管理员。远程 MCP 服务器不受影响，因为它们并不运行在用户的机器上。

_把智能体循环放在虚拟机内部意味着，虚拟机的任何故障都会导致 Cowork 无法使用。宿主机模式（host-mode）更可靠，因为即便虚拟机崩溃，智能体仍能响应；而它通过隔离代码执行，依然提供了重要的安全保证。_

文件系统控制是另一项重要的架构选择。Claude 需要能够访问宿主机上的"某些"文件才有用处，但我们希望把影响范围降到最低，并就本地文件访问向用户提供透明度。我们发现，提供不同的文件挂载模式有助于细粒度地控制风险；Claude Cowork 提供只读、读写、读写但不可删除三种模式。这里有一个潜在的坑：符号链接（symlink）的解析必须发生在路径校验"之前"、而非之后，否则一个位于已授权文件夹内部的符号链接就可能指向外部并逃逸。对于企业客户，我们允许管理员通过 MDM 设置中的挂载路径白名单来控制这一点。

#### 我们漏掉的风险：经由一个已批准域名进行数据窃取

一个经由已批准域名进行数据窃取的清晰案例，来自一次第三方披露。Claude Cowork 的出站白名单正确地放行了通往 api.anthropic.com 的流量——不调用我们自己的 API，产品就无法运转。在这个案例中，一个被放置在用户已挂载工作区里的恶意文件，携带了隐藏的指令以及一个由攻击者掌控的 API 密钥。Claude 遵循这些指令，读取了工作区里的其他文件，并使用攻击者的密钥调用了 Anthropic 的 Files API。出站代理检查了目的地，看到是 api.anthropic.com，便放行了。这些文件被上传到了攻击者的 Anthropic 账户。沙箱运转得完美无缺，然而数据还是被窃取了出去。

此前，我们把白名单理解为一个目的地过滤器，一个告诉 Claude"这些域名可以对话"的东西。但更好的理解方式，也许是把它看作一次能力授予（capability grant）。通过白名单上任何一个域名所能触及的每一项功能，如今都成了一处攻击面。允许 api.anthropic.com，就意味着允许把文件上传到任意的 Anthropic 账户。

我们通过在虚拟机内部部署一个防御性的中间人代理（man-in-the-middle proxy）来修复此问题，该代理会拦截通往我们 API 的流量。它只放行携带虚拟机自身所配发会话令牌（session token）的请求；攻击者内嵌的密钥会被代理拒绝。它还会拦截那些可能启用服务器端抓取（server-side fetch）的头部。这个代理之所以放在虚拟机内部、而非我们的服务器上，是因为只有虚拟机才知道来源出处（provenance）——从服务器的角度看，一个来自 Cowork 的请求与任何其他 API 客户端的请求无从区分。

_上图：通往 api.anthropic.com 的流量被放行，导致数据外泄。下图：用一个中间人代理拦截通往我们 API 的流量，从而修复该问题。_

这也是"你自己搭建的软件往往是最薄弱的一环"这一原则的第二个实例。贯穿我们各款产品的虚拟机监控程序、seccomp 和 gVisor 一直都很可靠。出问题的，是我们自定义的那个白名单代理。

#### 我们漏掉的风险：虚拟机隔离把端点检测软件也一并挡在了外面

在评估 Claude Cowork 时，企业安全团队会问："为什么我们的 EDR 看不到里面？"答案是：那套把 Claude 约束住的隔离机制，同样也把基于宿主机的端点检测与响应（endpoint detection and response）挡在了外面。从 EDR 的视角看，Claude Cowork 是一个不透明的虚拟机监控进程。它无法检查客户机内部。

隔离会降低可见性，而不透明对那些合规态势依赖于端点可见性的团队来说是个问题。我们目前的缓解手段，是使用基于拉取的 OTLP 导出，让管理员事后能够取回事件日志，但这与实时监控并不是一回事。如果你在构建类似的东西，请尽早为这场对话做好预算。

信任智能体所读取的内容

企业常常问我们如何保护 MCP 连接的安全。这是个好问题，但更贴切的问题范围要比 MCP 本身更广。提供给智能体的任何外部资源，都同时代表着两种风险：一是传统供应链意义上的代码执行风险，二是一个提示注入途径。传统的依赖审计（锁定版本、验证签名、审查源码）解决的是第一种，却漏掉了第二种。

远程与本地之分，比看上去更重要。 一个本地安装的工具是可审计的。你可以读它的代码、锁定它的版本，并确信它不会在你不知情的情况下发生改变。而一个远程工具——一个托管的 MCP 服务器、一个云连接器——则可能在你批准之后的任何时点改变其行为；你在安装时做出的信任决定可能已不再适用。我们的连接器目录通过持续评审来应对这一点，但目录之外的任何东西都应被视为不受信任。先拿假数据去跑它，并且要在一个即便工具是恶意的、其影响范围也能被约束住的环境里跑。

即便工具本身可信，工具输出仍是一处攻击面。 前面提到的 GitHub README 例子正是这种情况；任何应用于网页的输入扫描，都需要以同样的严格程度应用于联网工具的返回结果。尽管这会增加延迟、也并非完美的防御，我们仍倾向于做实时检查：一旦被投毒的工具返回已经诱导智能体把数据窃取出去，日志里显示的不过是一次成功的、经过授权的 API 调用。事后根本没有可供追查的信号。

在 Claude Code 和 Claude Cowork 中，工具调用会经由代理进行路由，这些代理强制执行网络与文件策略，并能在返回值进入模型上下文之前对其进行检查。执行这项检查的分类器可以是一个小而快的模型；它不必是那个负责推理的模型。

展望未来

模型与产品都在快速演进。随着它们演进，风险也会变形、演化，我们的缓解手段必须跟上步伐，与之相匹配。

持久化记忆投毒。 智能体上下文中能够跨会话保留的那部分，正在不断增长——这包括产品记忆、CLAUDE.md 文件、已挂载的工作区，以及计划任务和长时运行智能体的状态目录。落入其中任何一处的注入，都会在智能体每次启动时被重新加载。随着越来越多的智能体状态能够在会话结束后存活下来，我们正受到经典"后渗透"（post-exploitation）意义上的新型持久化机制的威胁。在会话启动时设置的良好分类器，将需要变得更加普遍。

多智能体信任升级。 一方面，子智能体（sub-agent）能够隔离不受信任的内容，向上层主智能体返回结构化的事实、而非原始文本。另一方面，这也可能被滥用：如果一个子智能体的输出被当作比原始工具结果更可信来对待——只因为这样的输出来自"我们自己人"——那么就引入了一条新的提示注入途径。在多智能体系统中，在"分配不同信任级别"与"因此变得易受信任升级之害"之间，存在一种权衡。

智能体身份。 Claude Cowork 对智能体身份给出的答案是具体的：凭据留在宿主机密钥链中，虚拟机获得一个按会话配发、权限收窄的令牌，而该令牌可以独立于用户自身的令牌被吊销。然而，我们正开始面对一个更宏观的问题：跨平台的智能体身份。一个智能体究竟应当拥有自己的主体身份（principal identity），还是应当作为用户的延伸、继承用户的权限？归根结底，答案也许是两者的融合。

随着智能体能力不断增强，攻击面也在持续移动。我们所见过的这些故障类型，很可能在各行各业和各实验室中被反复重现。我们需要对智能体专属的安全态势进行集体投入，从共享的基准测试和披露规范，到通用的身份标准和跨厂商的红队演练。本文我们聚焦于隔离约束，但那只是智能体安全图景中的一部分。关于治理、可观测性以及技术栈的其余部分，请参阅 NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 联合 CISA 和英国 NCSC 牵头的六机构《审慎采用智能体 AI 服务》指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中一份贡献，但我们期待在这一关键议题上与合作伙伴乃至竞争对手共同努力。

小结

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

先在环境层为隔离约束做设计，再在模型层去引导行为。 教给我们最多的两起事件——员工钓鱼，以及第三方的白名单披露——都是数据外泄（egress）的案例，数据是从一条被允许的路径流出去的。在这两起事件中，模型层都帮不上忙；对它而言没有任何异常可供捕捉。当所有概率性手段都失手时，最终被撞上的正是那条确定性的边界。

让隔离强度与用户的监督能力相匹配。 一个能读懂 bash 的开发者和一个读不懂 bash 的知识工作者，跑的并不是同一个威胁模型。用户能否评估智能体即将做什么，这个问题应当有助于决定隔离约束策略；而在任一方向上答错——对专家施加过多摩擦，或对非专家给予过多信任——本身就是一种失败。

警惕自定义组件。 身经百战的虚拟机监控程序、系统调用过滤器和容器运行时，所经受过的对抗性审视，比你能搭建出的任何东西都要多。在本文描述的每一次部署中，标准原语都稳如磐石，反倒是我们围绕它们自己搭建的那些部件暴露出了缺陷。

归根结底，尽管智能体也许是一类新的软件，但它们在系统层面的交互并不是新的。它们仍旧会读取文件、打开套接字、派生进程；这使得用成熟的工具来做隔离约束成为一种至关重要的、切实可行的防御。随着 AI 发展，部署的风险—收益平衡会不断移动，但为影响范围设一个硬性上限，往往能把这一平衡推向正确的方向。

#### 脚注

1. Claude Code 的自动模式把命令批准委托给一个基于模型的分类器；它以漏掉一部分有风险的命令（约 17% 的过度积极动作会被放过）为代价，把摩擦降到最低（约 0.4% 的良性命令被拦截）。因此它是沙箱内部纵深防御的一层，而不是沙箱的替代品。

PRIMARY_SOURCE: https://www.anthropic.com/engineering/how-we-contain-claude