看到一段无法阅读的加密文本，人很容易把它当成“安全的乱码”。但在大模型 API 里，这类不透明数据可能保存着模型的隐藏推理、工具返回值，甚至用户输入过的敏感信息。
2026 年 8 月提交的论文《Stealing Reasoning Traces from Proprietary LLM APIs》提出了一个反直觉的风险：研究者没有暴力破解密钥，也没有直接攻破防护最严的前沿模型，而是利用加密推理块可以跨会话、跨用户和跨模型复用的特性，把它交给同一家服务商中防护较弱的兼容模型处理。
本文由《听懂 AI》第 003 期整理而成。事实来源是 Alexander Panfilov 等 8 位作者于 2026 年 8 月 10 日提交的 arXiv 预印本及作者项目页。论文测试的是 2026 年 7 月初可用的特定 API 和模型版本，不能直接代表今天所有接口仍然存在相同行为。
什么是“加密推理块”
推理模型在给出最终回答前，会生成较长的中间推理。服务商通常不把完整推理以明文返回，而是向客户端提供摘要，以及一段签名或加密后的不透明数据。客户端保存这段数据，并在下一轮请求时原样传回，让模型延续之前的推理状态。
论文把这种数据描述为经过认证加密的封装。它既能防止用户直接阅读，也能检测内容是否被篡改，同时让服务端不必长期保存每次会话的完整推理。
需要注意，论文作者也明确说，各服务商没有公开完整的密码学实现。因此，文章中的具体结构和密钥使用方式来自研究者的实验观察与推断，不是服务商公开的协议承诺。
问题不一定是“加密被破解”
论文发现的关键在于兼容范围过大。一个推理块可能被拿到另一段会话、另一个用户，甚至同一服务商的另一个模型中继续使用。
攻击者可以先从能力强、拒绝训练更严格的模型获得一个加密推理块，再把它送给较弱但兼容的模型。后者本来就需要合法解开并处理这类数据，研究者再诱导它把处理到的内容输出出来。
整个过程不需要知道加密密钥，也没有修改密文。真正失守的是“这段加密数据只能在原来的用户、会话和模型里使用”这一安全边界。
示意图只说明安全边界和防御方向，不包含论文中的具体攻击提示或供应商实现细节。
论文描述了四类风险
第一类是模型蒸馏。竞争者可能批量提取强模型的隐藏推理，用来训练或模仿另一个模型，绕过服务商隐藏思维过程的初衷。
第二类是敏感数据泄露。开发者公开 Agent 会话、评测轨迹或 API 日志时，常常只清理肉眼可见的文本，却保留看似无害的不透明推理块。秘密可能仍藏在里面。
第三类是拒答背后的危险内容。模型最终可能正确拒绝一个恶意请求，但隐藏推理已经处理过更具体的信息。如果推理块可以被恢复，安全的最终回答并不代表整个执行过程都没有泄露。
第四类是不可见提示注入。恶意指令可以隐藏在不透明数据中，人工审查日志时看不见，后续接手同一轨迹的 Agent 却可能读取并执行。论文把它作为概念验证和长时任务污染风险来讨论。
31 万个推理块里发现了什么
研究者从 GitHub 和 Hugging Face 收集了 6,708 条公开 Agent 轨迹，重建了 315,320 个推理块。完整论文给出的统计包括：
- 1,028 个推理块，也就是约 0.3%，包含至少一项隐私泄露；
- 328 条轨迹，也就是 6,708 条中的 4.9%，至少泄露过一项真实敏感信息；
- 在排除基准测试身份后的真实用户会话中，研究者去重得到 704 项隐私数据；
- 其中包括 62 个 API Key、33 个密码、24 个访问令牌、7 个私钥和 30 个个人邮箱；
- 64 项数据只出现在隐藏推理中，没有出现在可见聊天记录里。
论文摘要还用另一组分类口径概括为 367 项个人身份信息和 182 项凭据。不同数字对应不同分类、去重和数据范围，不能直接相加，也不能理解成同样数量的独立受害者。
研究样本来自公开轨迹，不是对整个互联网或所有生产系统的普查。论文也使用两阶段自动分类筛掉占位符和测试数据，但这仍是一项定向研究，不是完整的泄露率调查。
为什么“我已经清理日志”仍可能不够
论文给出的一个典型风险是会话清理：用户要求 Agent 删除仓库中的秘密，模型在隐藏推理中重新读取并复述这些值；最终可见回答只说“已经清理”，但不透明推理块仍可能保留原值。
因此，只搜索最终回答里的 API_KEY 或密码格式并不够。共享原始 API 记录前，还需要删除 signature、thinkingSignature、encrypted_content 等不透明推理字段。字段名称会随供应商和 SDK 改变，不能依赖一份永远不变的黑名单。
如果含有此类数据的会话已经进入公开 Git 仓库，删除最新文件也不代表历史提交消失。应当检查 Git 历史、缓存、制品和数据集副本，并轮换可能已经暴露的凭据。
论文有哪些限制，漏洞现在还存在吗
这篇论文是 2026 年 8 月 10 日提交的 v1 预印本。实验针对 2026 年 7 月初的 Anthropic、OpenAI 和 Google API 版本，服务商可以在不公告的情况下改变内部实现。
作者无法看到隐藏推理的真实明文，因此不能逐字证明每次提取都完全正确。他们主要用 API 报告的思考 token 数量与恢复文本的 token 数量做对照，并在 120 个 Codeforces 问题上观察到较强的一致性。这是提取可信度的证据，但不是完整的明文真值验证。
论文还说明，团队在发表前已向相关模型服务商、Microsoft 和 Hugging Face 负责任披露。作者报告说，各服务商确认收到报告，此后他们已经无法用相同方法继续发动攻击。这说明供应商可能采取了缓解措施，但不能据此推断所有历史数据已经安全，也不能证明所有相邻攻击面永久消失。
服务商和开发者分别能做什么
论文建议服务商使用多层防御：
- 把完整推理留在服务端，客户端只拿随机句柄；
- 在认证加密中绑定用户、会话、模型、前序提示和对话历史；
- 在 API 网关阻止跨模型推理块；
- 为异常重放提供签名或密钥撤销机制；
- 训练模型拒绝输出隐藏推理，并监控异常提取模式。
更严格的上下文绑定会影响合法的会话压缩、历史编辑和模型切换，因此不是简单增加一个字段就能完成。即使绑定正确，只要某个模型必须解开并处理旧推理，模型级提示攻击仍可能成为风险，所以需要纵深防御。
开发者现在可以做这些事：
- 把不透明推理块当作敏感数据，而不是普通日志；
- 发布会话、轨迹或复现包前，删除完整推理字段；
- 不把未经验证的外部推理块传给 Agent；
- 检查已经公开的仓库与历史提交，必要时轮换凭据；
- 在日志策略里明确区分可见回答、工具结果和隐藏推理载荷。
密文不是废数据，也不是天然安全的秘密存储。看不懂一段内容，只说明人无法直接阅读，并不代表系统中的其他组件也无法处理它。
收听本期节目
原始资料与延伸阅读
- Alexander Panfilov、David Schmotz、Ilia Shumailov 等，2026-08-10：Stealing Reasoning Traces from Proprietary LLM APIs
- arXiv：论文 HTML 全文——包含威胁模型、实验结果、限制、披露过程和缓解方案。
- 论文作者：Stolen Thoughts 项目页——论文结果的交互式说明；示例中可能包含安全研究材料，阅读时不要复制其中的攻击提示或凭据样例。
资料说明：本文的技术结论和数字均来自论文 v1。论文作者报告的攻击状态、供应商范围和缓解结果具有时间性，后续版本或服务商更新可能改变结论。
Select Language