看不见的 Reasoning State，为什么不能拥有看得见的工具权限
一次 Agent 工具调用结束后，系统把模型返回的 reasoning、signature 或 encrypted_content 连同消息一起存进数据库。下一轮换了会话、切了模型，甚至把轨迹发到可观测平台，应用仍把这块不可读内容原样带回 API。
工程师很容易给自己一个安全感：内容是密文，我们也看不懂，所以它顶多是缓存。
2026 年 8 月公开的预印本《Stealing Reasoning Traces from Proprietary LLM APIs》恰好击中了这个判断。作者没有恢复密钥，也没有破坏 AES 或 AEAD。他们在 2026 年 7 月的 API 快照中，把一个模型产生的加密推理状态交给同一供应商生态中的兼容模型；服务端接受并恢复状态后，较弱模型在特制上下文里把隐藏内容转写成文本。
这不是"密文被本地解开"，而是"票据格式有效，但系统没有充分限制谁能在什么上下文消费它"。论文作者在披露后表示原方法已无法继续启动；截至 2026 年 8 月 26 日，公开资料仍不足以说明每家具体改了哪一层，也不足以证明这个攻击类别已经永久消失。因此本文只把论文当作一份历史架构反例，不提供攻击复现，也不把当前 API 写成仍可利用。
官方 API 仍需要推理状态，但字段存在不等于漏洞存在
三家当前官方文档都保留了"让模型延续推理"的状态对象，只是表示方式和生命周期不同。
OpenAI Responses API 的 reasoning item 可以包含摘要，也可以按请求返回 encrypted_content；手工管理上下文时，应用需要把相关 reasoning item 传回后续请求。
Anthropic 的 thinking block 会参与多轮和工具循环，不同模型与 adaptive/manual 模式对历史 thinking block 的保留方式已经发生变化。
Google 的 thought signature 是加密的内部推理状态表示；在 stateless 流程中要原样回传，而推荐的 stateful Interactions 模式由服务端管理这些状态。
这些当前文档只能证明一个产品事实：推理连续性仍需要被表示和传递。它们不能证明论文中的历史越权路径现在仍然成立。反过来，供应商修复了某条转写路径，也不等于应用可以把 opaque state 当普通日志字段公开。
因为风险取决于两个条件的组合：状态以后还能被谁消费，以及消费后能影响什么。
论文真正暴露的是两次授权被混成了一次
第一层授权是"这个状态能否被某个请求恢复"。它应绑定租户、用户、会话、模型族、状态序号和有效期。只验证签名正确或格式兼容，会把密文误当成不记名票据：拿到它的人未必知道里面是什么，却可能让后端替自己消费。
第二层授权是"模型根据恢复后的状态提出的动作能否执行"。这是 Agent 特有的完整性问题。隐藏状态可能包含旧计划、旧工具结果、被外部内容影响后的指令，甚至来自另一个权限域的目标。即使它没有被转写成可见文本，也可能改变下一步调用哪个工具、操作哪个文件或把数据发往哪里。
如果工具层只问"模型想不想做"，两层授权就被合并了：能够恢复状态，近似等于能够继承旧状态里的行动能力。
更稳妥的边界是：Reasoning State 只能帮助模型提出候选计划，不能证明当前主体有权执行计划。
最小工具授权合同必须只依赖当前可见事实
每次产生副作用前，模型外的 policy engine 至少重新判断这些字段：
| 字段 | 要回答的问题 |
|---|---|
tenant_id / user_id |
当前动作属于谁，是否与状态创建主体一致 |
session_epoch |
是否发生过切模型、分叉、恢复或权限变更 |
tool / arguments |
具体要调用什么，参数触及哪些资源 |
visible_intent |
当前用户可见请求是否支持这次动作 |
data_classification |
输入与输出是否含凭据、个人信息或内部数据 |
approval |
是否需要用户或人工确认，确认是否仍在有效期内 |
policy_version |
授权依据是哪一版策略，变更后旧决定是否失效 |
可以把决策写成一个明确函数：
text
allow = policy(current_subject, current_visible_intent,
tool, arguments, data_classification,
session_epoch, approval, policy_version)这里故意没有 reasoning_state_says_allowed。隐藏状态可以提供上下文，但不能成为授权来源。读取文件和列目录可以自动放行；发邮件、转账、删数据、推送代码或访问生产凭据则应做参数级校验，并使用面向单次动作、最小权限、短生命周期的 token。
三类状态需要三种生命周期
把所有东西都塞回完整消息历史，会让安全边界变得不可见。更容易执行的分层是：
| 状态 | 允许保存什么 | 生命周期与迁移规则 |
|---|---|---|
| 事实记忆 | 经净化、可见、可编辑的事实和决策 | 可长期保存；变更有来源和版本 |
| 执行状态 | 当前任务、步骤、工具结果、补偿和审批 | 绑定租户、会话与策略；切权限域必须重建 |
| 推理状态 | 厂商返回的 opaque reasoning block/signature | 最短保存；默认不可导出、不可进公开日志、不可进入长期记忆 |
模型切换、会话 fork、compaction 或从故障快照恢复时，都应创建新的 session_epoch。旧状态若必须迁移，要记录 source model、target model、迁移原因、状态摘要、key/version 标识和策略版本；不支持的迁移直接丢弃 opaque block，改用经过净化的事实摘要继续。
这会牺牲一部分连续性。某些长任务在丢弃推理状态后需要重新规划，成本和延迟都会增加。但这比把未知状态永久带过权限边界更可控。更简单的替代是优先使用供应商的服务端 stateful 模式，让 opaque block 不离开原信任边界；它仍不能替代工具授权，却能减少客户端日志、导出与误用面。
不记录原始思维链，也能留下足够的审计证据
安全审计不需要保存 raw Chain-of-Thought。系统可以记录不可逆的 block 摘要、创建主体、source/target model、状态版本、session_epoch、迁移原因、压缩或分叉事件，以及工具调用前的可见意图、策略版本和最终授权结果。
公开 trace、Issue、客服工单和训练数据导出则应按字段语义清理。凡是 reasoning、signature、encrypted content 或供应商等价字段，默认当作敏感且可重放的状态，而不是因为"看不懂"就当作已经脱敏。论文扫描的是 6,708 条公开轨迹中的 315,320 个 reasoning block，并在特定数据集与模型判断流程下标记出隐私和凭据制品；这些数字不能外推成行业泄漏率，却足以说明公开日志不是安全的默认去向。
真正需要改变的不是一句更强的系统提示，而是两条工程规则：隐藏状态不能跨主体和权限域自由迁移；任何看得见的副作用，都要依据当前看得见的意图重新授权。
Reasoning State 可以是连续性的载体，但不能是一张把旧权限带进新会话的通行证。
主要来源
- Panfilov et al., Stealing Reasoning Traces from Proprietary LLM APIs ，arXiv:2608.09867 v1（2026-08-26 检查） arxiv.org/abs/2608.09...
- OpenAI Reasoning models guide（2026-08-26 检查） developers.openai.com/api/docs/gu...
- Anthropic Thinking / Extended thinking 文档（2026-08-26 检查） platform.claude.com/docs/en/bui...
- Google Gemini Thinking 文档（2026-08-26 检查） ai.google.dev/gemini-api/...