這是一篇把可能發生在不熟悉安全的個人開發者身上的事故，隱去專有名詞與可識別資訊後加以一般化的文章。文中不刊載攻擊的重現步驟。目的在於「不重蹈覆轍的防備」與「真的遭遇時的冷靜因應」。
- 類型
- 帳號凍結（BAN）／API key 被盜、濫用
- 起因
- 被盜的 API key 被第三方濫用
- 判定理由
- 濫用內容被自動判定為『蒸餾（distillation）』政策違規
- 重點
- 即便實際操作的是第三方，被凍結的也是名義持有人的帳號
- 預防
- 金鑰分離、最小權限、用量告警、相依套件 CVE 的機器化監控
- 因應
- 保全證據 → 透過官方表單申訴（用記錄證明人不可能做到）
「停止扣款」≠「因應完成」
止住違規扣款只是讓損害不再擴大。堵住外洩路徑、並處理名義上殘留的違規記錄，才算真正完成因應。
為什麼連受害者都會被凍結
要點在於：平台一方的判斷依據是**「在該名義下發生了什麼」，而非「是誰操作的」**。在「金鑰持有人＝責任人」的前提下，一旦偵測到違規模式，帳號就會被停用。
什麼是『蒸餾（distillation）』
指大量蒐集強力模型的輸出，把這些「輸入→輸出」配對作為教師資料來訓練另一個 AI 模型的行為。多數主流 AI 供應商在條款中禁止用自家輸出去打造競品模型。大量的註解產生與資料標註很容易符合這種模式，是自動執法最易觸發的領域。
也就是說會發生什麼
對偷盜者而言，別人的 key 就是「隨便用的算力資源」。一旦其用途達到違規等級（蒸餾、大量產生資料），名義持有人的帳號也會一起被停用。比起被盜本身，被盜之後的用法才是凍結的原因——這正是此類事故的困難之處。
典型徵兆（一般化）
在實際案例中，凍結之前往往會先觀測到「自己毫無印象的使用」。這裡隱去具體數值，但其共通特徵如下。
徵兆① 用量異常
遠超平日預期的用量與帳單，在短時間內集中出現。徵兆② 內容不符
本人不會用的模型、與本人用途無關的內容、與本人語言不同的處理正在執行。徵兆③ 自動化痕跡
極短時間內大量請求集中，且大量輸出為空等，呈現出人力不可能造成的分布。結果 帳號凍結
數日後，以違反條款（蒸餾等）為由帳號被停用。
看到徵兆時，別急著下定論，先看原始記錄。只要看模型、內容、語言、時間分布，是不是自己的用法一目了然。
預防：分開 API key，讓外洩只影響一處
要防止被凍結，關鍵在於：根本不讓金鑰被盜，或即便被盜也限制它能影響的範圍。
按服務分離金鑰
設定最小權限與上限
布置用量告警
萬一被封：申訴的思路
只要手頭握有濫用的客觀證據，冷靜地提交事實就有機會恢復帳號。重點在於 用記錄證明「這絕非人類操作所能做到」。
保全證據
透過官方表單提交事實
按階段切換主張
為什麼證明「人不可能做到」會奏效
極短時間內大量請求集中、且大量輸出為空——這樣的分布，在正常的業務使用中無法解釋。使用模式本身的不自然，就是證明「不是我操作的」最強而有力的客觀證據。
容易犯的錯誤，與正確的防備
容易犯的錯誤
- 把一把 key 在多個專案裡反覆使用
- 沒有設定用量上限與異常告警
- grep 找不到金鑰就安心地以為「沒外洩」
- 只停了扣款就當成因應完成
- 情緒化地抗議，卻不整理客觀證據
正確的防備
- 按服務分離金鑰並採用最小權限
- 布置硬／軟用量上限與異常告警
- 也要懷疑執行階段外洩（RCE、HTTP 標頭）
- 兩件事都做：止住損害，並堵住外洩路徑
- 用記錄平靜地證明人不可能做到
本案的結局（這一案例的後續）
在這類事故中，附上記錄這種客觀證據提出申訴後，帳號本身最終得以恢復。另一方面，被濫用的那部分額外退款未能爭取到，最終以已經發放的抵扣額度（credit）作結。
這裡的主要教訓是——即使帳號找回來了，被外洩的 key 所產生的費用也回不來。 恢復既費時又費力。所以真正的防禦並不在於「被凍結後再去爭」，而在於不讓金鑰外洩，並設定用量上限，讓外洩造成的損失不超過上限的事前設計。申訴是最後的手段，而非最初的防護。
總結：比起被盜本身，被盜之後的用法才導致凍結。預防靠分開金鑰並設定用量上限；萬一發生，就靠保全記錄來因應。
延伸閱讀
- 術語：什麼是 RCE / 什麼是 .env / 什麼是 CVE
- 對策：跟進 CVE 安全維運