我们如何在各款产品中围堵 Claude

核心思想

面对能力日益强大的智能体,降低”失败概率”只解决了风险的一半,另一半”爆炸半径”只会随能力与权限扩张而膨胀。Anthropic 主张:与其监督智能体”做了什么”,不如在环境层用沙箱、虚拟机、出站管控等确定性手段限死它”能做什么”。文章以 claude.ai、Claude Code、Claude Cowork 三款产品的隔离架构为线索,复盘多起真实安全事故,得出核心取舍——隔离强度要匹配用户的监督能力,且自研组件往往是最脆弱的一环。

来源

原文:How we contain Claude across products(Anthropic Engineering,2026-05-26)

十二个月前,如果有人提议给 Claude 授予足以”搞垮一项 Anthropic 内部服务”的权限,我们会想都不想就拒绝。可如今,这种级别的权限已是家常便饭,而 Anthropic 的开发者也因此更高效了。这类部署的风险由两部分构成:一是失败发生的概率,二是一旦失败能造成多大破坏。安全护栏和模型训练的进步,持续压低了前者;而后者——理论上的爆炸半径——却只会随着能力和权限的扩张而增长。然而,当智能体能够胜任过去需要一个人、甚至一个团队才能完成的工作时,不去部署的代价变得如此之高,以至于风险与回报的天平会大幅倒向”采用”一侧——前提是产品能够做到足够安全。于是,工程上的问题就变成了:如何为爆炸半径封顶。

当一个自主智能体造成的相对破坏能够被设限时——比如通过控制它所处的环境——高价值的能力就足以成为部署它的理由。Claude Mythos Preview 就是这样一个例子:它的爆炸半径在 2026 年 4 月被判定为太高,不宜发布。不过我们预计,随着防御方加固关键系统、安全护栏日趋成熟,把具备类似能力水平的模型更广泛地发布出来终将变得合适——尽管总会残留一些风险。模型能力是一个智能体部署总体风险中的重要一环。

要为爆炸半径封顶,大体上有两条路。

第一条是通过人在回路来监督智能体的行为。Claude Code 此前防范智能体执行非预期操作的方式,就是在每一步都向用户征求许可。理论上这行得通,但我们发现这种做法并不可靠。我们的遥测数据显示,用户对大约 93% 的许可提示都点了同意。一个用户看到的许可越多,对每一个就越不上心,久而久之,他在监督上的尽职程度便大打折扣。我们最近构建了 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 mode 能在大约 83% 的过度积极行为执行之前将其拦下。然而,即便配备了业界一流的防御,模型层的防护也永远做不到 100% 有效——这正是它无法单独立足的原因。

智能体能够触及的外部内容。 MCP 服务器、第三方插件和网络搜索工具,都会把来自你无法掌控的来源的内容喂进智能体的上下文。一个经过审计的连接器,并不等同于经过审计的数据——比如一个 GitHub 连接器,尽管通过了恶意软件检查,却可能把一份被投毒的 README 直接加载进模型的上下文。对工具权限做细粒度的限制有助于限制爆炸半径。举例来说,一个只有数据库只读权限的智能体,可以比一个能向生产环境写入的智能体部署得广泛得多。

各层防御应当相互重叠、彼此补充。当环境层防御不可用时,模型层就得顶上(Claude Code 的 auto mode 正是为此而设计)。在本地,环境与模型防御可以防范恶意的工具输出;而在更上游,也可以通过限制工具自身的能力与访问权限来叠加防御。

需要防御的三个组件:模型、模型运行所在的环境,以及智能体能够触及的外部内容。

围堵智能体的几种模式

聚焦于环境层,我们介绍三种隔离模式,以及它们如何针对各个 Claude 平台——claude.ai、Claude Code 和 Cowork——量身定制。每一种设计都是我们逐步摸索出来的:在”我们需要智能体具备的能力”与”需要用户介入的程度”之间找到平衡点之后。

模式一:临时容器(claude.ai 代码执行)

尽管 claude.ai 最为人熟知的身份是一个聊天界面,但它也能编写并运行代码、生成文件、调用连接器。当 Claude 在 claude.ai 内部运行代码时,它是在隔离基础设施上的一个 gVisor 容器里运行的。这个智能体完全在服务器端;没有任何代码在本地机器上运行,文件系统也是临时的(按会话隔离)。爆炸半径被压到了最小,但 Claude 能做之事的上限也同样很低——没有持久化的工作区,也无法访问用户的文件系统。

这也使得 claude.ai 适用一种更传统的威胁模型。我们要保护的不是用户的机器免受智能体侵害;我们要保护的是我们自己的基础设施,以及让各个租户彼此隔离。我们为 claude.ai 所做的上线前工作,主要是网络配置、内部服务鉴权、编排这类传统安全工作。

那段工作再次印证了安全领域最古老的一条教训:最薄弱的那一层,往往是你自己亲手搭起来的那一层。gVisor 和 seccomp 在智能体 AI 诞生之前,就已经针对资源雄厚的对手被加固了很久很久;所以审查的精力都投向了我们围绕它们新搭的那些部件。这一点我们稍后还会回来讲,因为我们那个自研代理,正是在我们最严重的一次事故中被攻破的那一块。

模式二:人在回路的沙箱(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,而该仓库里包含一个定义了 hook 的 .claude/settings.json。由于 Claude Code 在启动过程中——也就是在弹出那个标准的”你信任这个文件夹吗?”提示之前——就会读取项目设置,于是攻击者编写并提交进去的那个 hook 便会自动执行。其余几个案例在结构上看起来都很相似:来自尚未受信任目录的输入,在信任边界尚未建立之前就被解析了。

每一例的修复办法都是同一个形状:把项目本地配置的解析与执行,推迟到用户接受信任提示之后再进行。如果你正在构建类似的东西,请把”打开项目""加载配置""监听 localhost”这些动作,当成来自互联网的任何一个入站请求来对待。不能仅仅因为它们感觉像是本地的、又赶在用户同意之前到来,就隐式地信任它们。

我们漏掉的风险:用户本身成了注入向量

2026 年 2 月,在一次受控的内部红队演练中,一名研究员成功钓鱼诱使一名员工带着一段恶意提示词启动了 Claude Code。这次钓鱼看上去就像一次寻常的协作:一封”能帮我跑一下这个吗?”的邮件,附带一段可以直接粘贴的提示词,而提示词本身读起来就像例行的任务说明。但在那些环境配置步骤之间的某处,它”温和地”请求 Claude 读取 ~/.aws/credentials,把内容编码,然后 POST 到一个外部端点。在对这段提示词的 25 次重试中,Claude 有 24 次完成了外泄。

这是一次直接提示注入——攻击者的指令是经由用户抵达的,而不是经由工具输出或抓取来的内容。我们的模型层防御锚定于用户意图——当下达指令的正是用户本人时,分类器没有任何异常可抓。换成一个人类外包人员拿到同样的脚本,也会做出同样的事。

在这种情形下唯一站得住脚的防御就是环境层,具体来说,是无论意图如何都会拦下那个 POST 的出站管控,以及一开始就把 ~/.aws 挡在可及范围之外的文件系统边界。

(当我们把这段能用的提示词发到内部 Slack 上讨论时,有人指出:某些内部智能体会读取 Slack。于是这段载荷成了环境噪声。我们往那条线程里加了一个 canary 字符串,这样一旦有什么东西把它捡了起来,我们就能察觉。在一个智能体什么都读的世界里,连调查工具本身也成了一块攻击面。)

模式三:本地虚拟机(Claude Cowork)

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

因此,人在回路的沙箱策略未必能直接照搬过来;不能指望一名非技术的知识工作者去判断 find . -name "*.tmp" -exec rm {} \; 这样的 bash 咒语。当批准一个例外所需要的专业知识超出了典型用户的能力时,管理员就应当设定一条绝对的、始终生效的边界。

为了实现这一点,我们第一版的 Claude Cowork 是在一个完整的虚拟机里运行的,使用平台自带的供应商虚拟机管理程序(macOS 上是 Apple 的 Virtualization 框架,Windows 上是 HCS)。这个虚拟机有自己的 Linux 内核、自己的文件系统、自己的进程表。用户选定的工作区和 .claude 文件夹会被挂载进去;宿主机上的其他一切都不可见。凭据留在宿主机的钥匙串里,从不进入这台客户机。这一设计防范的,是 Claude 在某个时刻表现出未对齐行为的可能性。一个被攻陷的 Claude 仍可能破坏工作区文件夹里的东西,所以这套架构的设计目标,就是确保那是它唯一能够触及的东西(直到用户添加连接器为止),并且确保由用户来掌控那里挂载了什么。

在最初的架构里——我们称之为 full-VM(全虚拟机)模式——agent loop 本身就跑在客户机内部,因此 Claude 是作为一个普通的 Linux 用户在执行,丝毫不知道自己被沙箱化了。拿它和 Claude Code 对比一下:在 Claude Code 中,一个特权进程坐镇于沙箱之外,逐条命令地决定是否对其强制施加沙箱;一段有说服力的注入提示词,或者一次因疲劳而点下的审批,都可能让那个进程去运行某个未被沙箱化的东西。而在这里,并不存在一个握着”逃生舱钥匙”的外部进程,因此也就没有任何一个组件有权去授予例外。

Claude Cowork 虚拟机的六大主要隔离机制。其中两个在客户机内核之外强制执行,因此即便智能体在虚拟机内拿到了 root 级访问权限,它们也能存活下来。另外四个由客户机强制执行,并被刻意保持最小化,因为剩下的防护由外层来承担。

然而我们很快意识到,让整个智能体都跑在 full-VM 模式下会带来现实问题:虚拟机启动过程中的任何一次失败,都会让 Cowork 变得无法使用。把 agent loop 移到虚拟机之外、同时把代码执行留在虚拟机之内,就能让 Claude 在遇到错误时仍可以回应用户、帮忙调试问题,而不是卡死在一个错误上。这一改动对安全的影响微乎其微,因为虚拟机依旧对智能体所执行的代码强制施加文件系统和网络管控。

另外,我们也把本地 MCP 服务器移到了虚拟机之外。把它们跑在虚拟机里,会让它们更难审计,会在虚拟机更新时引发脆弱的依赖问题,而且无法支持那些需要与数据库等本地进程交互的 MCP——这类服务器无论如何都得跑在宿主机上。这一改动让 Claude Cowork 与本地 MCP 服务器在 Claude Desktop 中早已采用的工作方式保持了一致:把它们当作用户可能选择安装的任何软件来对待,并信任管理员去决定启用哪些本地 MCP(如果要启用的话)。远程 MCP 服务器则不受影响,因为它们并不在用户的机器上运行。

让 agent loop 待在虚拟机内部,意味着虚拟机里的任何一次失败都会导致 Cowork 无法使用。宿主机模式更可靠,因为即便虚拟机崩溃,智能体仍能回应;而且它依然通过隔离代码执行,提供了重要的安全保证。

文件系统管控是另一个重要的架构抉择。Claude 需要能够访问宿主机上的一些文件才能发挥作用,但我们想把爆炸半径降到最低,并向用户提供有关本地文件访问的透明度。我们发现,提供不同的文件挂载模式有助于对风险做细粒度的控制;Claude Cowork 提供了三种:只读、读写,以及读写但不可删除。这里有一个潜在的坑:符号链接(symlink)的解析必须发生在路径校验之前,而非之后,否则一个位于授权文件夹内部的符号链接就可能指向外部、从而实现逃逸。对于企业客户,我们允许管理员通过 MDM 设置中的挂载路径允许清单(白名单)来控制这一点。

我们漏掉的风险:经由一个已被许可的域名外泄

一个经由已被许可的域名外泄的清晰例子,来自一份第三方披露。Claude Cowork 的出站允许清单正确地放行了发往 api.anthropic.com 的流量——这个产品没法在不调用我们自己 API 的情况下运转。在这个案例里,一个被放进用户挂载工作区里的恶意文件,夹带着一些隐藏指令,以及一个由攻击者掌控的 API key。Claude 遵照这些指令,读取了工作区里的其他文件,并用攻击者的 key 调用了 Anthropic 的 Files API。出站代理检查了目的地,看到是 api.anthropic.com,便放行了。于是这些文件被上传到了攻击者的 Anthropic 账户。沙箱运转得完美无缺,可数据还是被外泄了。

此前,我们一直把允许清单设想成一个目的地过滤器,某种告诉 Claude “这些域名可以聊” 的东西。但也许把它设想成一种”能力授予”会更好。允许清单上任何一个域名所能触达的每一个功能,如今都成了一块攻击面。允许 api.anthropic.com,就意味着允许向任意 Anthropic 账户上传文件。

我们用一个位于虚拟机内部、负责拦截发往我们 API 的流量的防御性中间人代理修复了这个问题。它只放行那些携带虚拟机自身已配发会话令牌的请求;由攻击者嵌入的 key 会被代理拒绝。它还会拦截那些可能触发服务器端抓取的请求头。这个代理之所以待在虚拟机内部、而非待在我们的服务器上,是因为只有虚拟机才知道请求的来源(provenance)——从服务器的视角看,一个 Cowork 请求与其他任何 API 客户端的请求毫无区别。

上图:发往 api.anthropic.com 的流量被放行,导致了外泄。下图:用一个中间人代理拦截发往我们 API 的流量后的修复方案。

这同样是”自己亲手造的软件往往最薄弱”这一原则的第二个例证。在我们各款产品里,虚拟机管理程序、seccomp 和 gVisor 都很可靠。出问题的那一块,正是我们自研的那个允许清单代理。

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

在评估 Claude Cowork 时,企业安全团队问道:“为什么我们的 EDR 看不到里面?”答案是:那道让 Claude 被围堵起来的隔离,同样也把基于宿主机的端点检测与响应(EDR)挡在了外面。从 EDR 的视角看,Claude Cowork 是一个不透明的虚拟机管理程序进程。它没法检视客户机内部。

隔离会降低可见性,而这种不透明性,对那些合规态势依赖于端点可见性的团队来说是个麻烦。我们当前的缓解措施是采用基于拉取的 OTLP 导出,让管理员可以在事后取回事件日志,但这与实时监控并不是一回事。如果你正在构建类似的东西,请及早把这场沟通纳入规划。

环境	临时容器(claude.ai)	人在回路沙箱(Claude Code)	封闭虚拟机(Claude Cowork)
代价:隔离开销	容器启动	低延迟的原生沙箱	完整虚拟机启动
代价:对用户的依赖	不适用	必须看懂 bash	不适用
风险:爆炸半径	服务器端容器(由 gVisor + 宿主基础设施边界守护)	本地工作区	挂载的工作区(由 vsock + 虚拟机管理程序边界守护)

信任智能体所读到的东西

企业经常问我们,该如何保护 MCP 连接的安全。这是个好问题,但真正该问的问题比”MCP”本身更宽。任何提供给智能体的外部资源,都同时代表着两重风险:一重是传统供应链意义上的代码执行风险,另一重是提示注入向量。传统的依赖审计(锁定版本、验证签名、审查源码)能应对前者,却会漏掉后者。

“远程还是本地”比看起来更重要。 一个本地安装的工具是可审计的:你能读它的代码,能锁定它的版本,并且知道它不会在你脚下悄悄变样。而一个远程工具——一个托管的 MCP 服务器、一个云端连接器——可以在你批准它之后的任何时点改变行为;你在安装时做出的信任判断,可能不再适用了。我们的连接器目录通过持续审查来应对这一点,但目录之外的任何东西都应被视为不受信任。先拿假数据去跑一跑它,放在一个恶意工具的爆炸半径已被围堵住的环境里。

即便工具本身是可信的,工具输出仍是一块攻击面。 前面提到的那个 GitHub README 例子正属于此种情况;任何施加于网页的输入扫描,都需要以同等的严格程度施加到那些联网工具的返回结果上。尽管这会增加延迟、也不是一道完美的防御,我们仍宁可偏向实时检视:一旦一个被投毒的工具返回值已经把智能体引导去外泄了数据,日志里就只会显示一次成功的、获得授权的 API 调用。事后再去找,根本没有信号可循。

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

展望未来

模型和产品都在飞速演进。随之而来的是,风险也在不断变形与进化,我们的缓解措施必须跟上节奏去应对它们。

持久化记忆投毒。 在跨会话持久存在的智能体上下文中,所占的份额在持续增长——这包括产品记忆、CLAUDE.md 文件、被挂载的工作区,以及计划任务型和长时运行型智能体的状态目录。一个落进上述任何一处的注入,都会在智能体每次启动时被重新加载。随着越来越多的智能体状态能够熬过单次会话,我们正面临经典”后渗透”意义上的新型持久化机制的威胁。在会话启动时配备优秀的分类器,将变得越来越普遍。

多智能体的信任升级。 一方面,子智能体可以隔离不受信任的内容,向上只把结构化的事实(而非原始文本)返回给主智能体。另一方面,这一点也可能被滥用:如果一个子智能体的输出仅仅因为来自”我们自己人”就被当作比原始工具结果更高的信任级别来对待,那么一条新的提示注入向量就被引入了。在多智能体系统中,分配差异化的信任级别与变得易受信任升级之害,二者之间存在一个取舍。

智能体身份。 Claude Cowork 对智能体身份的回答是具体的:凭据留在宿主机钥匙串里,虚拟机拿到一个按会话生成、权限收窄的令牌,而那个令牌可以脱离用户(凭据)被单独撤销。不过,我们也正开始面对一个更宽泛的问题:跨平台的智能体身份。一个智能体究竟应当拥有它自己的主体身份(principal identity),还是应当作为用户的延伸、继承用户的权限?说到底,答案也许是二者的某种融合。

随着智能体能力日增,攻击面在不断变化。我们已经见过的那几类失败,很可能会在各行各业、各家实验室中重演。我们需要对智能体专属的安全态势进行集体投入,从共享的基准与披露规范,到通用的身份标准与跨厂商的红队演练。本文聚焦于围堵,但那只是智能体安全图景的一部分。关于治理、可观测性以及技术栈的其余部分,可参阅 NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 牵头、CISA 与英国 NCSC 参与的六机构关于采用智能体 AI 的指南,以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中的一项贡献,但我们更期待在这一关键议题上与合作伙伴及竞争对手携手。

小结

简而言之,有几条原则是我们一再回到的:

先在环境层为围堵而设计,再在模型层去引导行为。 教会我们最多的两起事故——员工钓鱼和第三方允许清单披露——都属于出站外泄:数据经由一条被许可的路径离开了。在这两起中,模型层都帮不上忙;它没有任何异常可抓。当一切概率性的手段都失手时,被撞上的正是那道确定性的边界。

让隔离强度匹配用户的监督能力。 一个看得懂 bash 的开发者,和一个看不懂的知识工作者,跑的并不是同一套威胁模型。用户能否评估智能体即将做的事——这个问题应当帮助决定围堵策略,而在任一方向上答错——对专家施加了太多摩擦,或对非专家给予了太多信任——本身就是一种失败。

对自研组件保持警惕。 久经沙场的虚拟机管理程序、系统调用过滤器和容器运行时,所经受过的对抗性关注,比你将要造的任何东西都要多。在这里描述的每一次部署中,标准原语都稳如磐石,而我们自己围绕它们所做的那部分工作却暴露了缺陷。

归根结底,尽管智能体也许是一类新的软件,但它们在系统层面的交互并不新。它们照样要读文件、开 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、Sam Attard、Alfred Xing、Mohamad El Hajj、Gabby Curtis、David Dworken、Adam Jones、Amie Rotherham、Christian Ryan、Lucas Smedley、Brett Andrews 等人所作的贡献。

特别感谢我们的安全与产品工程团队,以及那些报告了 Claude 产品漏洞的个人与组织。

description	Anthropic 工程团队复盘 claude.ai、Claude Code、Cowork 三款产品的围堵架构与真实安全事故,提炼出"在环境层为爆炸半径封顶"的核心方法论。
tags	clippings, ai/agent, ai/安全, ai/工程实践
aliases	How we contain Claude across products, 智能体围堵与爆炸半径

AI 知识库

探索

我们如何在各款产品中围堵 Claude

三类风险,三个防御组件