OpenAI 的蒸馏攻防战，在 10 月 1 日迎来了尴尬的第二回合。据 The Decoder 当天报道，公司前一天刚官宣处置了一起大规模模型蒸馏攻击，独立研究者同一天就发布研究更新，称同样的窃取手法在微软 Azure 上依然有效——连最新发布的 GPT-6 Astra 的推理内容，都能被逐字"偷"出来。
事情的起因是 OpenAI 在 9 月 30 日发布的官方博客《Disrupting a coordinated model-distillation campaign》。公司披露，从 7 月 1 日起，有团伙用数万次精心构造的请求，试图从模型中提取被隐藏的内部推理；7 月 24 日至 25 日达到高峰，两天内出现 16,000 次带提取特征的请求，来自 4,000 多个用户，相关模式覆盖超过 15,000 个账户，并在 7 月 28 日被彻底阻断。OpenAI 把核心团伙归因于月之暗面（Kimi 开发商）相关人士，并在脚注里说明统计的是"尝试次数"，不代表全部得手。处置上，OpenAI 封禁了欺诈账号、收紧注册、堵住了加密推理被重放的通道，还给流式输出加了泄露检测。本站此前报道过这起披露：OpenAI 曝光模型蒸馏攻击：1.6 万次提取请求直指月之暗面。
复测：自家 API 拦住了，Azure 没拦住
戏剧性的是披露的同一天。研究者 Joachim Schaeffer 的团队在 stolen-thoughts.com 上更新了他们的研究《Stealing Reasoning Traces from Proprietary LLM APIs》，标题只有一句："We stole reasoning. Again."（我们又把推理偷出来了。）
他们在 9 月 13 日重新测试了那套手法：在 OpenAI 和 Anthropic 自有 API 上，攻击已被拦下；但在微软 Azure 上，所有试过的 OpenAI 模型——包括新发布的 GPT-6 Astra——以及 Anthropic 到 Sonnet 5 的模型，全部中招，一次尝试就足以逐字提取出推理内容。用 Schaeffer 的话说："同一批模型，换个平台托管，防护就完全不一样。"
更简单的第二条路：给模型一本"记事本"
研究者还公开了第二种更简单的手法，由开发者 Can Bölük 演示：给模型挂一个虚拟"记事本"工具，告诉它把推理写进去，用户随后就能读到写下的内容。这套手法在全部 OpenAI 模型以及 Opus 4.8、Sonnet 5 上都有效，只有 Opus 5、Fable 5 和 Fable 5.1 没有泄露。研究者称，记事本法拿到的输出与解密攻击拿到的高度相似，拿去做蒸馏"一样好用"。
补丁为什么总是慢半拍
时间线解释了尴尬从何而来。GPT-6 Astra 上线第三方平台时，防护一项都没配；OpenAI 直到 9 月 27 日才给 Azure 端点加上防护——距离模型发布过去了好几天。Anthropic 那边，Azure 上的提取在 9 月 28 日之后才无法复现。
研究者把现有修复形容为"零敲碎打、浮于表面"：很多防护只是针对特定请求模式的脆弱匹配，而且从模型厂商落地到云平台，往往要再晚几天。攻击者不需要攻破最强的门，只需要找到防护最弱的那扇窗。
研究者的主张：防护跟不上的云，就别托管推理模型
论文把话说得更重：补丁必须覆盖每一种攻击手法、每一家托管模型的云，否则攻击者永远选最弱的一条路。更进一步，研究者主张，不执行同等防护的云服务商，本就不该被允许托管推理模型——否则敞开的后门等于让出口管制在 API 层面被轻松绕过。
OpenAI 对此的回应是承认：合作方托管的模型需要和自家服务同等的保护，"这项工作尚未完成"。
对实际使用云端推理 API 的企业来说，这件事的启示很具体：你调用的模型安全水位，不取决于模型厂商自己修了多少补丁，而取决于你接入的那朵云跟上了多少。模型越强，推理内容越值钱，想"偷"它的人只会更多——这场攻防，才刚刚进入下半场。
