討論 API Key 的安全時，我習慣多往後想一步：如果它已經外洩了，系統會允許對方做多少事？我們多久會發現，又能多快停止？

保護秘密本身很重要，但「不要外洩」不能是唯一一道防線。原先在 Threads 的討論，我用備用柴油的存量作類比：需要有足以維持運作的餘裕，也需要知道餘裕有多大、由誰補充，以及異常消耗時怎麼處理。

先決定這把鑰匙應該開哪些門

一把用來查詢資料的 key，是否同時能修改、刪除或建立新的憑證？測試環境的 key，是否能存取正式資料？不同服務是否共用同一把？

這些問題決定了外洩的影響範圍。依功能與環境拆分權限，也讓後續撤銷比較精確：停止一個有問題的用途，不必同時讓所有服務停擺。OWASP 的秘密管理指引也將最小權限、輪替與撤銷視為秘密生命週期的一部分。

額度要連到能承受的損失

速率限制、每日用量和金額上限，處理的是不同問題。短時間大量呼叫可能先拖垮服務；緩慢但持續的濫用，則可能在沒觸發瞬間速率門檻的情況下累積費用。

我不認為存在一個對所有服務都正確的「平常用量乘幾倍」。原貼文用倍數表達預留餘裕，但真正設定時，至少需要看正常尖峰、批次工作、告警延遲，以及超限後停機的代價。

也要確認供應商的「預算」到底是通知門檻，還是會真正拒絕後續請求的硬上限。帳單介面上的數字，未必等於執行中的攔截機制；這一點必須以使用中的服務文件和測試確認。

以下是我會拿來評估的問題，不是一組可以直接套用的數值：

問題 需要確認的事情
正常尖峰是多少？ 用量資料是否包含月底、活動或批次工作？
多久才會有人處理？ 告警有沒有負責人？非上班時間怎麼辦？
等待處理期間會損失多少？ 計費延遲、並行請求和額度重置是否會擴大損失？
超限之後怎麼運作？ 停止服務、降級或人工核准，各自會影響誰？

發現與撤銷，也要真的做得到

告警應該讓人知道哪個服務、哪把憑證、哪種行為需要處理，同時避免把完整秘密再次寫進日誌或通知。平時就知道如何替換 key、更新依賴服務及確認舊 key 已失效，事件發生時才不需要臨時找人猜。

輪替也不是刪掉原 key 就算結束。若新的 key 被放回同一個洩漏位置，或仍保留原本過大的權限，問題很容易重演。

我希望系統能回答的，是一個具體的損失範圍：這把 key 就算出事，也只能影響哪些資源；超出什麼程度會停止；由誰決定恢復。把這些決定事先做完，才有機會讓一次外洩停留在可處理的事件。