事件概述

OpenAI 在 2026 年 9 月 30 日发布安全公告，披露其近期识别并阻断了一次协同的模型蒸馏行动（coordinated model-distillation campaign），该行动的目标是提取 OpenAI 模型中被保护的推理内容（protected reasoning）。

按照原文的说法，最早观察到的活动出现在 7 月第一周。OpenAI 将这类行为定性为对抗性蒸馏（adversarial distillation），即系统性地、未经授权地使用一个模型的输出或推理，来帮助训练、复现或改进另一个模型。

需要特别注意的是，OpenAI 明确表示攻击者没有攻破加密、没有入侵数据库，也没有直接访问存储的用户对话记录。他们做的是操纵模型交互方式，让受保护的推理以请求方可见的形式被复现出来，并且是以协同化、规模化的方式进行的，违反了服务条款。

OpenAI 在发布前完成了范围与潜在影响调查、部署了自身的缓解措施，并与研究人员和行业伙伴沟通、收集反馈。相关调查与缓解工作仍在继续。

关键技术点

受保护推理是什么

原文对”受保护推理”的定义是：模型处理任务时的内部记录。提取它可能泄露在最终答案中被隐去的信息，并帮助他人复现模型的能力。这也解释了为什么它值得被专门保护——最终输出经过了对齐与安全过滤，而内部推理记录未必保留同样的处理。

观察到的手法

OpenAI 描述的攻击方式相当具体，也颇具”套娃”意味：

  1. 跨对话重放加密推理：操作者尝试把一段对话中的加密推理内容复制出来，然后在另一段对话中要求模型解密并转写这些隐藏的推理内容。
  2. 跨模型与对话压缩漏洞：独立安全研究人员通过负责任披露（responsible disclosure）向 OpenAI 提交了相关的跨模型漏洞与对话压缩（conversation-compaction）漏洞。OpenAI 调查后确认这些攻击路径真实存在，并表示研究人员的发现帮助他们理解了更广泛的攻击类别，加速了缓解工作。

时间线与规模

  • 7 月 1 日：活动开始，初期量级较低。
  • 7 月 24 日和 25 日：出现高流量峰值，16,000 次请求使用了相关的提取模式，来自超过 4,000 个用户。
  • 进一步调查：识别出分布在一个超过 15,000 名用户集群中的相关提示模式活动。
  • 7 月 28 日：该活动被完全阻断。

原文脚注补充说明：这些数字描述的是尝试提取，不一定是成功提取。

OpenAI 强调活动随时间不断演化，这印证了对抗性蒸馏是一个需要分层、自适应防御的更广泛安全挑战。

归因

OpenAI 表示，尚不清楚在相关时间段内观察到的所有操作者是否都来自单一行为体。但他们将其中核心活动集群归因于与 Moonshot AI（Kimi 的开发者） 相关的人员。

采取的措施

OpenAI 的响应是三路并进：

  • 账号与基础设施层面：封禁或限制欺诈账号，强化注册与基础设施控制，扩大对相关网络的监控。
  • 技术层面：强化隐藏推理在用户、工作区、组织、模型家族各层级的保护；关闭了一条允许已持有他人加密推理的人重放并恢复其内容的路径；增加检查以检测并扣留可能暴露推理的流式输出。
  • 生态与伙伴层面：当相关活动经由第三方服务流转时，与这些服务提供商合作识别并阻断涉事账号；通过 Frontier Model Forum 及适当的政府信息共享渠道分享发现。

OpenAI 特别提醒：支持可移植或可重放推理产物的系统，可能面临同类风险。

后续计划

OpenAI 预计随着前沿模型能力提升、以及行为体寻找更廉价的能力模仿路径，对抗性蒸馏尝试会变得更加复杂。其后续工作聚焦三个方向：

  1. 更强的反提取技术保护；
  2. 更好的针对协同行动的检测与执行；
  3. 更深入的跨行业与政府威胁信息共享。

原文还提到两个尚未完成的点：伙伴托管的部署需要与第一方服务同等的保护；工具输出类攻击需要超出普通可见文本范围的检查能力。OpenAI 表示将持续改进工具防御、分类器覆盖、模型拒绝，并把相关控制传播到云合作伙伴。

对数据科学或 AI Agent 落地的意义

这件事对做 Agent 和推理模型应用落地的团队有几个直接触动：

第一，推理链是可被攻击的资产，不再是”附带产物”。 很多团队在构建 Agent 时，会把模型的思考过程、工具调用中间结果、上下文压缩摘要一起持久化，用于调试、记忆和跨会话复用。OpenAI 提到的两个漏洞类型——跨模型漏洞与对话压缩漏洞——恰好命中这两类设计。如果你的系统支持”推理产物可移植/可重放”，就落在原文点名的风险面里。

第二，压缩即攻击面。 长上下文 Agent 普遍依赖对话压缩来控成本。压缩后的摘要如果被当作可信输入在另一条链路上重放，就可能变成提取通道。安全设计需要考虑压缩产物的来源与权限边界，而不只是内容本身。

第三，安全边界要覆盖”非最终输出”。 蒸馏攻击的收益恰恰来自最终输出之外的信息。对应用团队来说，这意味着日志脱敏、推理内容访问控制、跨租户隔离这些工程实践，从合规问题升级为安全基础设施问题。

第四，共享情报是现实需求。 原文明确指出这不是 OpenAI 独有的漏洞，并通过 Frontier Model Forum 向行业同步。对使用多家模型供应商的团队来说，跨供应商的同类风险监测与统一的账号风控策略，会逐渐成为标配。

我的技术点评

这篇公告最值得注意的地方，不在于”又一次越狱”，而在于它把攻击面从输出层推进到了推理层，并且明确区分了”没被攻破的东西”和”被滥用的东西”。OpenAI 反复强调加密没破、数据库没被入侵、用户对话没被直接读取——攻击者利用的是模型自身被设计成”可以看见并复述某些内容”的能力。这本质上是一种能力滥用，而非传统意义的漏洞利用。这类问题的棘手之处在于：防御方很难通过打补丁一次性解决，因为被滥用的功能往往同时是合法功能。

关于规模数字，需要保持清醒。16,000 次请求、4,000 名用户、15,000 人集群，这些数字描述的是尝试行为，原文脚注也明确说明了这一点。把它们读成”成功窃取了 15,000 人的推理数据”是误读。但反过来说，能够观察到如此规模的协同模式，本身也说明提取尝试的门槛已经不高。

归于 Moonshot AI 相关人员的归因，是这篇公告里最具争议性的部分。原文的措辞是有保留的：一方面说”尚不清楚所有操作者是否来自单一行为体”，另一方面将核心集群归因于与 Moonshot AI 相关人员。这种”部分归因”的表述在安全公告中并不罕见，但它显然会被放到地缘与商业竞争的语境下解读。作为技术读者，比较稳妥的做法是把”归因结论”和”技术事实”分开对待：技术事实（攻击手法、时间线、缓解措施）是可验证、可复用的工程信息；归因结论依赖 OpenAI 单方面的调查，原文未说明其证据细节，外部无法独立核实。

从防御思路看，OpenAI 提到的”检测并扣留可能暴露推理的流式输出”是个有意思的方向——它不是拦截请求，而是在响应生成过程中做实时判断。这类防御的代价是可能引入误杀和延迟，如何平衡需要工程上的持续调优。原文也承认工作”尚未完成”，尤其是第三方托管部署和工具输出攻击这两块，说明当前防护存在明确的覆盖缺口。

最后一点观察：这份公告的读者显然不只是安全团队。原文两次点出”支持可移植或可重放推理产物的系统可能面临相关风险”，以及”伙伴托管的部署需要同样的保护”——这是在向整个生态喊话。对于正在构建多模型、多租户 Agent 平台的团队，这句话应当被当成一份待办清单来看。

原文链接