十二个月前，如果有人提议授予 Claude 足以搞垮 Anthropic 某个内部服务的访问权限，我们会想都不想就拒绝。而今天，这种程度的访问权限已成为日常，Anthropic 的开发者也因此更高产了。这类部署的风险由两部分构成：故障发生的可能性有多大，以及一旦发生能造成多大破坏。安全防护与模型训练上的进步持续压低了前者；至于后者——也就是理论上的“爆炸半径”——则只会随着能力和访问权限的扩张而不断增大。然而，当智能体已经能够胜任过去需要一个人乃至一个团队才能完成的工作时，不部署的代价会变得足够高，以至于只要产品能做到足够安全，风险与回报的权衡就会明显倒向采用一侧。于是工程问题就变成了：如何为爆炸半径设上限。
当我们能够为一个自主智能体的相对破坏程度划定边界——例如通过控制它所处的环境——那些高价值的能力就能成为部署的理由。Claude Mythos Preview 就是一个例子：在 2026 年 4 月，它的爆炸半径被判定为过高、不适合发布。不过我们预计，随着防御方加固关键系统、安全防护手段日趋成熟，发布具备类似能力水平的模型将逐渐变得合适——尽管总会残留一定风险。模型能力是智能体部署整体风险中的一个重要因素。
要做到这一点，大体上有两条路。
第一条是通过人类在环（human-in-the-loop）来监督智能体的行为。Claude Code 此前防范智能体执行非预期操作的方式，是在每一步都向用户征求许可。理论上这行得通，但我们发现这套做法并不可靠。我们的遥测数据显示，用户对大约 93% 的许可提示都点了同意。一个用户看到的批准请求越多，对每一条的注意力就越少，久而久之，监督也就越来越敷衍。我们最近构建了 Claude Code auto mode，它通过自动化更安全的批准流程来缓解这种“批准疲劳”。但漏洞依然存在——任何概率性的防御都有非零的漏报率。1
第二条为爆炸半径设上限的路径——也是本文的重点——是收束（containment）。我们不去监督智能体做了什么，而是监督它能够做什么，办法是通过沙箱、虚拟机、出站流量管控等手段强制施加访问边界。这正是 Anthropic 工程团队投入精力最多的地方，也是许多最出人意料的安全失误所发生的地方。
过去两年里，我们发布了三款主要的智能体产品：claude.ai、Claude Code 和 Claude Cowork。每一款面向不同的受众，也因此需要不同的收束架构。本文将分享哪些设计经受住了考验、哪些出了问题，以及我们一路走来在智能体安全上学到的东西。
三类风险，三个防御组件
智能体面临的安全风险可归为三类之一：
用户滥用： 用户——无论是出于恶意还是粗心——指使智能体去做有害的事。这涵盖了从让智能体绕过某个他们嫌烦的检查，到运行一条自己都不理解的破坏性命令，再到蓄意指定造成危害的各种情形。
模型行为失当： 智能体执行了没有任何人要求过的有害操作。随着我们的模型不断改进，它们在大多数行为评测中变得更加对齐，但这并不意味着风险一定会缩小。能力较弱的模型更容易误读情境、犯下显而易见的错误。能力更强的模型犯错更少，但它们也更擅长找到通往目标的意外路径——往往是绕过了那些没人想到要写下来的限制。
在 Anthropic，我们见过 Claude 模型为了完成任务而“热心地”逃出沙箱、翻查 git 历史来找出一道编程测试的答案，还会自发识别出自己正在被哪个基准测试评估，进而破解它的答案密钥。每一代模型都会带来一套新的能力，而这些能力有时会以意想不到的方式被派上用场。
外部攻击者： 智能体通过工具、文件或网络访问等外部途径遭到攻击。这一类既包括提示词注入（prompt injection），也包括针对智能体运行时、编排层或代理（proxy）的传统攻击。
在构建收束与防御系统时，我们会针对三个主要组件施加防御：
智能体运行所处的环境。 我们用进程沙箱、VM、文件系统边界和出站流量管控来约束智能体能在何处、以何种方式行动。目标是为智能体能触达的范围划下一条硬边界。举例来说，如果凭据从不进入沙箱，那么无论起因是用户、是找到了“创造性”路径的模型，还是攻击者，凭据都无法被外泄。
紧致的边界也意味着你可以放松监督。Claude Code 的参考 devcontainer 之所以存在，正是为了让智能体能够无人值守地运行，无需逐个操作地征求批准。
智能体所咨询的模型。 这里的机制包括系统提示词、分类器、探针（probe）和训练层面的调整。由于模型是概率性的，这些手段只能塑造智能体倾向于做什么，而非它理论上能够做什么。
这些防御很强。在 Gray Swan 的 Agent Red Teaming 基准测试（用于检验对提示词注入的易感程度）上，Claude Opus 4.7 把单次尝试的攻击成功率压到约 0.1%，在 100 次自适应尝试后也仅约为 5–6%。Claude Code auto mode 能在大约 83% 的过度积极行为执行之前将其拦下。然而，即便配备了业界顶尖的防御，模型层的保护也永远做不到 100% 有效——这正是它无法单独成立的原因。
智能体能够触达的外部内容。 MCP 服务器、第三方插件和网页搜索工具，都会把内容从你无法掌控的来源喂进智能体的上下文。一个经过审计的连接器，并不等于经过审计的数据——比如一个 GitHub 连接器，尽管通过了恶意软件检查，仍可能把一份被投毒的 README 直接加载进模型的上下文。细粒度地限制工具权限有助于限制爆炸半径。例如，一个只拥有只读 DB 访问权限的智能体，就可以比一个能向生产环境写入的智能体部署得广泛得多。
各层防御应当彼此重叠、相互补充。当环境层的防御无法施加时，模型层就必须顶上（这正是 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 存在的时间长得多，所以审查的精力都投在了我们围绕它们新建的那些部件上。这一点我们稍后还会回头细说，因为我们的自研代理（proxy）也正是在那起后果最严重的事故中出问题的那个部件。
模式二：人类在环的沙箱（Claude Code）
Claude Code 运行在用户的机器上，能够访问其文件系统、shell 和网络。没有这些，编程智能体的用处就十分有限，因此必须想办法以安全的方式授予这种访问权限。
一种办法是依靠人类在环。这之所以对 Claude Code 来说是个可行的方案，是因为它的典型用户是开发者，对编程环境很熟悉：他们看得懂 bash，明白 rm -rf 会干什么，而且每周本来就会从不受信任的来源运行好几次 npm install。这一切意味着，当一个“允许这项操作”的对话框弹出来时，他们极有可能具备准确评估“智能体打算做什么、风险有多大”的专业能力。基于此，Claude Code 上线时采用了尽可能最简单的防御：允许读取，对写入、bash 和网络访问要求批准。
然而，如前所述，批准疲劳在几周之内就出现了。讽刺的是，这意味着一个原本为了提供监督而设计的功能，很可能起到了相反的效果——有些用户干脆就不再留意了。作为缓解草率批准的第一步，我们发布了一个 OS-级别的沙箱（macOS 上用 Seatbelt，Linux 上用 bubblewrap）来加固边界：允许读取，允许在工作区内写入，但默认拒绝网络访问。在沙箱内，智能体基本可以不受打断地运行。结果是许可提示减少了 84%，而且我们开源了这套运行时，因此这条边界是可审计的。
我们的匿名使用数据还显示，有经验的用户自动批准的频率大约是新用户的两倍，但他们也更频繁地在执行过程中打断智能体。比起逐步设卡，有经验的用户更倾向于只在智能体跑偏时才介入监督。这或许是人们与智能体协作方式的一种自然演进，但它同样并不可靠：它要求用户在技术上足够内行、注意力足够集中，才能在一开始就察觉到偏离。随着模型能力的提升、智能体开始编写越来越有野心的 bash，要察觉到这种偏离会变得愈发困难。而当用户转向多智能体系统时，这套办法也远不太可能成为一种有效的监督策略。
我们漏掉的风险：信任对话框之前的一切
在 2025 年年中到 2026 年 1 月之间，我们通过负责任披露计划收到了若干 Claude Code 漏洞报告。其中三个利用的是在用户同意任何事情之前就已执行的代码。要理解这怎么可能发生，不妨看一个最直接的例子：一名开发者克隆了一个仓库来评审一个拉取请求（pull request），而该仓库里包含一个 .claude/settings.json，其中定义了一个 hook。由于 Claude Code 在启动期间——也就是在弹出标准的“你信任这个文件夹吗？”提示之前——就会读取项目设置，攻击者所编写并提交的那个 hook 就会被自动执行。其余几个案例在结构上看起来很相似：来自尚未受信任目录的输入，在信任边界建立起来之前就被解析了。
每个案例的修复方法形状都一样：把项目本地配置的解析与执行推迟到用户接受信任提示之后再进行。如果你正在构建类似的东西，请把“打开项目”“加载配置”以及监听 localhost 这几件事，当作来自互联网的任何入站请求一样对待。它们不该仅仅因为感觉上很“本地”、又赶在用户同意之前到达，就被隐式地信任。
我们漏掉的风险：用户本身就是注入途径
2026 年 2 月，在一次受控的内部红队演练中，一名研究员成功钓鱼诱使一名员工带着一段恶意提示词启动了 Claude Code。这次钓鱼看上去就像寻常的协作——一封“能帮我跑一下这个吗？”的邮件，附上一段可以直接粘贴的提示词，而提示词本身读起来也像例行的任务说明。但在那些准备步骤之间的某处，它温和地让 Claude 去读取 ~/.aws/credentials，把内容编码，再 POST 到一个外部端点。在对该提示词的 25 次重试中，Claude 有 24 次完成了数据外泄。
这是一种直接的提示词注入——攻击者的指令是经由用户、而非经由工具输出或抓取到的内容送达的。我们的模型层防御锚定在用户意图之上——当输入指令的人正是用户本人时，分类器没有任何反常之处可供捕捉。换作一个被递了同一份脚本的人类承包商，也会做出同样的事。
在这种情形下唯一能站得住脚的防御，就是环境层——具体而言，就是无论意图如何都拦下那个 POST 的出站流量管控，以及一开始就让 ~/.aws 处于够不着位置的文件系统边界。
（当我们把这段能跑通的提示词发到内部 Slack 上供大家讨论时，有人指出，有些内部智能体会读取 Slack。于是这段载荷就变得无处不在了。我们往那个会话线程里加了一个金丝雀字符串（canary string），以便一旦有什么东西把它读了进去，我们能察觉到。在一个智能体什么都读的世界里，连调查工具本身也成了攻击面。）
模式三：本地 VM（Claude Cowork）
Claude Cowork 运行在用户的桌面上，能够访问一个由用户选定的工作区文件夹。由于该平台是为通用的知识工作、而非软件工程打造的，它的典型用户精通 bash 的可能性要小得多。
因此，人类在环的沙箱策略未必能照搬过来；不应指望一名非技术背景的知识工作者去判断诸如 find . -name “*.tmp” -exec rm {} \; 这样的 bash 咒语。当批准一项例外所需的专业能力是典型用户并不具备的时候，管理员就应当设下一条绝对、始终生效的边界。
为实现这一点，我们第一版的 Claude Cowork 运行在一个完整的虚拟机里，使用各平台厂商提供的 hypervisor（macOS 上是 Apple 的 Virtualization 框架，Windows 上是 HCS）。这个 VM 拥有自己的 Linux 内核、自己的文件系统、自己的进程表。用户选定的工作区和 .claude 文件夹会被挂载进来；宿主机上的其他任何东西都不可见。凭据留在宿主机的钥匙串里，从不进入客户机。这套设计是为了防范 Claude 在某个时刻表现出不对齐行为的可能性。一个被攻陷的 Claude 仍然可能破坏工作区文件夹里的东西，因此架构的设计意图是确保那就是它唯一能触达的地方（直到用户添加连接器为止），并且由用户来掌控挂载进去的是什么。
在最初的架构里——我们称之为全 VM 模式（full-VM mode）——智能体循环本身就跑在客户机内部，因此 Claude 是作为一个普通的 Linux 用户来执行的，毫不知道自己被沙箱关着。把这与 Claude Code 对照一下：在 Claude Code 里，有一个特权进程坐在沙箱之外，逐条命令地决定是否对其强制执行约束；一段有说服力的注入提示词，或者一次因疲劳而点下的批准，都可能让那个进程去运行某些未受沙箱约束的东西。而在这里，没有任何外层进程握着逃生舱的钥匙，因此也就没有任何组件有权授予例外。
Claude Cowork 的 VM 所采用的六种主要隔离机制。其中两种在客户机内核之外强制实施，因此即便智能体在 VM 内部取得了 root 级访问权限，它们也能存续。另外四种由客户机内强制实施，且被刻意保持得极为精简，因为外层已经扛起了其余的担子。
然而，我们很快意识到，让整个智能体都跑在全 VM 模式下会带来一些现实问题：VM 启动期间的任何失败都会让 Cowork 不可用。把智能体循环移到 VM 外部、同时把代码执行保留在 VM 内部，就让 Claude 在遇到错误时仍能响应用户、帮忙排查问题，而不是僵在那里。这一改动对安全性的影响微乎其微，因为 VM 依然对智能体所执行的代码强制施加文件系统与网络管控。
另外，我们也把本地 MCP 服务器移到了 VM 外部。把它们跑在 VM 内部会更难审计，在 VM 更新时会带来脆弱的依赖问题，而且无法支持那些需要与本地进程（比如数据库）交互的 MCP——这类服务器无论如何都得在宿主机上运行。这一改动让 Claude Cowork 与本地 MCP 服务器在 Claude Desktop 中本就采用的工作方式保持一致：把它们当作用户可能选择安装的任何软件来对待，并信任管理员去决定启用哪些本地 MCP（如果要启用的话）。远程 MCP 服务器不受影响，因为它们并不在用户的机器上运行。
让智能体循环跑在 VM 内部，意味着 VM 中的任何失败都会导致 Cowork 不可用。宿主模式（host-mode）更可靠，因为即便 VM 崩溃，智能体仍能响应；同时它通过隔离代码执行，依然提供了重要的安全保证。
文件系统管控是另一项重要的架构选择。Claude 需要能访问宿主机上的一部分文件才能发挥作用，但我们希望把爆炸半径压到最小，并就本地文件访问向用户提供透明度。我们发现，提供不同的文件挂载模式有助于细粒度地控制风险；Claude Cowork 提供只读（read-only）、读写（read-write）和读写但不可删除（read-write-no-delete）三种模式。这里有一个潜在的坑：符号链接（symlink）的解析必须发生在路径校验之前、而不是之后，否则一个位于已授权文件夹内的符号链接就可能指向外部、从而逃逸出去。对于企业客户，我们允许管理员通过 MDM 设置里的挂载路径允许列表来对此加以控制。
我们漏掉的风险：经由已批准域名的外泄
一个经由已批准域名进行外泄的清晰例子，来自一份第三方披露。Claude Cowork 的出站流量允许列表正确地放行了去往 api.anthropic.com 的流量——产品离开了对我们自己 API 的调用就无法运转。在这个案例中，一个被放进用户所挂载工作区里的恶意文件，携带了隐藏指令以及一个由攻击者掌控的 API 密钥。Claude 依照指令读取了工作区里的其他文件，并使用攻击者的密钥调用了 Anthropic 的 Files API。出站代理检查了目的地，看到是 api.anthropic.com，便予以放行。这些文件就被上传到了攻击者的 Anthropic 账户里。沙箱运转得完美无缺，数据却照样被外泄了。
此前，我们一直把允许列表设想成一个目的地过滤器，一个告诉 Claude “这些域名可以与之通信” 的东西。但更恰当的设想，或许是把它看作一种能力授予。允许列表上任何一个域名所能触达的每一个功能，如今都成了一个攻击面。允许 api.anthropic.com，就意味着允许向任意 Anthropic 账户上传文件。
我们用一个位于 VM 内部、专门拦截去往我们 API 流量的防御性中间人代理（man-in-the-middle proxy）修复了它。它只放行携带 VM 自身预置会话令牌的请求；一个由攻击者嵌入的密钥会被这个代理拒绝。它还会拦截那些可能触发服务端抓取（server-side fetch）的请求头。这个代理坐落在 VM 内部、而非我们的服务器上，是因为只有 VM 才知道请求的来源——从服务器的视角看，一个 Cowork 请求与任何其他 API 客户端发来的请求毫无区别。
上图：去往 api.anthropic.com 的流量被放行，导致数据外泄。下图：通过一个拦截去往我们 API 流量的中间人代理来修复。
这也是“你自己亲手搭建的软件往往是最薄弱的一环”这条原则的第二个实例。我们各款产品中的 hypervisor、seccomp 和 gVisor 都一直很可靠。出问题的，是我们那个自研的允许列表代理。
我们漏掉的风险：VM 隔离把端点检测软件也挡在了外面
在评估 Claude Cowork 时，企业安全团队问：“为什么我们的 EDR 看不到里面？”答案是，那套把 Claude 关住的隔离，同样把基于宿主机的端点检测与响应（EDR）挡在了外面。从 EDR 的视角看，Claude Cowork 是一个不透明的 hypervisor 进程。它无法窥探客户机内部。
隔离会降低可见性，而这种不透明，对于那些合规姿态依赖端点可见性的团队来说是个问题。我们目前的缓解办法，是使用基于拉取（pull-based）的 OTLP 导出，让管理员能够事后取回事件日志，但这与实时监控并不是一回事。如果你正在构建类似的东西，请尽早为这场对话留出预算。
| 成本：隔离开销 | 容器启动 | 低延迟的原生沙箱 | 完整 VM 启动 |
| 成本：对用户的依赖 | 不适用 | 必须看懂 bash | 不适用 |
| 风险：爆炸半径 | 服务端容器（由 gVisor + 宿主基础设施边界守护） | 本地工作区 | 挂载的工作区（由 vsock + hypervisor 边界守护） |
信任智能体所读取的内容
企业常常问我们如何保障 MCP 连接的安全。这是个好问题，但真正该问的，比单单 MCP 要宽泛得多。提供给智能体的任何外部资源，都同时代表着两种风险：传统供应链意义上的代码执行风险，以及提示词注入途径。传统的依赖审计（锁定版本、验证签名、评审源码）能应对前者，却漏掉了后者。
“远程还是本地”比看上去更重要。 一个本地安装的工具是可审计的。你可以读它的代码、锁定它的版本，并知道它不会在你脚下悄悄变样。而一个远程工具——一个托管的 MCP 服务器、一个云端连接器——在你批准它之后的任何时点都可能改变行为；你在安装时做出的信任决策，可能已经不再适用了。我们的连接器目录通过持续的评审来应对这一点，但目录之外的任何东西都应当被视作不受信任。先拿假数据去跑一遍它，在一个恶意工具的爆炸半径已被收束住的环境里。
即便工具是受信任的，工具输出也仍是一个攻击面。 前面提到的那个 GitHub README 的例子正是这种情况；任何应用于网页的输入扫描，都需要以同等的严格程度应用到具备联网能力的工具结果上。尽管这会增加延迟、也并非完美的防御，我们仍倾向于做实时检查：一旦一个被投毒的工具返回值把智能体引去外泄数据，日志里就只会显示一次成功的、获得授权的 API 调用。没有任何事后的信号可供查找。
在 Claude Code 和 Claude Cowork 里，工具调用都会经由代理来路由，这些代理强制施加网络与文件策略，并且能在返回值进入模型上下文之前对其加以检查。负责检查的那个分类器可以是一个小而快的模型；它不必是那个负责推理的模型。
展望未来
模型与产品正在飞速演进。随之而来，风险也在变形、进化，而我们的缓解手段必须同步跟上以应对它们。
持久化记忆投毒。 在跨会话持久存在的那部分智能体上下文中，其占比仍在不断增长——这包括产品记忆、CLAUDE.md 文件、被挂载的工作区，以及定时任务和长时运行智能体的状态目录。一个落入其中任何一处的注入，都会在智能体每次启动时被重新加载。随着越来越多的智能体状态在会话结束后存续下来，我们正面临传统“后渗透（post-exploitation）”意义上的新型持久化机制的威胁。在会话启动时部署好的分类器，将需要变得更加普遍。
多智能体信任升级。 一方面，子智能体（sub-agent）可以隔离不受信任的内容，向主智能体返回结构化的事实而非原始文本。另一方面，这也可能被滥用：如果一个子智能体的输出仅仅因为它来自“我们自己”，就被当作比原始工具结果更可信，那么一种新的提示词注入途径就被引入了。在多智能体系统里，“分配不同的信任级别”与“变得易受信任升级攻击”之间，存在一个权衡。
智能体身份。 Claude Cowork 对智能体身份的回答是具体的：凭据留在宿主机的钥匙串里，VM 拿到一个按会话授予、权限被收窄的令牌，而这个令牌可以独立于用户的令牌被吊销。不过，我们也开始着手应对一个更宽泛的问题：跨平台的智能体身份。一个智能体究竟应当拥有它自己的主体身份（principal identity），还是应当作为用户的延伸、继承用户的权限？归根结底，答案或许是两者的某种融合。
随着智能体能力日益增强，攻击面也在不断变化。我们所见过的那些失败类型，很可能会在各行业和各实验室之间反复上演。我们需要在智能体专属的安全姿态上进行集体投入——从共享的基准测试和披露规范，到通用的身份标准与跨厂商的红队演练。本文聚焦于收束，但那只是智能体安全图景中的一部分。关于治理、可观测性以及技术栈的其余部分，可参阅 NIST 关于 AI 智能体身份与授权的项目、由澳大利亚 ACSC 联合 CISA 与英国（UK）NCSC 牵头的关于采用智能体 AI 的六机构指南，以及 AI 管理标准 ISO/IEC 42001。我们的 Glasswing 计划是其中一项贡献，但我们也期待与合作伙伴和竞争对手一道，共同应对这一关键议题。
小结
简而言之，有几条原则是我们反复回到的：
先在环境层为收束而设计，再在模型层去引导行为。 教会我们最多的两起事故——员工钓鱼，以及那份第三方允许列表披露——都属于外泄（egress）的情形：数据是经由一条被许可的路径离开的。在这两起事故里，模型层都帮不上忙；它没有任何反常之处可供捕捉。当一切概率性的手段都没拦住时，被撞上的，正是那条确定性的边界。
让隔离强度与用户的监督能力相匹配。 一个看得懂 bash 的开发者，和一个看不懂 bash 的知识工作者，并不处在同一套威胁模型之下。“用户能否评估智能体即将做的事”这个问题，应当帮助决定收束策略；而在任一方向上答错——对专家施加了过多摩擦，或对非专家给予了过多信任——本身就是一种失败。
对自研组件保持警惕。 经过实战检验的 hypervisor、系统调用过滤器和容器运行时，所经受过的对抗性关注，比你将要构建的任何东西都多。在这里描述的每一次部署中，标准原语都顶住了，而我们围绕它们所做的工作却暴露出了缺陷。
归根结底，智能体或许是一类新软件，但它们在系统层面的交互并不新。它们仍然要读取文件、打开套接字、派生进程；这就使得“用成熟工具来做收束”成为一种至关重要且切实可行的防御。随着 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 产品漏洞的个人和组织。
脚注
- Claude Code auto mode 把命令批准委托给一个基于模型的分类器；它把摩擦降到最低（约 0.4% 的良性命令被拦），代价是漏掉一小部分有风险的命令（约 17% 的过度积极操作会被放行），因此它是沙箱内纵深防御的一层，而非沙箱的替代品。