导语：2026年8月，一篇116页的论文揭露了今年最严重的AI安全漏洞：Anthropic、OpenAI、Google三大厂商的加密思维链（Chain-of-Thought）推理块可跨会话、跨账户、跨模型自由移植。攻击者只需把强模型的加密块塞给同家族的弱模型，后者就会”照本宣科”地朗读出来。315320个公开推理块被批量解码，182组凭证和367个PII遭恢复——而这个漏洞早在5月就被单独报告过，被三家厂商均判定为”无安全影响”。

一、加密推理块：从「心里话」到「加密数据」

1.1 思维链的两层表达

现代大模型在给出最终答案之前，会先生成一段内部”思考过程”——这才是模型真正在推理时说的话。用户界面（Chat UI）看到的，只是对这段思考的摘要或压缩版本。

API场景下情况更复杂。当客户端以无状态模式、零数据保留（ZDR）模式运行，或在工具调用循环中管理对话时，客户端需要自行维护对话状态。下一次请求时，厂商需要恢复模型的”思考状态”，但不能让客户端读到它。解决方案是：将推理块加密，以Base64字符串形式交给客户端保存，下一次请求时原样带回，厂商服务端解密后继续推理。

这个设计在逻辑上是合理的——客户端持有状态却读不到，厂商在服务端解密后继续。但问题出在实现层面。

1.2 全局密钥之殇：Portability是一把双刃剑

论文（arXiv:2608.09867，由ELLIS研究院图宾根分院和马克斯·普朗克智能系统研究所团队发表）指出了核心问题：加密推理块在同厂商生态系统内”跨会话、跨用户、跨模型完全兼容可互换”。

这意味着什么？答案几乎可以确定：三家厂商使用单一全局密钥加密所有用户的推理块，而不是按账户或按会话派生独立密钥。否则，账户A产生的块根本无法在账户B的请求中成功解密。

这一架构决策对于依赖”零数据保留”保证的用户来说是一个认知盲区：ZDR意味着厂商不存储对话内容，但并不等于你的推理状态在密码学上与所有其他客户隔离。在全局密钥体系下，它们本质上是共享的。

图片版权华盟网

二、核心攻击手法：弱模型”朗读”强模型的秘密

2.1 解码越狱（Decryption Jailbreak）

整个攻击链最精妙的部分不需要直接攻击强模型的防护栏。

攻击者拿到强模型（如Claude Opus 4.8）输出的加密推理块后，不是试图破解它，而是将其注入到同一厂商的弱模型（如Haiku 4.5）中。弱模型收到块后，厂商服务端透明地完成解密——因为用的是同一个全局密钥。弱模型看到明文推理后，会将其视为合法上下文，攻击者只需让弱模型复述这段内容，即可完成提取。

用论文原话说：Haiku 4.5可以读取 Opus 4.8的”想法”。整个过程中，强模型从未被攻击，其安全防护栏从未被触发。

这一手法在Anthropic、OpenAI和Google三家均被验证有效。

2.2 密码学观察：Matthew Green的早期发现

早在2026年5月29日，约翰霍普金斯大学密码学家Matthew Green就独立发现了类似问题，并在厂商bug bounty项目中报告。他观察到：

Anthropic推理块中有一个被标注为”signature”的字段，实际并不含真实签名
12字节的IV暗示使用了GCM或ChaCha20-GCM，但IV长度过短
修改密文中任何一个字节，API会干净利落地拒绝；但重放一个完全未修改的块，API接受得无任何报错。 这种”修改报错、重放放行”的不对称性，就是整个漏洞最简洁的描述

Green当时报告后，OpenAI判定为”不可复现”，Anthropic判定为”未发现安全影响”。十周后，116页论文证明这两个结论均为误判。

三、四大攻击向量与真实影响

3.1 反蒸馏防线崩塌

各厂商用思维链做知识产权保护的一个核心理由，就是防止竞争对手通过蒸馏（Distillation）复制能力——用强模型的输入输出对训练自己的模型。但如果连强模型的完整推理过程都能提取，那这层防线就被彻底绕过。

3.2 公开日志中的凭证矿

这是对普通开发者影响最直接的一类。

研究团队从公开仓库中爬取了大量共享的Agent会话日志，在这些日志的加密推理块中发现了大量在可见对话中从未出现过的敏感信息。典型场景：模型读取了.env文件，处理了其中的API密钥，然后给出了一个完全不提及该密钥的回复——但密钥已经被写进了推理链。

315320个推理块被成功解码，从中提取了367个PII产物和182组凭证（包括API密钥、邮箱、密码）。早期7千条trace的扫描中，就发现了62个不同API密钥、33个邮箱地址、33个密码。

3.3 有害内容的”隐形传递”

即便模型在可见输出中正确拒绝回答了有害问题，其推理过程中可能已经处理了该内容。这部分内容可以通过推理块恢复，绕过了模型的安全过滤层。

3.4 看不见的提示注入

第四个攻击向量最值得构建Agent系统的工程师警惕：如果攻击者将恶意Payload嵌入加密推理块中，当这段块被包含在公开分享的Agent日志里，任何人拿到日志后将其加载到自己的Agent流程中，就会在完全无感知的情况下执行隐藏的恶意指令。这是一种新型的提示注入（Prompt Injection），且对人工审核和大多数日志扫描工具完全不可见——因为预期的加密噪声本就长那个样子。

图片版权华盟网

四、侧信道：比密码学漏洞更难修补的一层

除了加密块本身的移植漏洞，研究还发现了独立于加密层面的侧信道攻击路径：攻击者可以通过诱导模型进行”与秘密位相关的条件推理”——当某隐藏位为0时执行廉价计算，为1时执行昂贵计算——这种计算量差异会显现在推理Token数量、块长度甚至响应耗时上。

Green用这个方法逐bit提取了一个字节的内容。这个侧信道无法通过密码学修复，因为泄漏源不是”写了什么”，而是”想了多少”。

五、验证方法：如何确认自己是否受影响

如果你曾公开分享过Claude Code、Codex或其他Agent会话日志，需要立刻做以下几件事：

第一步：定位共享日志。 搜索你的代码库、GitHub Gist、Issue、博客文章和提交记录，查找粘贴的Agent会话内容，特别关注thinking、reasoning、signature等字段中的长Base64字符串。

第二步：评估暴露面。 找到后，不仅要检查可见会话中出现的凭证——凡是在该会话运行期间Agent可能读取过的文件（.env、配置文件、数据库连接信息等），全部视为已暴露并立即轮换。

第三步：检查应用日志。 审计你的应用是否在日志中持久化了原始推理字段（reasoning_content/thinking/reasoning_trace等）。如果日志被攻陷，加密的块瞬间变成明文情报。

六、检测与防御：多层次加固方案

防御层级	具体措施	防护对象
会话级绑定	推理块绑定到会话ID，防止跨会话重放	跨会话攻击
账户级密钥派生	每个账户使用独立密钥派生，阻止跨账户提取	跨账户攻击
模型级绑定	推理块绑定到发出它的特定模型	跨模型解码越狱
密钥轮换	定期轮换全局密钥，限制长生命周期暴露	历史数据批量解密
Nonce/序列号	加入不可重放机制，重复使用同一块即报警	重放攻击
侧信道收敛	消除推理Token数量与秘密内容的可预测关联	侧信道攻击