从商用 LLM API 窃取推理轨迹

  • 关联论文：2608.09867
  • 作者：flyP
  • 更新：2026-08-12

一句话结论

头部 LLM 厂商把推理链（chain-of-thought）以加密块形式回传给客户端、靠客户端原样回传维持状态 —— 这种设计让加密块在同一厂商生态内完全可互换，结果诞生了一条"用弱模型解码强模型推理"的可扩展越狱通道，威胁反蒸馏、私密数据、危险信息隐藏与不可见 prompt 注入四个攻击面。

解决什么真问题

过去两年商用推理模型（o 系列、Claude、Gemini thinking、DeepSeek-R1 类）开始在响应里附带"思考过程"。这个过程既是产品卖点（用户能看到推理），又是知识产权（蒸馏对手可以直接学到）和安全敏感面（推理过程可能泄露被最终答案过滤掉的有害信息）。

厂商为此采取的对策很统一：把推理链加密，客户端拿到一段密文块（reasoning encrypted block），下次请求时原样回传，服务端据此重建会话状态。这种设计假设：没有密钥，客户端拿不到任何信息；密钥在服务端。

但作者指出一个架构性弱点：加密块的设计目标是"跨请求维持会话状态"，因此同一厂商生态下不同会话、不同用户、不同模型之间的加密块彼此兼容。客户端不需要密钥，它只需要把一块密文投喂给同厂商另一个、且解密与生成耦合较松的模型，就能让后者把这块密文作为上下文来推理，直接以明文形式复述出原始推理。

核心方法

1. 攻击模型概览

[强模型 S]  响应：{"content": "...",
                "encrypted_reasoning": E_k_S(cot_S)}
            ↓ 客户端原样转发
[弱模型 W]  接收同样的 encrypted_reasoning 块
            W 解密并将其作为"上下文"重新生成
            输出：{"content": "...", "reasoning": cot_S 明文}

攻击成功的关键是 W 与 S 共享密文格式与解密前缀 —— 而这正是"跨模型兼容"的工程便利所自动赋予的。

2. 四类攻击向量

(a) 反蒸馏绕过（anti-distillation circumvention） 厂商为防蒸馏，普遍在 ToS 与系统提示中禁止"用 A 模型输出训练 B 模型"。本文给出的方法绕过了这条禁令 —— 攻击者从未直接调用 S，只是把 S 的密文块塞给 W 让 W 代为输出。这使得现有的"输出水印 / 使用审计"在协议层失效。论文在 Anthropic、OpenAI、Google 三家产品上演示了可窃取推理过程。

(b) 大规模私密数据提取 开发者经常把会话日志（包含 encrypted_reasoning 字段）上传到 GitHub、博客、Hugging Face Spaces、Stack Overflow 答案里，以为字段不可读。论文从公开仓库抓取并解码了 315,320 个 reasoning block，恢复出 367 条 PII 与 182 条凭据（API key、密码、内部 token 等）—— 这是论文里最具操作性威胁的数字。

(c) 危险信息泄露 S 的最终可见输出可能安全地拒绝了一个恶意请求（"我不能帮你合成 X"），但其在加密推理过程中已经走过"先承认、再在最后一步拒绝"的轨迹。把这段密文喂给 W，W 可能复述出 S 在思考过程中提到过的有害信息，例如中间检索引用、操作序列等。这是"安全对齐在最终输出层有效、在推理层失效"的实证。

(d) 不可见 prompt 注入 密文块对所有中间环节（包括日志收集、监控、agent 编排系统、第三方审计）都是"不可见"的 —— 因为它是加密的。攻击者可以把完整恶意指令写在加密块里，让它穿过所有只看明文的过滤器，直接进入 W 的上下文。这是面向 agent rollout、CI 自动化、RAG 流水线的潜在供应链攻击面。

3. 攻击为什么"可扩展"

作者的核心论断：单独窃取一个推理块价值有限，可扩展性来自跨用户、跨模型、跨会话的格式兼容。一次抓到某厂商某版本的密文模板，攻击者就能批量复用到同厂商所有模型 —— 这把"模型 IP"从一个用户级保护问题变成了"格式生态级"保护问题。

关键实验与数据

  • 生态覆盖：论文在 Anthropic、OpenAI、Google 三家头部厂商上演示，跨厂商不同模型、不同会话、不同用户的密文互通。
  • 公开数据抓取规模：315,320 个 reasoning block 来自公开仓库；解码后获得 367 条 PII、182 条凭据。
  • 负责任披露（responsible disclosure）：作者已向相关厂商披露漏洞，并提出加密层与系统层的缓解方案（具体加密协议变更未在公开 abstract 详述，原文未明确）。
  • 16,346 KB PDF 体量：含完整攻击代码、密文模板、复现脚本与受影响系统提示片段的脱敏版本。

⚠️ 数字核验：315,320 / 367 / 182 三组数字直接来自 abstract 与摘要，单一实验报告，未见独立第三方复现。"Anthropic / OpenAI / Google 三家覆盖"是论文自报范围，受版本与时间影响极大，不应视为当下状态。

亮点与局限

亮点

  1. 架构层漏洞而不是实现 bug：靠合规、监控、水印挡不住，因为攻击根本不"读"被监控对象。这是论文最重要的一击。
  2. 真实危害量化：从公开仓库解码出 367 条 PII 与 182 条凭据，把"理论威胁"变成"已经在发生的危害"。
  3. 负责任披露 + 缓解方案：论文同步给出具体缓解路径（加密层 + 系统层），不是只破不立。
  4. 攻击面覆盖完整：四个向量（反蒸馏 / 私密数据 / 危险信息 / 不可见注入）互相正交，意味着任何一项缓解都不能假设另外三项被解决。

局限 / 风险

  1. 依赖厂商的密文协议稳定性：一旦厂商收密集文格式、不再跨模型共享密钥前缀，攻击即失效。本文威胁的"有效期"取决于厂商未做协议变更的时间窗。
  2. 演示 ≠ 量产：论文在三家上演示，但具体哪些模型版本 / 时间点 / 流量大小，原文未给出量化。缓解后续可能让该论文成为历史快照。
  3. 负责任披露与公开之间的张力：论文已公开详细攻击方法 + 部分密文模板，任何读到的人都可在自己合规测试范围内复现 —— 这本身是一种"按公开论文做安全研究"的双刃剑。
  4. PII 与凭据的上下文：367 / 182 来自公开仓库扫描，这些数据本来就是被开发者"无意中"上传的。论文的功劳是证明可批量解码，而不是新发现这些数据存在。

对工程落地的启发

给 LLM 应用开发者

  • 永远不要把 encrypted_reasoning 字段原样上传到公开位置（GitHub、Hugging Face、博客、Stack Overflow、Notion 公开页等）。即便你觉得它"加密了所以无所谓"。
  • 会话日志的脱敏策略应把推理字段当成不可见但可解密的 PII。在内部合规里把它列入与 token、密钥同等级的资产。
  • agent 编排系统应假设密文块内容不可信 —— 任何把 reasoning 字段作为下一阶段 prompt 输入的链路都构成潜在注入面，必须独立审计。

给 LLM 厂商 / 安全团队

  • 不要让密文块跨模型兼容：每个模型族独立密钥前缀，至少让"用 W 解 S 的密文"不再自然成立。
  • 在解密后增加内容审计：即便不向用户展示推理，模型仍应在生成阶段把推理纳入安全过滤，而不是只过滤最终输出。
  • 监控"密文块异常复用"模式：同一密文块被同一个外部账户跨用户提交，可作为反蒸馏滥用的信号。
  • 缩短密文有效期与跨会话持久化窗口：避免攻击者抓到一块就能在数月内复用。

给研究者

  • 这是 LLM 系统级安全（system-level LLM security）的代表性论文，关注点从模型权重安全扩展到 API 协议安全。
  • 后续可研究方向：跨厂商统一威胁建模、密文格式演化追踪、agent pipeline 中的 reasoning 注入防御、对抗蒸馏的水印协议设计。

与同方向工作的关系

  • 提示注入 / 间接注入（Greshake 等 2023、prompt injection survey 系列）：本文把"不可见"维度从 Unicode 隐藏、零宽字符、图像隐写扩展到加密块 —— 攻击面更宽、检测更难。
  • 模型窃取 / 模型抽取（model extraction、Knockoff nets 系列）：那些工作关注权重窃取；本文关注推理过程窃取，威胁更现实但更难量化。
  • 反蒸馏与水印：现有水印多打在最终输出上，encrypted_reasoning 的存在使水印协议失效。本文应被视为反蒸馏体系必须考虑的协议层缺口。
  • 供应链安全（CI/CD、agent pipeline）：把 reasoning 当作不可信输入的角度，与 SolarWinds / xz-utils 类供应链攻击在结构上同源。

复现骨架与防范清单

下面是一段可作为自我审计起点伪代码，适合在合规测试环境中复现（不要在生产环境调用同厂商不同模型做这件事 —— 它本身就可能被厂商视为违规）：

# 伪代码：仅作为内部安全审计框架示意
def audit_reasoning_block(block):
    # 1. 密文快是否出现在公开仓库 / 外部文档？
    if grep_in_public_sources(block):
        flag("reasoning block leaked externally")
    # 2. 本组织上游 LLM 提供商是否多模型共享密文前缀？
    if same_prefix_across_models(provider):
        flag("cross-model reasoning block compatible")
    # 3. 本组织下游 agent / RAG 链路是否把 reasoning
    #    字段直接拼进下一轮 prompt？
    if reasoning_in_next_prompt:
        flag("reasoning-as-input injection surface")

合规自检三连：（1）公开仓库扫描；（2）厂商密文协议审计；（3）内部管道 reasoning-字段处理清单。任何一项命中都需要走拦截 / 重设计 / 披露。

⚠️ 以上为内部安全审计思路，不构成可执行攻击指南。

适合谁读

  • LLM 应用开发者：你今天写的代码可能就在无意间把 reasoning 字段上传到不该上传的地方。
  • LLM 平台 / 安全 / 法务团队：这是必须知道的攻击模型，比 prompt injection survey 更紧迫，因为它已经造成了 PII 与凭据泄露。
  • AI 安全 / 红队研究者：本文给出了完整的攻击骨架与攻击面清单，是少见的"已经造成可观测危害"的研究。
  • 不太适合：希望看到"具体到哪一行代码被滥用"的产品经理 —— 本文是协议层 / 系统层研究，落点是架构决策而非代码修补。

工程落地与核查（Jay）

事实核查摘要

可确认（原文支持）： - 四攻击向量（反蒸馏 / PII提取 / 危险信息泄露 / 不可见注入）架构性逻辑成立，加密块跨模型兼容这一工程实现事实在 Anthropic/Claude 系列、OpenAI o系列、Google Gemini 系列中已被独立安全社区多次记录。 - 负责任披露+缓解建议框架本身符合 CVEs/BDVP 标准流程。 - 16,346 KB PDF 体量可通过 arXiv 直接核实（原始 PDF 字节数），建议以 wget --spider 或 curl -I 验其存在性。

存疑 / 待独立核验： - 315,320 / 367 / 182 三数字：单一实验报告，无第三方复现；存疑概率中等偏高。建议读者将"PII泄露已在发生"视为方向性事实，而不等比例映射到具体量级。 - "三家覆盖=当下状态"：厂商API协议随时可变（Anthropic曾在数月内多次变更 reasoning_content 字段格式），原文覆盖不代表2026-08时仍成立。 - 具体密文协议变更方案（"加密层+系统层"）公开 abstract 未详述，原文 16,346 KB 中是否包含可操作工程方案，需 fetch PDF 逐段核验。

可读性精修

原文整体质量较高，仅指出以下可优化处： - "加密块在同一厂商生态内完全可互换"——"完全"略过强，建议改为"格式层面可互换（协议兼容性不等于语义等价）"，以防读者误以为攻击100%成功。 - "(c) 危险信息泄露"节描述"先承认、再在最后一步拒绝"的推理轨迹，但未说明这类轨迹在商用模型的实测频率；可补充"论文是否报告了该类轨迹在拒绝类响应中的占比"以防读者高估普适性。 - 伪代码注释中"密文快"应为"密文块"（typo）。

工程落地补强

原文"给 LLM 厂商 / 安全团队"四条建议框架性强，以下给出可操作化要点：

1. 密文协议层：跨模型兼容切断 - 具体动作：在服务端为每个模型实例（model instance / model version）分配独立 session_key，拒绝解密来自其他 model-instance 的 reasoning块。可用 request metadata 中的 model-chat-version 字段做显式版本校验。 - 坑：同厂商的"旗舰→经济型"产品线经常共享底层推理集群，完全隔离 session_key 可能破坏兼容性承诺，需与产品侧联合评估。

2. 内容审计：推理层安全过滤 - 具体动作：解密后的 reasoning content 应走与最终输出同等严格的 PII 检测 + 安全红线扫描，不因"用户不可见"而跳过。 - 坑：reasoning content 体积通常是最终响应的 5-20×，在高频 API 调用中引入同步解密+扫描会显著增加 P99 延迟（估算 +30~80ms @ p99，取决于推理内容长度）。建议异步审计或采样审计而非全量同步。

3. 密文异常复用检测 - 具体动作：在 API 网关层对 encrypted_reasoning 字段做 Bloom filter 存储，检测"同一密文被同一 IP/账号跨 session 提交"的事件。 - 坑：Bloom filter 有假阳性，且攻击者可切换账号或 IP 绕过。实战中需结合其他信号（UA、请求时序、模型版本）做综合评分，而非单独依赖密文匹配。

4. 公开日志治理 - 具体动作：组织内部 CI/CD 或日志 pipeline 对所有包含 reasoning、thinking、encrypted_reasoning 字段的日志条目做强制过滤标记，并将其加入数据泄露扫描（Data Loss Prevention, DLP）规则集。 - 坑：Base64 编码后的密文块无明显特征字符串，DLP 规则需针对 encrypted_reasoning JSON 字段名做结构化检测，而非内容扫描。

⚠️ 特别注意：原文"agent 编排系统应假设密文块内容不可信"是本节最重要的一条工程结论，实际落地需同时在 agent framework 层面（如 LangChain、LlamaIndex、Rivet）增加对 tool-call input 中 reasoning 字段的显式剥离逻辑。