LLM API Key 管理：預算、輪替與更安全的應用程式存取
作者：Nicho
LLM API Key 是一種可授權支出與存取權限的憑證。要妥善管理它，必須回答四個問題：它儲存在哪裡、它能做什麼、它的工作量能消耗多少，以及你能多快撤銷它？
一次成功的首次請求，這四個問題一個都答不了。在原型變成共享應用程式之前，先建立一套 Key 生命週期與存取邊界，讓你不必打開任何人的原始憑證就能說明清楚。
把供應商 Key 留在你的應用程式後方
不要把長效的供應商 API Key 內嵌在瀏覽器 JavaScript、行動應用程式封裝檔或瀏覽器儲存空間中。把密鑰傳送到終端使用者的裝置，等於讓它脫離你伺服器的控管。OpenAI 明確建議將請求導向後端，而不是在用戶端環境中暴露 Key。OpenAI API Key 安全指引
對於傳統的網頁應用程式，請採用這道邊界：
Signed-in user → your authenticated backend → LLM provider
瀏覽器向你的應用程式進行驗證。你的後端選擇允許的模型，並從伺服器端的密鑰儲存空間取出供應商憑證。
但把 Key 移到後端還不夠。未經驗證的代理仍可能讓陌生人花掉你的餘額，卻從未看到密鑰。在轉送工作之前，先強制執行使用者授權、請求大小限制、允許的操作，以及每位使用者的用量控管。不要讓用戶端任意提供的 URL 決定你的後端要把授權標頭送到哪裡。
先區隔工作量，再共用憑證
避免讓生產環境、預備環境、開發者筆電和排程匯入共用同一把 Key。區隔之後，更容易辨識用量，也能在不弄壞其他一切的情況下撤銷單一工作量。
一份實用的起始清冊不含任何原始密鑰：
| 欄位 | 範例 |
|---|---|
| 工作量 | 客服摘要工具 |
| 環境 | 生產環境 |
| 擁有者 | 應用程式團隊 |
| 密鑰參照 | 密鑰管理系統的項目名稱 |
| 預定存取 | 已核准的摘要模型 |
| 檢視觸發條件 | 部署變更或擁有者離職 |
| 撤銷程序 | 內部作業手冊的連結 |
在供應商提供專案或服務帳號邊界時使用它們，而不是只把權限完全相同的 Key 重新命名。舉例來說，OpenAI 的專案文件說明了專案範圍的服務帳號與資源。那是供應商特有的能力，並不保證每個相容的閘道都提供相同的隔離。OpenAI 專案管理
儲存密鑰，但不要不必要地散布它們
優先採用指定的密鑰管理系統，並將存取權限限制在需要它的工作量與操作人員。把擁有權與生命週期中繼資料和憑證值分開記錄。OWASP 建議採用細粒度的存取權，並在建立、輪替、撤銷與到期之間全程管理密鑰。OWASP 密鑰管理速查表
對於小型部署而言，受保護的伺服器環境變數或許是一種串接機制，但並不是完整的安全性策略。檢視誰能讀取部署設定、執行除錯指令，或查看當機報告。診斷連線問題時，絕不要印出完整環境。
讓憑證遠離原始碼檔案、容器映像、螢幕截圖、工單和聊天訊息。在文件中使用經過遮蔽的設定範例。隊友在排解錯誤時，通常需要的是端點、模型、去識別化的錯誤和請求識別碼，而不是 Key 本身。
定義「預算」實際上代表什麼
不要把儀表板上的每個預算都當成立即的硬性支出上限。在依賴某項控管之前，先確認：
- 它會發出警示，還是拒絕額外的請求。
- 它適用於 Key、專案、帳號，還是應用程式使用者。
- 它的重設週期和時區（若適用）。
- 如何處理並行請求和延遲的用量計算。
- 誰會收到警示，以及誰能變更設定。
把未知的事項記錄下來，而不是假設行為對自己有利。即使供應商提供預算功能，仍要保留應用程式端的准入控管和監控。
舉例來說，某個支援應用程式可能只允許其核准的模型、限制輸入大小、限制要求的輸出量，並限制每位客戶的每日操作次數。這些控管各有不同用途：模型限制約束選擇，請求限制約束量，支出控管則約束金錢曝險。沒有任何一項能取代其他項。
設定 cheapaimodel 公布的 Key 控管
cheapaimodel 公開的定價頁面說明了每個 Key 的預算、到期日、模型允許清單和 IP 允許清單。它也指出，Key 的預算不能超過帳號餘額所能支應的金額，而帳號餘額耗盡會導致閘道請求傳回 403。
對於新的串接，請選擇範圍狹窄的模型允許清單，以及適合該工作負載的預算。為臨時性的串接設定到期日。當你的伺服器有已知且穩定的對外位址時，可考慮使用 IP 允許清單；啟用前先將容錯移轉基礎架構納入考量。
這些建議依據的是公布的產品說明，而非對強制執行時機的獨立稽核。不要承諾在並行情況下零超支，也不要將 IP 限制與憑證保密混為一談。設定部署前，請查閱目前的 cheapaimodel 文件。
刻意輪換；外洩時緊急撤銷
對於計畫性的輪換，請採用受控的交接流程：
- 找出所有使用舊憑證的部署和背景工作。
- 建立具有預期限制的替代憑證。
- 透過你平常的部署流程更新密鑰參照或值。
- 確認受影響的工作負載正在使用替代憑證。
- 撤銷舊憑證並記錄完成。
任何重疊都應該是刻意且短暫的。不要因為「以防萬一」就讓舊 Key 無限期保持啟用。到期也需要有負責人：一個即將到期卻沒有續用計畫的憑證，可能演變成原本可避免的服務中斷。
外洩的 Key 則是另一回事。優先處理撤銷與控制損害，而不是保留一段從容的遷移期。檢查用量、找出受影響的部署，並透過核准的機密管道交付替代 Key 來恢復服務。
從最新的 Git commit 刪除外洩的 Key，並不會讓它失效，也不會移除既有的副本。GitHub 的指引將憑證撤銷或輸替排在儲存庫歷史清理之前，並說明為何清理需要協調。GitHub 敏感資料移除指引
讓 Key 的擁有權可實際運作
上線前，請確認有人能回答：這個 Key 由誰擁有、哪個服務使用它、什麼機制能阻止濫用，以及我們要如何停用它？
可管理的串接會有明確的答案。如果答案是「大家都用同一個 Key」，請先修正這個界線，再擴大流量。更安全的 Key 管理，重點不在於巧妙的儲存技巧，而是讓存取範圍保持狹窄、支出清楚可見，且撤銷切實可行。