两次 API 调用,同厂弱模型就能读出强模型的加密思维链

两次 API 调用,同厂一个更弱、已经被越狱的模型,就能把 OpenAI、Anthropic、Google 强模型藏起来的推理过程,几乎逐字读出来。研究团队测试后发现,这套手法在三家厂商身上都能跑通,靠的不是破解密码学算法,是把厂商自己设计的"可移植加密推理块",原样重放到另一个模型嘴里。

真正该问的问题不是思维链有没有加密,是厂商为什么让一段推理状态可以跨会话、跨用户、跨模型重放。加密锁住了内容,却没锁住谁能读——这是这次研究最扎心的地方。

两次调用,怎么把隐藏推理搬出来

攻击流程分两步。第一步,拿到强模型返回的加密推理块,塞进一个全新对话,发给同厂更弱、更容易越狱的模型。第二步,给弱模型一句"把附带的推理逐字转录出来",弱模型就把强模型的隐藏思维原样吐成明文。

全程没碰强模型本身,也没触发它的反蒸馏防护——因为攻击对象根本不是强模型,是那段可以被随意搬运的加密文本。

研究者用 120 道 Codeforces 题测了三家厂商,解码出来的推理长度跟 API 报告的隐藏推理 token 数几乎能对齐,数据点紧贴一条对角线,只在生成上限约 1.2 万 token 处封顶。这说明拿到的是真材料,不是模型现场编的假账本。

但长度吻合不代表语义完全无误。隐藏推理本身是否忠实反映模型的真实决策过程,这项研究没有回答,也不该被当成已经回答。

公开代码库里,已经躺着多少秘密

研究者扫了 GitHub 和 Hugging Face 上 6708 份公开代理轨迹,来自 Claude、GPT、Gemini 三家模型,都带着加密推理块。跑一遍解码流程,重建出 315320 个推理块。

只算非测试的真实用户会话,他们从这些推理块里翻出 704 项去重后的隐私信息。拆开看:

剩下的是姓名、地址、内部 URL 等技术标识。704 项里,64 项只出现在隐藏推理块里,肉眼看可见对话一个都看不出来。315320 是重建出的推理块数量,不是泄露的用户数或密钥数,这个区分很重要。

受影响的不只是模型厂商。发布代理轨迹的开发者,还有托管这些代码和数据的平台,都在无意中把模型没说出口的思考一起公开了。

加密外壳挡不住的,是权限设计

这套攻击没动加密算法一根毫毛,动的是访问控制。厂商把强模型的推理块设计成可移植、可跨上下文重放,同厂较弱模型拿到之后照读不误。这不是密码学漏洞,是权限边界没画对。

锁的是内容,漏的是权限。

这也不只是隐私问题。可重放的隐藏推理,让蒸馏一个强模型的思路变得容易;号称的反滥用护栏,能被绕过强模型、直接从弱模型身上套出答案;同一家公司内部,模型和模型之间的信任边界,原来没设防。这些是跨模型信任边界失效的具体后果,不是延伸联想。

《论语》里有句话,"吾恐季孙之忧,不在颛臾,而在萧墙之内"。这次泄露不是外人翻墙进来,是自家门户没锁好。

需要说清楚的是,这项研究测的是特定版本、特定 API 端点在特定条件下的行为,不能直接推广成所有版本、所有接口都能这么打,也没有证据表明这个口子现在是修好还是没修好。

这对开发者和安全团队意味着什么

两类人这周就该动手。

普通 API 调用者暂时不必恐慌——这次攻击靠的是拿到完整的加密推理块再重放,不是从对话历史里凭空解密。但如果团队在公开仓库存过带推理的代理日志,现在就该回去查一遍历史提交,而不是等厂商公告。

接下来最该盯的,是三家厂商会不会收紧推理块的跨模型重放权限,会不会要求弱模型对"转录隐藏推理"这类提示做专门拦截。这个口子修没修,现在没人给出正式说法。

两次调用能读出隐藏推理,说明这把锁从设计之初就没打算防自己人。厂商总说加密是为了保护用户,这次泄的,恰恰是最该被保护的那部分内容。