參考來源：arXiv:2608.09867、Stolen Thoughts 研究站点、The Decoder、CocoLoop、Hugging Face Papers；核验论文提交节点、The Decoder 发布节点、OpenAI/Anthropic/Google API 范围、315,320 个重建推理块、6,708 条公开轨迹、704 个隐私痕迹、367 个 PII 与 182 个凭证等口径。
推理加密塊洩出模型底稿
加密推理块原本是给 API 省状态、保连续对话用的，现在被安全研究人员拧成了一把解码钥匙。
8 月 10 日，Alexander Panfilov、David Schmotz、Ilia Shumailov 等 8 名研究人员在 arXiv 提交论文《Stealing Reasoning Traces from Proprietary LLM APIs》。8 月 11 日，The Decoder 报道了这项研究。论文和项目页给出的结论很直接：OpenAI、Anthropic、Google 等供应商在 API 中返回给客户端的加密 reasoning trace，可以跨会话、跨用户、跨同一家供应商的模型复用；攻击者把强模型生成的加密块塞给防护较弱的同门模型，就可能让后者吐出强模型的隐藏推理。
研究站点把这个过程压缩成一句话：
> “Proprietary reasoning can be recovered from its encrypted traces.”
自然说，就是“看不见的推理”并没有因为加密块离开服务器就天然安全。
## 问题卡在无状态设计
推理模型通常不会把完整 chain-of-thought 直接展示给用户。供应商既要保护模型能力和安全策略，又要让多轮对话保留上下文，于是采用一种折中设计：模型把隐藏推理打包成加密块交给客户端；客户端后续请求再把这段块带回去，服务端继续接上。
这套设计的好处是供应商不用替每个会话长期保存完整状态。风险也在这里：研究人员发现，这些块在同一供应商生态内“可携带”。它们不只属于某个原始会话，也不只绑定某个原始模型。
论文给出的攻击路径分两步。先从前沿模型请求中拿到加密推理块；再把它注入同一家供应商中成本更低、防护更弱的模型，并用越狱提示要求后者转写。论文图 1 的示例中，Claude Opus 4.8 生成的推理签名，被送入 Claude Haiku 4.5 后，后者输出了前者隐藏推理的明文片段。论文称同类现象也在 OpenAI 和 Google API 上得到验证。
它不同于普通 prompt injection。普通注入攻击要让目标模型当场违反规则；这里攻击的目标，是客户端手里的“推理包裹”能否被别的模型拆开。安全边界从模型回答，滑到了 API 会话状态本身。
## 公开日志里已经有泄漏物
更麻烦的一层在公开数据。研究人员从 GitHub 和 Hugging Face 收集了 6,708 条公开 agent 轨迹，里面包含 Claude、GPT、Gemini 生成的加密推理块。解码流水线跑完后，得到 315,320 个重建推理块。
在去掉 benchmark 和非真实用户会话后，研究团队报告发现 704 个不同隐私痕迹：其中包括 62 个 API key、33 个密码、24 个访问 token、30 个个人邮箱，以及姓名、邮寄地址、内部 URL 和其它技术标识。论文摘要在另一个口径下汇总为 367 个 PII artifact 和 182 个凭证；项目页图表则把这些痕迹分成 351 个技术标识、204 个 PII、126 个凭证和 23 个其它项目。
这些数字不能混读。315,320 是重建推理块数量；704 是项目页按去重后展示的隐私痕迹；367 和 182 是论文摘要按 PII 与 credential 两类归纳的数量。共同指向同一件事：开发者以为公开的是“看不懂的加密文本”，实际可能同时公开了模型在内部推理时看见过的秘密。
这对中文开发者很贴近。很多团队会把 agent 运行日志、评测轨迹、复现材料上传到 GitHub 或 Hugging Face。过去大家主要检查 visible message、环境变量和显式配置文件；这篇论文提醒，客户端保存的加密 reasoning block 也该被当成敏感数据处理。
## 厂商修补还没统一口径
论文写明，团队在发表前已向受影响的主要模型 API 供应商、Microsoft 和 Hugging Face 披露漏洞与初步扫描结果。论文还提到，早在 2026 年 5 月，相关研究已经指出 reasoning trace 可互换的问题；本次工作把它扩展到跨会话、跨用户、跨模型的可扩展解码和隐私扫描。
这类漏洞的修补方向并不神秘，却会牵动 API 设计。论文提出的方向包括把加密块与会话、用户、模型或用途做更强绑定；引入不可转移的认证机制；减少客户端可携带状态里包含的敏感中间信息；以及为公开日志和 agent 数据集提供更严格的清洗规则。
难点在产品取舍。无状态 API 对开发者友好，日志复现也方便；强绑定会增加服务端状态管理、调试成本和兼容性压力。对供应商来说，推理块既是上下文续接材料，也是商业秘密、安全策略和用户数据的混合容器。只把它当成“加密字符串”转来转去，风险已经被这篇论文量化。
## Agent 时代的日志要重审
这条新闻的产业信号不在“某一家模型被攻破”，而在 agent 工作流的默认假设要更新。
过去一年，开发者越来越习惯把完整 agent trace 留下来：模型看过什么文件、调过什么工具、失败了几次、怎么修复，全都写进日志。这样做利于复现、评测和微调，也利于团队排查任务失败。但当隐藏推理以客户端可携带加密块形式出现，日志里就多了一类肉眼无法审查的高风险对象。
企业团队的短期动作很具体。第一，公开仓库和数据集里直接剔除 reasoning signature、encrypted_content、thinking block 等字段。第二，把 agent 日志按密钥、邮箱、内部 URL、客户数据做二次扫描，不能只扫可见对话。第三，供应商 API 更新后，要确认旧 trace 是否仍可被复用，历史数据是否需要轮换密钥或撤回。
这也是 AI 安全从“模型会不会乱答”转向“系统会不会泄露工作过程”的节点。推理模型越会规划、越会调工具，中间轨迹就越像一份操作底稿。底稿如果被压成加密块交回客户端，安全边界就不能停在最终回答上。
后续最该看的指标，是三家供应商是否公开说明修复范围：加密块是否绑定会话和用户、旧日志是否受影响、开发者该删除哪些字段、云平台和开源评测数据集是否同步清洗。没有这些动作，agent 生态里的“可复现日志”会继续和“不可见秘密”绑在一起。