如何窃取AI模型的私密想法
传统 AI 安全方案通常需要在应用代码中为每个 MCP server 硬编码权限，或使用静态 API token 实现全有或全无的访问（并祈祷 LLM 不会偏离预期行为）。
Teleport 通过零代码 MCP 集成消除了这些问题，应用了与人类工程师相同的零信任安全原则：
默认拒绝新工具的最小权限访问控制
针对高风险工具的按需（JIT）访问请求
记录每步操作——附带完整的审计与身份上下文
对 MCP server、数据库和 Kubernetes 集群的零信任 agent 访问
无需编写授权代码、重写 MCP server，也不必限制 agent 的能力。
当 AI 模型处理复杂问题时，会生成三段独立的文本：
第一段是屏幕上显示的答案。
第二段是较短的「思考」或「推理」块，通常在答案组装过程中出现。
第三段是模型的完整推理过程，从不直接展示。
第二段文本是对第三段的摘要，它独立生成并在原地替换原始推理过程。完整推理链路更长，且包含摘要省略的内容。大多数主流厂商都对此加以隐藏。然而，作为完整过程的替代，对话期间会向客户端分享一份加密版本。
2026 年 8 月，MATS Research、ELLIS 学院蒂宾根分校以及马克斯·普朗克智能系统研究所的研究团队希望验证：Anthropic、OpenAI 和 Google 返还给客户端的加密推理块是否真的能保护推理隐私。他们证明，这些块可以被回放进同系列更便宜的模型中，后者会将隐藏推理以明文形式输出。换言之，AI 模型的思想被窃取，暴露了本应保密的信息。
本文我们将介绍研究人员的发现：
推理轨迹是什么，它和答案、摘要有什么区别
服务商为什么隐藏推理内容
隐藏带来的存储问题，以及两种解决方案
加密块里装了什么，它用来认证什么
随之而来的三种兼容性
提取方法及其验证方式
四种攻击路径
对公开会话日志扫描后的发现
建议的修复方案，以及依然存在的局限
声明：本文基于多个公开渠道的信息整理，参考文献见文末。如有不准确之处，欢迎在评论区指出。
推理轨迹
现代前沿模型在给出可见答案之前，会先生成一段很长的内部文本。比如让模型解一道高难度数学题，它可能先写出两千词的探索过程，包括各种死胡同和自我修正，最后才凝练成两百词的简洁答案。这段更长的探索过程就是推理轨迹，也叫思维链。
轨迹中记录了模型尝试过又放弃的中间假设，包括调用工具的原始输出、模型处理过程中的用户数据，以及会话里出现的各种上下文敏感信息。不出所料，这些轨迹比最终精修过的输出要密集得多，暴露的信息也多得多。
举个例子，如果让一个 coding agent 去清除代码仓库里硬编码的凭证，它必须先读取这些凭证才能干活。换句话说，在任何答案产出之前，凭证就已经流经推理轨迹了。
隐藏的理由
那模型服务商为什么要隐藏这些推理轨迹？
主要有两个原因：
第一个原因是商业上的。竞争对手可以从一个强大的模型中收集大量推理轨迹，作为构建更廉价模仿模型的训练数据。这是因为最终答案只提供计算的终点，而推理轨迹揭示了背后的方法论。
第二个原因是安全相关的。模型有时需要生成对有害主题的推理过程，以便据此做出拒绝回复。将完整轨迹过滤为安全可见答案的机制，是在轨迹已经生成之后才运行的。如果公开轨迹，就等于跳过了该过滤步骤，让用户看到了这些本不该泄露的信息。
状态管理
不让推理轨迹到达用户，并不意味着轨迹本身不需要保留。在多轮对话中，早期轮次的推理结果必须在后续轮次中可用。例如，向模型 API 发送的请求本身不包含任何历史上下文。我们在聊天窗口中看到的连贯性，是由客户端在每条消息中重新发送完整历史来实现的。然而服务端是无状态的，即在不同请求之间不存储任何信息。
这为我们提供了两种选择：
第一种方案将状态保留在服务端。提供商将推理轨迹存入自己的数据库，向客户端返回一个无意义的标识符，并在收到下一条消息时查找该标识符。这种方式简单直接，但成本高昂，因为它要求为全球服务的每一位用户的每一段对话都持久化存储状态。
第二种方案是对轨迹进行加密，然后将其返回给客户端，由客户端存储并在每次后续请求中一并发送。这种情况下，提供商无需存储任何内容。
OpenAI、Anthropic 和 Google 等服务商选择了第二种方案。机密性防止竞争对手读取推理痕迹，完整性阻止篡改后的痕迹被送回，无状态则省去了存储开销。可以看出，前两项是安全目标，第三项是成本目标。
信封结构
那么，实际发回给客户端的区块里到底装了什么？
它由一串 Base64 文本组成——这是一种用普通字母和数字表示二进制数据的方式，确保数据能在 JSON 中安全传输。解码后，它就是一个 AEAD 信封。AEAD（带关联数据的认证加密）同时完成两件事：隐藏内容并证明内容未被篡改。其中的关联数据部分包含额外字段，这些字段保持可读，但同样受到防篡改保护。
信封携带一个头部，具体内容因服务商而异，可能包括模型名称、区块类型、版本号和密钥标识符。此外还有 nonce（一次性随机值），用于每次加密时生成看起来不同的输出，以及认证标签和密文。承载所有这些内容的字段在 Anthropic 称为 signature，在 OpenAI 称为 encrypted_content，在 Google 称为 thinkingSignature。
这里的认证机制证明内容来自服务商且后续未被修改，模型名称和版本号也包含在该证明范围内。然而，生成该区块的账户及其所属对话完全不在认证字段之内。需要说明的是，由于没有任何服务商公开过该方案的技术细节，研究人员的这一判断主要基于可观察的行为推断。现有证据指向整个生态系统中使用的单一全局密钥。
轨迹兼容性
如果经过认证的字段不包含任何来源信息，那么一个有效的块在任何地方都能保持有效。研究人员描述了这种情况的三种形态，限制一个比一个宽松：
跨会话兼容：块可以乱序重放，早前会话中的块也能在新会话中使用。这使得编辑对话历史、裁剪冗长会话以适配上下文窗口成为可能。
跨用户兼容：一个账户生成的块，换成另一个账户提交也能被接受。
跨模型兼容：一个模型的块能被另一个模型接受，这为对话中途切换模型、自动路由提供了支持。
研究人员测试了 2026 年 7 月所有可用的来源与目标组合，部分发现如下：
Claude 几乎接受所有组合，唯一的例外是 Fable 5——它的块只有 Fable 5 自己接受。
GPT 按代际划分：GPT-5.6 系列接受所有更早代际的块，而老模型只接受自己这一代的。
Gemini 接受所有代际之间的所有组合。
提取方法
跨模型兼容性之所以重要，是因为同一模型家族内部的防护并不均衡。
Claude Opus 4.8、GPT-5.6 Sol 这类旗舰模型都接受过反蒸馏训练，目的是防止自身推理过程被泄露。这种防护隐藏在输入和输出过滤器之后，专门检查逐字匹配。但同一家族中的小模型，比如 Claude Haiku 4.5 和 GPT-5.6 Luna，为成本和速度做了优化，接受的这类训练要少得多。也就是说，跨模型兼容意味着小模型会接受大模型生成的块。
信息提取方法正是利用了这道训练上的缺口。具体过程如下：
- 向强模型提出一个问题，其回复包含一个明文答案和一个加密的推理块。
- 丢弃该答案，保留推理块。
- 随后，在同一系列中开启与一个较弱模型的新一轮对话。
- 将该推理块作为前置上下文输入，并请求其将附带的推理转录出来。
- 较弱模型以明文形式输出了强模型的推理过程。
换句话说，强
