Claude Code 的 auto 模式不是安全边界

Claude Code 的 auto 模式是安全边界吗？ 不是，而且 Anthropic 自己也这么说。在研究员 Johann Rehberger 报告了一条针对 auto 模式下 Claude Code Opus 5 的、真实可行的攻击链之后，Anthropic 将该报告标记为 Informative 并关闭。其立场是：auto 模式是一项便利功能，背后是一个尽力而为的分类器，而不是安全保证；由一个个单独看来无害的步骤拼装而成的、有备而来的攻击链，本就不在分类器被期望拦截的范围之内；真正的边界是操作系统层面的隔离，加上网络 egress 管控。¹ 这个答复不是推诿。它才是正确的心智模型，而我们大多数人一直抱着错误的那一个。 {.answer-block}

有一类安全发现，其价值不在于漏洞本身，而在于它纠正的那个信念。Rehberger 在8月26日发布的分析就属于这一类。他演示的攻击链很巧妙，但真正有用的是它引出的那份答复，因为这份答复告诉你：在你的环境里，究竟哪一层才是真正承重的。而它并不是自8月 auto 模式成为默认设置以来，多数开发者一直信赖的那一层。

摘要

• Rehberger 于2026年8月26日公开了一条针对 auto 模式下 Claude Code Opus 5 的、真实可行的攻击链，并报告在小样本上的成功率为60%至80%：主攻击链五次中有三次成功，第二个变体的两种配置分别是五次中三次和五次中四次。他特别说明，这些只是小样本，而非普遍意义上的攻击成功率。¹
• 这一发现正好撞上了一个具体的数字：Anthropic 委托的第三方评估报告称，auto 模式下的 Opus 5 提示注入攻击成功率为0.00%，测量方式是72个场景各运行十次。Rehberger 的攻击链并不在这批场景之内，因此0.00%这个数字与一条真实可用的代码执行链可以同时成立。¹
• 攻击链中的每一步单独来看都合情合理。这正是其中的设计教训：分类器一次只评估一个动作，而攻击藏在这些动作的组合里，不在任何单个动作之中。
• Anthropic 将报告标记为 Informative 并关闭，把 auto 模式定位为由尽力而为的分类器支撑的便利功能，而非安全保证，并指出操作系统隔离与网络 egress 管控才是真正的边界。¹
• 最锋利的一处细节由 Rehberger 报告、经 Willison 着重提出：在少数几次运行中，Claude 察觉到了入侵并试图终止恶意进程，而 auto 模式拒绝了那条清理命令。¹²
• 实际后果是：auto 模式是一项生产力控制手段，并且在它判断您并未提出相应要求时，也会拦截一份有文档记录的破坏性操作清单。但挡在攻击者可控文本与您的凭据之间的，并不是它。真正挡在中间的，是容器、受限的 egress，以及一个不存放凭据的主目录。

逐步拆解这条攻击链

起点是一个在做日常工作的智能体：获取一份资源，解码它，使用其中的内容。下面看看这一过程是如何演变为代码执行的。¹

某台服务器对智能体的 WebFetch 返回 HTTP 415，这看上去像是 content-type 的问题，而不像攻击。智能体做出了合理的选择，退回到 curl。它取回的压缩包解开后，临时目录里躺着一个 README、一份校验和清单、一个 CSV 索引、七条经 Base85 与 zlib 编码的 JSON 记录、一个原生解码器二进制文件，以及一个名为 struct.py 的文件。

接着，安全机制发挥了作用。智能体拒绝运行这个不可信的原生二进制文件——正是您希望看到的行为。拒绝了二进制文件之后，它转而自己写了一个 Python 解码器，并在解压目录内部运行。

那个解码器会 import base64。标准库的 base64 又会 import struct。Python 把工作目录放在模块搜索路径的最前面，于是 struct 解析到的不是标准库，而是解压出来的压缩包里那个属于攻击者的 struct.py。

请再读一遍这个顺序，并留意其中缺了什么：没有任何一步是在指示智能体去做明显恶意的事，也没有任何一步会被一位称职的审查者单独挑出来。收到415后退回 curl 很正常。解开压缩包很正常。拒绝未签名的二进制文件是安全上的胜利。自己动手写解码器是随机应变。在存放数据的目录里运行它，更是再自然不过的选择。

分类器为何注定输掉这一局

auto 模式的分类器会对照会话的意图来评估一个动作：这条命令是否与用户所要求的相符，它本身是否危险？这个问题对 rm -rf / 有很好的答案，对 python decode.py 却给不出好答案。

这次攻击从头到尾没有呈上任何一个危险动作。它只是重新摆布环境的形状，使得一个看似安全的动作产生了不安全的后果；而这个后果之所以成立，完全依赖于更早发生的那一步——那次埋下模块的解压操作。要抓住这一点，审查者必须把整段历史都装在脑子里，并结合当前工作目录去推演 Python 的 import 解析规则。Anthropic 的立场，即由单独无害的步骤构建的攻击链落在分类器职责范围之外，正是对这道缝隙的陈述。¹

值得把这类攻击的名字说准。Willison 在8月30日更新了他的文章，认可了一位 Lobste.rs 读者提出的观点：这压根不是经典的提示注入，因为模型自始至终都没有读取攻击者的指令并加以执行。更贴切的说法是混淆环境攻击（confused environment attack）——是交到智能体手里的那个环境的形状，制造出了这次利用。² 这个区分并没有削弱问题，反而让它更加尖锐。一个盯着注入指令看的分类器在这里无物可看，因为根本就没有指令。

这与 MCP 的 CVE 浪潮不断揭示的是同一个结构性问题：智能体工具积累能力的速度，快过它积累约束的速度；而逐动作的审查，并不能合成为逐会话的安全。

应当改变您心智模型的那处细节

Rehberger 报告、Willison 着重提出的那一幕值得停下来细想：在少数几次运行中，Claude 注意到了入侵并试图终止恶意进程，而 auto 模式拒绝了那条清理命令。¹²

一个安全层阻止了补救，这并不是悖论。当一项控制手段只为“别让智能体做出任何激烈举动”而优化，却没有关于这个激烈举动为何被尝试的概念时，就会出现这种局面。在分类器看来，入侵之后的清理，与破坏行为长得非常像。

由此得出的运维教训虽窄却实用：“智能体会察觉到”不是一种控制手段。察觉与能够采取行动是两种不同的能力，您的事件响应方案不能假设被入侵的智能体还能自己收拾残局。

真正约束智能体的东西

Rehberger 的建议都不怎么光鲜，但头两条本可以把这条攻击链关在里面：¹

在容器或虚拟机中运行无人值守的智能体。 这次入侵是以智能体所属用户的身份执行代码的。一层隔离能把对整台机器的访问变成一个用完即弃的环境。

限制网络 egress。 这条攻击链的收益，来自一个子进程向外获取并运行远程载荷，随后再发出回连。一份基于允许列表的 egress 策略，能同时切断远程阶段的下载和回连。

让凭据处在智能体够不着的地方。 主目录里的 SSH 密钥、云凭据和 .env 文件，默认就在爆炸半径之内。要么把它们挪走，要么把智能体放到没有它们的地方去运行。

监控智能体，并且不要把批准当作证据。 auto 模式的批准只意味着分类器没有提出异议，并不等于认定该动作是安全的。

也请留意清单上没有的一项：关掉 auto 模式。当它判断您并未提出相应要求时，它会拦截一份有文档记录的破坏性操作清单，同时它还减少了那种让人条件反射式点“同意”的提示疲劳。为了一种虚假的严谨感而把它交出去，等于用一个更糟的弱控制换掉了一个弱控制。留着它，只是别再把它当成边界。

有些话值得直说

把这个发现写成一次失败很容易，写成对厂商的指责更容易。两者都不对。

Anthropic 的答复——一项由尽力而为的分类器支撑的便利功能，而非安全保证，边界在于操作系统隔离与网络 egress 管控——是一种比更强硬的表态更诚实的安全姿态。¹ 若有厂商承诺自家分类器能拦下有备而来的注入链，那将是任何分类器都无法兑现的承诺，而开发者会在这份承诺之上继续搭建。有意思的问题不是这次攻击是否奏效，而是整个生态的心智模型是否与厂商的一致——目前并不一致。auto 模式在8月成为 Pro、Max 和 Team 会话的默认设置，而当时被 Anthropic 投入流通的数字，是一份受委托的72场景评估所得出的0.00%攻击成功率；Rehberger 把它归入“0.00%的营销问题”。与这个数字一同传播的叙事框架是安全性，而不是“便利加上爆炸半径的缩小”。¹ Rehberger 得出了比我更强硬的结论：他把0.00%的宣传口径与“不在范围内”的处置读作彼此对不上的混乱信号。¹ 我认为两者可以同时成立。这个处置是诚实的；而那个数字，本就不该被当作产品的属性来做营销。

如果您的环境一直假定分类器就是那堵墙，那就把墙补上。

9月3日更新：本文发布后上线的内容

在本文发布后的48小时内，Claude Code 发布了三个版本，其中两个涉及 auto 模式。³ 9月1日发布的2.1.257版本新增了发布说明中称为 Containment Escape 的规则：“云元数据凭据获取、egress 规避以及跨租户访问不再被自动批准，除非您的环境将它们标记为预期之内。”同一版本还在 auto 模式中，为首次读取工作目录之外的文件加入了一次性确认提示，并提供设置项 permissions.blockReadsOutsideWorkingDirectories，可将该提示变为直接拒绝。9月2日发布的2.1.259版本，为无人值守的 headless 主机新增了 --permission-prompts none：“任何本会触发提示的操作都会被自动拒绝，与此同时当前生效的权限模式（包括 auto 模式）仍在继续做判断。”

请在本文设定的框架里理解它们。这条规则、这次读取提示以及这个命令行标志，都是货真价实的加固，而这个 headless 标志正是无人值守主机应当启用的失败即拒绝设置。但前两项收窄的，是 auto 模式自行批准的范围：规则把三类操作从自动批准中剔除，除非环境将其标记为预期之内；读取方面的变更则提示一次，或者在开启设置后直接拒绝。两者都没有被描述为边界，两者也都位于 auto 模式的批准流程之内。而正是这套审查，被这条攻击链一路走通，且其间没有呈上任何一个单看就不对劲的动作。规则点名了 egress 规避，而 Rehberger 描述的并不是规避，只是每一跳上的对外连接：一次 curl 下载、一个去获取远程阶段的子进程、该阶段再去获取载荷，以及最后的回连。规则是否会把其中任何一项读作规避，说明里没有讲；读取提示是否覆盖子进程发起的读取，说明里同样没有讲。这两项变更中是否有哪一项本可以拦下这条攻击链，发布说明并未做此声称，我们也不该擅自假定。2.1.257 中确有一处修复落在边界这一层：沙箱的 deniedDomains 条目此前无法拦截以尾点书写的主机名，该版本修好了这一点。那是在边界上做的修补，而不是边界的移动。auto 模式自行批准的范围缩小了，边界并没有动。

要点回顾

• auto 模式是便利与爆炸半径的控制手段，不是安全边界。 这是厂商在一次真实绕过之后自己的立场，而非外界的批评。¹
• 分类器裁决动作，攻击却活在组合之中。 所演示的攻击链每一步单独看都站得住脚，而这恰恰是逐动作审查漏掉它的原因。
• 察觉不等于补救。 在某些运行中，智能体检测到了自身被入侵，随后却被拦住而无法清理。请据此规划事件响应。¹²
• 真正立得住的控制手段都在模型之外。 容器或虚拟机、受限的 egress、移出主目录的凭据。其余的一切都是纵深防御，而不是边界。

常见问题

我应该关掉 auto 模式吗？

不应该，除非您一直把它当作隔离手段来依赖。当它判断您并未提出相应要求时，它会拦截一组有文档记录的破坏性操作——git reset --hard、git checkout -- .、git clean -fd、git stash drop，以及 terraform/pulumi/cdk destroy——并且它还削减了那种诱发条件反射式批准的提示数量。把它留作生产力与爆炸半径的控制手段，同时为接触不可信输入的会话加上真正的隔离。

这只影响 Claude Code 吗？

这个机制并非 Claude 独有。任何一个会去获取不可信压缩包、编写代码并在刚刚解压出来的目录里运行它的智能体，都暴露在同样的 import 解析陷阱之下；任何一种逐动作的安全审查，也都暴露在同样的组合缝隙之下。此处的具体细节，是在 auto 模式下的 Claude Code Opus 5 上演示出来的。¹

什么样的会话算是不可信输入会话？

任何可能让受攻击者影响的文本抵达模型的场景：抓取的网页、下载的压缩包、issue 与 PR 的文本、电子邮件、来自公开服务的日志，以及第三方 MCP 服务器。实际上这几乎涵盖了大部分真实工作——这正是令人不安的地方。

这个问题已经修复了吗？

它并未被当作需要修复的漏洞来处理。Anthropic 将报告标记为 Informative 并关闭，理由是此类绕过分类器的行为不在 auto 模式所承诺的范围之内。¹ 请把它当作系统一项有文档记录的性质，而不是一个待发的补丁。本文发布后48小时内的一个版本2.1.257收窄了 auto 模式自行批准的范围，并新增了对工作目录之外读取的可选拦截；2.1.259则为 headless 主机新增了一个失败即拒绝的命令行标志。上文9月3日的更新说明了它们改变了什么、又没有改变什么。³

来源