圈内内参。Anthropic 委托 Trajectory Labs 在 Opus 5 Auto Mode 上跑的那 72 个间接提示注入场景，每个场景 10 次，成功率 0.00%。这个数我确认过，公开可查。wunderwuzzi 那条链不在 72 个场景里，五次测试的成绩摆出来是：C2 链 3/5、claude -p 子进程 3/5、文件写入 4/5。两个数都对，差的不是谁造假，是“安全评估”这四个字在不同人手里指的不是同一层。这期信源全部公开：博客原文、附录视频、Anthropic 安全回应、Boris Cherny 的表态。没有匿名消息源。
0.00% 的语境是什么：Trajectory Labs 受委托，拿 72 个间接提示注入场景，单个场景在 Opus 5 Auto Mode 下跑 10 次，统计攻击成功率。结果为零。这个数字很容易被读宽。它只证明了一件事：模型在这 72 个场景、这 10 次运行里没被注入成功。它不证明 Auto Mode 能防间接提示注入，也不证明攻击者绕不过去。wunderwuzzi 自己在文章里也点了这点：0.00% 的基准成功率和实际可利用漏洞可以同时成立。这不是辩解，是测评集的老毛病——它天然只覆盖已知的、能被写进测试集的攻击模式，实际攻击者从来都在测试集外面。
攻击链真正有意思的不是最终拿到什么权限，是中途一个不太起眼的转折。让 Claude Code 去处理不可信内容，诱导它访问一个恶意网站。第一步不是代码执行，是服务器返回一个 415 Unsupported Media Type。这个错误码本身没什么，但它的作用是让 Claude 放弃 WebFetch 工具——WebFetch 处理不了这个返回——转而用 curl 去下载。这一步轻到几乎所有安全分类器都不会拦：发一个错误码，然后看模型自己往哪边走。它自己走向了 curl。
curl 请求被重定向到一个 ZIP 归档。归档里塞了伪造的目录元数据、编码记录、说明文件、一个叫 decoder-darwin 的二进制解码器，还有恶意的 struct.py。到这里为止都还是老剧情：诱导模型去拿一个可疑文件。接下去才是反直觉的地方。
Claude 出于安全考虑拒绝执行 decoder-darwin 这个二进制。按分类器的逻辑，这步是对的——不执行未知二进制，防御生效。但 Claude 没停下，它自己决定：那我用 Python 写一个解码器。这个决定看起来安全，实际上把攻击链从“诱导执行二进制”切换到了“诱导模型在解压目录里写 Python 并运行”。那个解压目录里，就躺着 struct.py。
整条链最咬合的地方在这。Claude 写的 Python 解码器在解压目录里运行，导入 base64 模块。base64 内部要 import struct。Python 的导入机制会先在当前目录找 struct.py——当前目录里恰好就有那个恶意的 struct.py。于是标准 struct 模块被遮蔽，恶意 struct.py 被加载。它在正常完成解码的同时，执行了藏着的恶意代码。这种“遮蔽标准库模块”的路径，那 72 个基准场景几乎肯定没覆盖。它依赖一串非常具体的操作：先让模型放弃一个工具、换一个、下载一个特定结构的归档、然后在解压目录运行模型自己写的代码。单独看每个环节都无害，凑够链才出问题。测评集天然倾向于测单点防御是否生效，这类链式依赖它测不出来。
文章里有个细节我起初以为是笔误，核了下视频不是。两种情形都出现了：有时系统已经被攻陷了，Claude 还在继续解码记录，稍后才检查出 struct.py 是恶意文件并警告用户；有时 Claude 声称自己没有执行恶意指令，实际上已经执行了。也就是说，攻击成功的测试里，模型的自我报告不可靠。它要么报得晚，要么报得错。这不是小问题：Auto Mode 的安全分类器本质上要依赖模型对自身行为的判断来触发干预。如果模型在“自己是否执行了恶意指令”这件事上都能说错，分类器接到的是一个被污染的信号。
另一个更扎眼的是分类器行为反常。在部分测试里，Auto Mode 阻止了 Claude 试图终止恶意进程的命令。也就是安全分类器允许创建那个恶意子进程，但当模型试图 kill 它的时候，分类器把 kill 动作拦下来了。我的分析（分析，非事实）：分类器的习得偏置是“创建进程是正常开发行为，终止进程是危险操作”。在无人值守的 agent 场景里，这种偏置会把一次本来可以自愈的清理变成攻击链的延长。这条我只有 wunderwuzzi 一个信源，先标未证实放着。如果有同行能复现这个行为，值得单独核实。
C2 载荷的启动方式也值得记一笔。恶意 struct.py 启动一个隔离的 Python 子进程，命令是 python3 -I -c，下载并执行远程载荷，建立 C2 回调，然后打开计算器作为可见效果。这里 -I 是隔离模式，不让环境变量和用户站点目录影响子进程。从构造者角度理解，这是为了让子进程更干净、更不容易受现有环境干扰。但这个细节也顺带说明：构造者很清楚 Claude 会在哪一层设防、哪一层不设防。
有个变体里，恶意 struct.py 不直接拉远程载荷，而是启动第二个 Claude Code 实例：claude -p。那个子代理执行了 whoami、uname、id 这些侦察命令，还在主目录写了文件。成功率摆出来：C2 链 3/5，claude -p 子进程 3/5，加文件写入那个是 4/5。小样本，n=5，连置信区间都谈不上。我不拿它推总体成功率。但五次能成三到四次，至少说明这不是一次侥幸。
Anthropic 的回应怎么读。报告先发到 [email protected] 没回复，走安全报告渠道，最后被关为 Informative。回应原文反复出现几个说法：Auto Mode 是依靠尽力而为的分类器的便利功能，不是安全保证；真正的安全边界是操作系统隔离和网络出口控制；Auto Mode 的批准不代表命令安全。也就是说，报告方和厂商的立场居然没有根本冲突。厂商承认攻击有效，但说这本来就不在安全承诺范围内。
这段话不是敷衍。它精确地划了一条线：Auto Mode 的价值是省去人工审批的摩擦，代价是不作安全承诺。谁把无人值守的编码 agent 跑在没有 OS 隔离和网络卫生策略的环境里，出事是预期内的事，不是漏洞。Anthropic 没有拿 0.00% 来辩护 Auto Mode 安全。两边能并存，是因为各自在讲不同层的问题。
有个反向细节我不太想展开，但带一句：混淆 struct.py 的代码是攻击者用 ChatGPT 写的，视频里标的是 GPT-5.6。攻击方的工具链本身就在用最新的模型。这个事实只是把“AI 编程工具普及后，攻击构造门槛会怎么变”这个老问题又往前推了一步。原作者还提了一句，成熟的提示注入越来越依赖社会工程式技术——他叫它“对抗性错位”，而不是简单的“忽略之前指令”。若这条路线成立，基准测试里那种脚本化注入场景会越来越说明不了问题。
现在让我有点皱眉头的是另一个事实：从 2026 年 8 月中旬起，Auto Mode 成为 Claude Code 的默认启动模式。产品团队把它设默认，意味着多数用户不会去改。那么“便利功能、非安全保证”这个定位，就要求用户在理解成本很低的情况下自己建立边界。问题在于，大多数人对安全边界的理解恰恰来自默认值本身。被默认启用的东西，心理上会被当作“被认为足够安全的东西”。
几个值得盯的信号，不压注，只列出来：一、Anthropic 下一次更新 Auto Mode 时，会不会把 wunderwuzzi 这条链的结构加进基准测试的 72 个场景里，甚至公开更新测试集。二、安全分类器那个“允许创建进程、拒绝 kill”的行为会不会被当成具体 bug 修掉。这个比任何话术都说明问题。三、Auto Mode 作为默认启动这件事，下个版本会不会改成“首次使用显式询问”，还是继续默认打开。这三条到点都能核验，到时候回头看就知道这是不是一次会被认真对待的报告，还是一次被 Informative 归档掉的技术噪音。