AI 工具刪了，API 金鑰還活著？先查清楚誰能替你花錢

把 AI 工具解除安裝，畫面乾淨了；但曾經交出去的 API 金鑰，可能仍能在供應商那裡通過驗證。真正該問的不是「我還有沒有用這個工具」，而是「這把金鑰現在還能不能被使用」。

這不是在說每個工具都會外洩，也不是把所有異常帳單都當成攻擊。它提醒的是一個容易漏掉的邊界：本機設定、第三方保存的副本、供應商承認的有效憑證，是不同的東西。以下是一份原創盤點方法，不是任何事件的鑑識結論，也不是特定產品的自動防護功能。

一、刪掉工具，為什麼不等於金鑰失效

API 金鑰可以想成請求服務的憑證。工具讀到它之後，能否成功呼叫，取決於供應商如何驗證、金鑰當時的狀態，以及適用的權限與限制。解除安裝主要改變本機，不能據此推定供應商端已撤銷憑證。

例如 OpenCode 官方 Providers 文件寫明，用 /connect 加入的供應商金鑰會存在本機 ~/.local/share/opencode/auth.json。這只能證明該文件描述的儲存位置，不能延伸成「整個工作流程絕不經過雲端」或「所有外掛都碰不到」。實際還要看你使用的端點、代理服務及額外整合。官方文件

因此，刪掉本機檔案、登出工具或取消連線，都不要直接當作撤銷成功的證據。如果曾經複製到其他裝置、服務或備份，那些副本也不會因為一台電腦刪檔而一起消失。

二、先畫出金鑰走過哪裡，不要先猜誰出事

先回答四件事：誰核發金鑰、誰保存副本、請求送到哪個端點、費用記在哪個專案。看得到熟悉的模型名稱，不代表請求一定直接到原供應商；設定若經過代理或閘道，還有另一層保管與記錄責任。

可先列本機工具、雲端工作區、自動化流程及測試環境。只記金鑰識別名稱、供應商提供的識別碼或可安全辨識的末碼，不把完整金鑰貼到試算表、聊天或截圖裡。這張清單的目的，是找出要更新的連線，不是再製造一份秘密副本。

若無法確認是否經過某個服務，寫「待確認」並找管理者核對；不要因為沒看見用量，就把它寫成未曾持有。一般用量頁也未必能辨識每個實際使用者或每次存取來源。

三、把感覺安全，改成五欄可核對的紀錄

下面是原創教學表，甲、乙、丙均為虛構情境，不代表任何平台發生事故。每欄都要能對應到你自己的設定或管理紀錄。

「已刪掉」只是一個動作，不是完整的結果。至少要說清楚刪的是工具、設定、副本，還是供應商端的金鑰；不知道是哪一個，就還不能把該列標成完成。

四、疑似外洩時，處置順序要看風險

已懷疑金鑰被未授權取得時，優先找有權管理者在供應商端停用或撤銷，並保留必要的時間、識別與用量紀錄。不要為了不中斷服務，讓疑似外洩的舊鑰長時間繼續有效；若涉及重要系統，應把止損及服務中斷的取捨交給負責人。

如果只是例行輪替、沒有疑似外洩跡象，則可先盤點依賴，按照供應商流程建立新鑰、更新必要服務並驗證，再停用舊鑰。這兩種情境不能混成同一套無條件先後順序。

不同平台的按鈕與狀態不相同。Claude API 管理文件列有金鑰的 active、inactive、archived 狀態；這不代表一般使用者都能呼叫管理 API，也不代表其他平台使用相同名稱。本文不提供代操作指令，不要求你把憑證交給 AI。官方狀態定義

五、換完金鑰，還要回查哪些東西

回頭查看供應商允許取得的用量、費用與專案紀錄，找出不熟悉的時段、模型或請求型態。保留時區及查詢範圍，別把帳務延遲當成「撤銷後仍在使用」的證據，也別把暫時沒有新費用當成沒有外洩的證明。

Google Cloud 官方建議對 API 金鑰施加適用限制、移除不再使用的金鑰，並避免將金鑰放在客戶端程式或程式碼倉庫。這些是降低暴露面的做法，不是事故不會發生的保證；限制能力也要依 API 類型確認。官方管理原則

用量告警、預算提醒與真正會擋請求的限制，也應分開核對。Google Cloud 文件明確區分僅告警的預算與適用服務可設定的支出上限；前者不會自動封頂費用。其他供應商也應查當前文件，不要只因為設了提醒，就假定支出一定會被切斷。預算與告警文件

六、最值得留下的，不是新金鑰本身

留下的應該是責任與證據：哪個專案、哪些連線、誰有權處置、舊鑰何時失效、哪些服務確認恢復，以及用量要追查到哪裡。新金鑰本體留在原本核准的秘密管理位置，不要夾在交接文件裡。

下次準備把憑證貼進新的 AI 工具前，先想好退出方式：不用了要到哪裡撤銷、誰會受影響、怎麼知道已經完成。工具可以一鍵移除，授權關係卻需要逐一結清。

你上一次換 AI 工具時，有回頭確認舊金鑰真的失效了嗎？