6708条Agent记录被还原：GPT、Claude隐藏推理里翻出API密钥和密码

昨天，X用户@kotekjedi_ml公布了一组反常实验：Claude、GPT和Gemini API里原本不向用户展示的隐藏reasoning，被研究人员重新恢复成了可读文本。按正常设计，这些reasoning本来应该是看不到的。模型完成内部推理后，API会把这部分内容加密成一段opaque block返回给客户端。用户拿得到这段数据，但无法直接读取，也不能随意修改，等到下一轮调用时，再把它原样交回服务器，模型就能接着之前的状态继续推理。

问题出在绑定关系上

问题出在这些encrypted reasoning并没有始终和原来的模型、会话严格绑定。一段由强模型生成的隐藏推理，在一些情况下可以被同一家厂商的另一个模型继续读取。于是，研究人员不再尝试让强模型自己交出Chain-of-Thought，而是把它留下的encrypted reasoning交给一个更容易被绕过的兼容模型，再让后者把已经加载的内容转录出来。

整个过程没有拿到服务端密钥，也没有破解encrypted reasoning。被绕过的是这段reasoning的使用范围：系统能够确认这段数据没有被篡改，却没有在所有场景下确认当前模型和当前会话是否仍然有资格使用它。而要理解这个漏洞为什么会出现，得先看清一件事：这些隐藏reasoning为什么会离开模型，跑到客户端手里。

推理状态为什么要交给客户端

推理模型和普通聊天模型的区别，不只是回答之前多想了几步，而是这些中间状态在很多任务里还要继续使用。模型可能先拆解问题，尝试不同方案，读取工具结果，再根据中间结果修正判断。对于一次性问答，这段reasoning用完就结束；但到了长任务和Agent场景，下一轮调用往往还要接着前面的分析继续。如果每次都从头计算，不仅浪费推理成本，也会丢掉已经形成的任务状态。

服务端当然可以替每个会话长期保存完整reasoning，但这样会增加状态存储、任务恢复和上下文管理的复杂度。于是，一些API选择把内部reasoning封装成客户端无法直接读取的数据，再交给客户端保存。后续调用时，客户端把这段数据原样发回来，服务端验证后继续使用。这样做同时解决了几个工程问题：调用者看不到完整内部推理，修改后的数据也无法继续通过认证，服务端还不用长期保存全部状态。

但也正因为reasoning被交到了客户端，系统开始面对一个过去没那么突出的权限问题。加密和签名能够证明一段block是服务端生成的，而且没有被外部改动，但这只能证明数据本身可信。它不能自动证明这段数据现在还应该出现在当前账号、当前session，或者当前模型里。也就是说，一段reasoning可以完全合法，却被放到了错误的位置。接下来的跨模型攻击，正是从这里成立。

跨模型读取成为突破口

研究人员继续测试后发现，这些reasoning block并不总是只能回到原来的上下文。有些可以跨session使用，有些甚至可以换账号重新提交，而更关键的是，一些block能够被同一家厂商的其他模型继续读取。跨session本身并不奇怪。现实产品需要支持任务恢复、conversation fork、context compaction和模型切换，如果reasoning被完全锁死在原始历史中，这些能力会受到很大限制。真正带来安全问题的是cross-model compatibility。

以Claude为例，Opus先完成一个正常任务，服务端生成对应的hidden reasoning，并向客户端返回signed thinking block。研究人员没有继续要求Opus输出内部推理，而是把这段block放进Haiku的上下文。Haiku能够正常加载这段由Opus产生的reasoning。这一步一旦成立，攻击目标就发生了变化。研究人员不再需要突破Opus自己的限制，只需要让Haiku把已经读到的内容重新输出。

由于不同型号在对齐强度和jailbreak抵抗能力上并不完全一致，原本守在强模型上的限制就可能被旁路。这也意味着，一段高端模型reasoning的安全性不能只看生成它的模型。只要同一体系里的其他型号也能解释这段state，那么这些型号的安全能力同样会影响它。一个模型负责产生高价值推理，另一个模型却可能成为更容易利用的读取入口。到这里，漏洞的结构其实已经很清楚了：加密没有失效，真正缺失的是更严格的context binding。

怎么证明恢复的不是重新推理

不过还有一个更关键的问题没有回答：后面的模型吐出来的reasoning，怎么证明真的来自前面的隐藏状态，而不是它自己重新想了一遍？这个问题如果不解决，前面的攻击链就只能说明模型能够生成一段相似推理，而不能说明encrypted reasoning真的被恢复。研究人员拿不到服务端内部保存的明文trace，因此无法逐token对照，只能从多个独立信号判断恢复结果是否与原state高度对应。

其中一个信号来自thinking token数。实验让source model处理120道Codeforces问题，同时记录API报告的hidden thinking token数。随后再恢复reasoning，并重新计算恢复文本长度。如果decoder只是独立重新解题，它可能换一种算法，也可能多走或少走一些中间步骤，因此推理长度应该出现明显波动。实际结果里，Anthropic、OpenAI和Google多组模型的恢复长度与API记录的reasoning token数高度对应，大量样本靠近y=x。这不能证明每个token完全相同，但至少说明恢复文本和原始hidden computation在长度结构上存在很强对应。

更有说服力的证据来自真实Agent trajectory。研究人员收集了GitHub和Hugging Face上6708条公开Agent运行记录，从中处理出315320个reasoning block。恢复后，真实用户记录里出现了API key、password、access token、private key、邮箱以及内部技术信息，其中还有一部分内容从未出现在公开conversation history中。这意味着后面的模型并不是简单根据可见聊天内容重新推理。因为如果公开文本里根本没有这些具体值，它就没有足够信息凭空还原出来。

这组结果还顺带暴露了Agent日志里的另一个问题：用户把credential从聊天记录或代码仓库中删掉，不代表旧reasoning block里相同的信息也已经消失。Agent为了修改代码、处理配置或者清理仓库，本身就可能读取过这些内容，一旦进入reasoning，这些敏感值就被留在了隐藏状态里。