2026 年 8 月，一篇题为《Stealing Reasoning Traces from Proprietary LLM APIs》的研究论文引起了 AI 安全社区关注。研究者测试了多家前沿模型 API 在处理隐藏推理状态时的行为，发现一些服务为了保持 API 无状态，会把模型内部推理以加密块的形式返回给客户端，后续请求再由客户端原样送回。研究指出，这些加密块在部分模型生态中可以跨会话、跨用户甚至跨模型复用，而同一家供应商中防护较弱的小模型可能在接受强模型生成的加密块后，把其中内容以明文形式近似还原。
这项研究的价值不在“模型会不会泄露神秘思维”这个标题，而在它碰到了一个很现实的 API 架构问题：加密保证了数据没被外部直接解密，却没有天然保证这段密文只能在原来的用户、会话和模型语境中使用。 当 LLM 逐渐成为状态机和 Agent Runtime 的一部分，如何把“内容”和“产生内容的上下文”一起认证，会成为新的安全边界。
需要先说明一点：模型供应商并没有公开完整的内部推理加密协议，研究者对信封格式、认证字段和兼容性的判断，主要来自黑盒实验与可观察行为。文章讨论的是 2026 年 7—8 月测试到的系统状态，后续服务端策略完全可能更新。因此它更适合被理解为一个架构级漏洞研究，而不是永久有效的供应商行为说明。
为什么服务端要把隐藏状态交给客户端保管
多轮聊天看起来像服务端一直“记得”前面发生过什么，很多 LLM API 实际上尽量保持无状态。客户端在下一轮请求里重新提交此前消息、工具结果和需要续接的内部状态，服务端收到完整上下文后继续计算。这样做的好处非常明显：供应商不必为全球每一个 API 会话永久维护服务器状态，水平扩展、容灾和路由也容易得多。
问题在于，推理模型在生成最终答案之前可能存在一段内部 reasoning trace。供应商不希望把完整 trace 明文暴露给用户，一方面涉及模型知识产权和蒸馏风险，另一方面内部推理可能包含敏感工具输出、临时错误假设或者被最终安全过滤挡住的内容。于是一个合理设计是：服务端把内部状态加密，再把密文交给客户端；客户端看不懂，但后续请求可以把这段密文原样带回。
从密码学角度，这通常可以用 AEAD（Authenticated Encryption with Associated Data）来实现。密文提供保密性，认证标签提供完整性，Associated Data 可以把模型版本、块类型、协议版本等字段也纳入认证。只要攻击者没有密钥，就不能直接修改或解开密文。
研究发现的关键问题恰恰在这里：“密文有效”与“密文在当前上下文中有效”是两件不同的事。
加密没有失败，失败的是上下文绑定
如果一段 reasoning block 的认证数据只包含模型版本、块类型和 key id，却没有绑定生成它的账户、会话 ID、前序状态指纹，那么它只证明“这是供应商合法生成且未被修改的一段状态”。服务端收到它时，缺乏密码学证据判断“它是不是这个用户在这个会话里产生的”。
研究者把这种现象拆成三个层次。第一层是跨会话兼容：旧会话的 reasoning block 可以放到新会话里。第二层是跨用户兼容：A 账户生成的块可能被 B 账户接受。第三层是跨模型兼容：同一供应商的不同型号可以消费彼此生成的块。
这些兼容性并非纯粹的设计错误。它们也支持正常产品功能。用户可以 fork 对话、删除一部分旧历史、切换模型继续聊天；服务端做负载均衡时，也可能把下一轮请求路由到同一系列的另一型号。如果把状态死死绑定到完整原始 transcript，很多灵活功能都会消失。安全问题来自兼容范围过大，而配套授权边界没有同步收紧。
为什么弱模型会变成“模糊解码器”
论文中最有意思的攻击思路并不需要破解 AES，也不需要得到服务器密钥。研究者观察到，旗舰模型往往接受更严格的反蒸馏和输出过滤训练，而价格较低的小模型为了速度和成本，可能没有同等强度的防护。如果强模型生成的加密 reasoning block 能被同一家族的弱模型接受，那么弱模型就可以读取其内部表示并依据指令把内容重新表达出来。
这里的“读取”要理解准确。弱模型并没有在密码学意义上拿到密钥再解密，它是服务系统的合法参与者，服务端已经为它恢复了这段内部状态。攻击者利用的是模型间状态兼容 + 防护强度不一致。论文把弱模型称为 fuzzy decoder，因为还原结果是模型生成的近似明文，不一定字节级等同原 trace。
这也是为什么单纯加强旗舰模型的拒答训练不够。强模型从来没有收到“把你的隐私推理告诉我”这类请求；它只回答了一个正常问题，生成的内部状态后来被转交给另一个模型。在安全工程里，这属于典型的跨组件信任边界问题：组件 A 的安全假设建立在组件 B 也足够安全之上，而系统没有强制这个假设。
315,320 个公开 reasoning blocks 暴露了日志分享的风险
研究者从公开代码仓库和会话日志中收集并分析了 315,320 个 reasoning block，报告称恢复出 367 条个人可识别信息（PII）以及 182 份凭据。这里最值得企业关注的并不是绝对数量，而是日志处理方式。
开发者分享 Agent 会话日志时，通常会检查明文部分，删除 API Key、密码、邮箱或者客户数据。但一段不可读的 base64 加密字段很容易被当成“没有信息量的签名”保留下来。问题是，这个字段可能封装了模型曾经读到的上下文、工具输出或秘密。如果供应商生态存在可重放和可恢复路径，发布者自己无法检查的密文反而成为长期携带秘密的容器。
对于 Coding Agent、MCP、自动化运维和企业知识库场景，这个风险尤其现实。模型要修改配置，自然需要读配置；要清理硬编码密钥，自然会先看到密钥；要分析数据库错误，可能会接触连接串。最终答案可以被脱敏，但 reasoning state、tool state、缓存和 trace 仍可能保留原始敏感内容。
所以一个很朴素但重要的运营规则是：公开会话日志时，不要尝试“清洗”看不懂的加密 reasoning block，直接移除。
论文列出的四类风险，本质上都来自状态可移植性过宽
第一类是反蒸馏绕过。攻击者可以批量收集强模型的内部推理，作为训练更便宜模型的数据。最终答案只告诉模仿者“结果是什么”，reasoning trace 则可能包含“怎么到达结果”，数据价值更高。
第二类是隐私信息恢复。公开日志中不可见的 reasoning block 可能携带凭据和用户数据。第三类是安全过滤旁路：模型内部可能曾经推演过危险内容，最终答案经过安全策略后拒绝，但内部 trace 本身比最终输出更完整。第四类是不可见提示注入：如果恶意内容能够被封装进合法状态并在后续会话中复用，Agent 可能在用户看不到明文指令的情况下受影响。
讨论这些风险时不必夸大“隐藏推理等于模型真实思想”。LLM 的 chain of thought 是生成过程中的文本状态，不是人的意识记录，而且不同模型、不同 API 对内部状态的实现也不相同。安全工程关心的是它可能包含高价值信息，并参与下一步模型行为，因此应被当作敏感状态管理。
修复方向：给密文加上“它属于谁、属于哪段会话”的证明
最直接的补丁是把账户标识纳入 AEAD 的 Associated Data。服务端在接受 block 时同时验证调用者身份，只要账户不一致就拒绝。这样可以阻断跨用户重放，又不需要服务端保存所有会话状态。
跨会话绑定更复杂，因为产品往往需要允许分叉、裁剪历史和切换模型。论文提出可以用 hash chain 把每个 reasoning block 与前一个 block 的指纹连接起来，再用 Merkle Tree 保留被裁剪历史的根摘要。这样服务端不必存完整上下文，也能检查状态顺序和会话连续性。
对已经公开出去的旧 block，补加账户字段已经来不及。更彻底的办法是轮换旧 key id，并拒绝继续接受旧密钥签发的状态；代价是合法旧会话也可能无法无缝继续。另一类方案是把状态改为服务端保存，只给客户端 opaque handle，安全边界更清楚，却重新引入大规模存储和会话粘性成本。
供应商还可以缩窄跨模型兼容范围，在 API Gateway 层拒绝不符合目标模型版本的 reasoning block，并训练所有家族成员拒绝“转写内部状态”类任务。不过这类模型层防护更适合作为第二道防线，不能替代协议层授权。
对企业 Agent 来说，安全边界已经从 Prompt 扩展到状态管理
这项研究给企业落地 Agent 的最大提醒，是不要把安全只理解成“System Prompt 写得够不够严”和“MCP 工具有没有权限”。一个长期运行的 Agent 会产生大量中间状态：模型隐藏状态、工具输出、缓存、checkpoint、消息队列、审计日志、浏览器快照。它们中的任何一个都可能成为敏感数据载体。
因此企业需要建立更完整的状态生命周期：哪些状态可以落盘，保存多久，能否跨用户复用，能否用于模型切换，是否进入日志，导出会话时哪些字段必须删除。状态越可移植，授权就越需要跟上。很多分布式系统已经熟悉“数据对象 + 身份 + 租户 + 会话 + 版本”的绑定，大模型 API 只是在一个新的位置重新遇到了同样的问题。
这篇论文有很强的戏剧性标题，但它揭示的问题其实很传统：密码学只能保护你明确认证的东西。 如果协议证明了“内容是真的”，却没有证明“内容属于当前用户和当前会话”，系统仍可能在合法解密路径上泄露信息。随着 Agent、长上下文和无状态 API 越来越普及，这类“上下文认证”会成为 AI 基础设施安全设计的重要部分。
参考资料
- Panfilov et al., Stealing Reasoning Traces from Proprietary LLM APIs, arXiv:2608.09867, 2026-08-10
https://arxiv.org/abs/2608.09867 - ByteByteGo, How to Steal an AI Model’s Private Thoughts, 2026-08-25
https://blog.bytebytego.com/p/how-to-steal-an-ai-models-private - Horizon Summary, 2026-08-26
https://thysrael.github.io/Horizon/2026/08/26/summary-zh.html