这是一篇把可能发生在不熟悉安全的个人开发者身上的事故，隐去专有名词与可识别信息后加以一般化的文章。文中不刊载攻击的复现步骤。目的在于「不重蹈覆辙的防备」与「真的遭遇时的冷静应对」。
- 类型
- 账户冻结（BAN）／API key 被盗、滥用
- 起因
- 被盗的 API key 被第三方滥用
- 判定理由
- 滥用内容被自动判定为『蒸馏（distillation）』政策违规
- 要点
- 即便实际操作的是第三方，被冻结的也是名义持有人的账户
- 预防
- 密钥分离、最小权限、用量告警、依赖 CVE 的机器化监控
- 应对
- 保全证据 → 通过官方表单申诉（用日志证明人类不可能做到）
「停止扣费」≠「应对完成」
止住违规扣费只是让损害不再扩大。堵住泄露路径、并处理以你的名义留下的违规记录，才算真正完成应对。
为什么连受害者都会被冻结
要点在于：平台一方的判断依据是**「在该名义下发生了什么」，而非「是谁操作的」**。在「密钥持有人＝责任人」的前提下，一旦检测到违规模式，账户就会被停用。
什么是『蒸馏（distillation）』
指大量收集强力模型的输出，把这些「输入→输出」配对作为教师数据来训练另一个 AI 模型的行为。多数主流 AI 提供商在条款中禁止用自家输出去打造竞品模型。大量的注释生成与数据标注很容易符合这种模式，是自动执法最易触发的领域。
也就是说会发生什么
对偷盗者而言，别人的 key 就是「随便用的算力资源」。一旦其用途达到违规级别（蒸馏、大量生成数据），名义持有人的账户也会随之被停用。比起被盗本身，被盗之后的用法才是导致冻结的原因——这正是此类事故的难处。
典型征兆（一般化）
在实际案例中，冻结之前往往会先观测到「自己毫无印象的使用」。这里隐去具体数值，但其共通特征如下。
征兆① 用量异常
远超平日预期的用量与账单，在短时间内集中出现。征兆② 内容不符
本人不会用的模型、与本人用途无关的内容、与本人语言不同的处理正在运行。征兆③ 自动化痕迹
极短时间内大量请求集中，且大量输出为空等，呈现出人力不可能造成的分布。结果 账户冻结
数日后，以违反条款（蒸馏等）为由账户被停用。
看到征兆时，别急着下定论，先看原始日志。只要看模型、内容、语言、时间分布，是不是自己的用法一目了然。
预防：拆分 API key，让泄露只影响局部
要防止被封，关键在于：根本不让密钥被盗，或即便被盗也限制它能影响的范围。
按服务分离密钥
设置最小权限与上限
布置用量告警
万一被封：申诉的思路
只要手头握有滥用的客观证据，冷静地提交事实就有可能恢复账户。要点在于用日志证明「这绝非人类操作所能做到」。
保全证据
通过官方表单提交事实
按阶段切换主张
为什么证明「人类不可能做到」会奏效
极短时间内大量请求集中、且大量输出为空——这样的分布，在正常的业务使用中无法解释。使用模式本身的不自然，就是证明「不是我操作的」最强有力的客观证据。
容易犯的错误，与正确的防备
容易犯的错误
- 把一把 key 在多个项目里反复使用
- 没有设置用量上限与异常告警
- grep 没找到密钥就以为安全
- 只停了扣费就当成应对完成
- 情绪化地抗议，却不整理客观证据
正确的防备
- 按服务分离密钥并采用最小权限
- 布置硬/软用量上限与异常告警
- 也要怀疑运行时泄露（RCE、HTTP 头）
- 两件事都做：止住损害，并堵住泄露路径
- 用日志冷静地证明人类不可能做到
本案的结局（这一案例的后续）
在这类事故中，附上日志这种客观证据提出申诉后，账户本身最终得以恢复。另一方面，被滥用的那部分额外退款未能争取到，最终以已经发放的抵扣额度（credit）作结。
这里的主要教训是：即使账户找回来了，被泄露的 key 所产生的费用也回不来。 恢复既费时又费力。所以真正的防御并不在于「被冻结后再去争」，而在于不让密钥泄露、并设置用量上限使泄露的损失不超过上限这样的事前设计。申诉是最后的手段，而非首要的防护。
总之：导致冻结的不是被盗本身，而是被盗之后 key 的用法。用拆分密钥和设置用量上限来预防；万一发生，就保全日志来应对。
延伸阅读
- 术语：什么是 RCE / 什么是 .env / 什么是 CVE
- 对策：跟进 CVE 安全运维