AI API 金鑰治理檢查表：專案隔離、花費上限、稽核——給資安負責人
給資安/IT 主管的 AI API 金鑰治理檢查表：12 條原則涵蓋隔離、花費上限、輪替、稽核與資料保留，每條說明為什麼重要，並誠實標出目前需要自建的部分。
為什麼 AI API 金鑰需要專門的治理框架
傳統的 API 金鑰管理思維，套在 AI API 上常常不夠用——原因是 AI API 金鑰通常直接綁著一筆會持續燒錢的額度，外洩造成的損失不是「資料被看到」，而是「帳單直接失控」。這份檢查表不是理論清單，每一條都附上「為什麼重要」跟「實際上該怎麼做」，並且誠實標出哪些是現成工具能幫你做的、哪些還是要靠公司自己的流程。
檢查表
1. 原廠金鑰不落地部署平台
為什麼：原廠 API 金鑰通常是無上限的——一旦外洩，攻擊者能造成的損失沒有天花板，只能等你發現帳單異常才能止血。
怎麼做：不要把 OpenAI、Anthropic 這類原廠金鑰直接放進 Zeabur、Vercel 之類的部署平台環境變數。改用中繼層（如 BazaarLink）發的金鑰，原廠金鑰只保留在中繼層帳號設定裡一份。
2. 每個專案、每個環境用獨立金鑰
為什麼：共用同一把金鑰，代表一個環境出事，全部專案的額度都曝險，事後也難以從帳單反推是哪裡出的問題。
BazaarLink 現況：金鑰建立時可以個別命名（name 欄位），每把金鑰獨立管理、獨立撤銷，不互相影響。
3. 每把金鑰都要有花費上限與重置週期
為什麼：這是外洩發生後唯一能把最大損失鎖死的機制——沒有上限的金鑰，外洩的代價是無上限帳單。
BazaarLink 現況：建立金鑰時可設定 limit（美元花費上限）與 limit_reset（每日／每週／每月重置）。
4. 設定到期日，定期輪替
為什麼：長期不換的金鑰，暴露的時間視窗越長，風險累積越高——尤其是外包、測試環境或已經離職員工曾接觸過的金鑰。
BazaarLink 現況：金鑰支援 expires_at 到期日欄位。建議做法是搭配公司內部排程，定期（例如每季）重新產生正式環境的金鑰。
5. 最小權限：管理權限跟呼叫權限分開
為什麼：如果同一把金鑰既能改設定又能呼叫模型燒錢，外洩的殺傷力是雙重的。
BazaarLink 現況：金鑰分「管理型」與「一般」兩種類型——管理型金鑰能建立/修改/撤銷其他金鑰，但不能直接呼叫模型；一般金鑰能呼叫模型，但不能管理其他金鑰。兩種權限天生分離。
6. 用量異常自動告警
為什麼：花費上限是「事後止血」，異常告警是「提早發現」——理想狀況是金鑰接近上限或用量突然暴增時，負責人能主動收到通知，而不是等月底對帳才發現。
BazaarLink 現況（誠實標註）：目前沒有找到面向客戶的自動推播告警機制——用量查詢是自助式的（透過 Dashboard 或 API），需要主動去查，不是系統主動通知你。如果這條對你的組織很重要，建議先用排程腳本定期呼叫用量查詢 API 自行做告警，而不是假設系統會主動通知你。
7. 每個關鍵操作都留稽核軌跡
為什麼：金鑰被誰改過、額度被誰調過、誰登入過系統——這些紀錄是事後追查與問責的基礎，沒有稽核軌跡，出事了也查不出是誰做的。
BazaarLink 現況：登入、額度調整、金鑰變更等關鍵操作均留稽核軌跡，記錄操作者、時間、來源 IP。
8. 稽核紀錄要能匯出，供法遵審查
為什麼：稽核軌跡如果只能在系統裡看、不能匯出，遇到外部稽核或法遵審查時會很麻煩。
BazaarLink 現況：稽核紀錄支援匯出，可供法遵審查使用。
9. 人員異動時，金鑰要能被回收
為什麼：離職或轉調的員工，如果曾經接觸過某把金鑰，這把金鑰就該被視為需要重新評估的風險——不撤銷等於留一個沒人在管的後門。
BazaarLink 現況（誠實標註）：金鑰支援手動撤銷（DELETE），但沒有找到跟公司 HR 系統自動串接的離職回收流程。這部分建議把「金鑰盤點與撤銷」寫進公司既有的離職／專案結案 SOP，用人工流程補上系統沒有自動化的部分。
10. 供應商的資料處理條款要白紙黑字
為什麼：AI API 處理的往往是公司內部或客戶的實際內容，資料會不會被留存、會不會被拿去訓練模型，不能只是口頭承諾。
BazaarLink 現況：服務條款明確載明中繼層本身零資料保留——不記錄、不儲存、不檢視 API Prompt 或模型回應內容，只記錄計費所需的元資料（模型名稱、Token 數量、時間戳記），不會用於訓練任何模型。但要注意：這只涵蓋中繼層本身，你實際選用的上游模型供應商（OpenAI、Anthropic、Google 等）依其自身政策處理請求，部分供應商可能保留輸入輸出並用於訓練或改進——這部分要另外查閱該供應商當下的條款，不能假設「中繼層零保留」等於「全部供應商都零保留」。
11. 組織層級的多層預算與緊急煞車
為什麼：單一金鑰的花費上限管的是「一把金鑰」，但如果公司有多個團隊、多個專案同時在用，還需要一個組織層級的總預算控制，避免所有金鑰加總起來還是失控。
BazaarLink 現況：企業方案提供組織層級的多層預算管控與緊急煞車機制，搭配前面提到的金鑰層級稽核，形成兩層防護。
12. 定期實測故障轉移機制
為什麼：多模型自動容錯（failover）的價值在於「供應商出狀況時系統還能運作」，但如果從來沒實測過，你不會知道它在真正需要的時候到底有沒有用。
BazaarLink 現況：支援自動容錯（目前為 Beta）——主要模型的供應商發生 5xx 錯誤、逾時或限流時，可自動改用指定的備援模型重試。建議正式依賴這個機制前，先自行測試驗證行為符合你的服務等級要求，畢竟目前還是 Beta 狀態。
結語
這份清單裡，有幾條是工具本身就能幫你做到的（隔離、上限、稽核、資料保留條款），也有幾條老實說目前還是要靠公司自己的流程補上（主動告警、離職自動回收）。治理不是「買了工具就自動安全」，而是把工具能做的部分用足、把工具做不到的部分寫進公司自己的 SOP——這份檢查表的用意，就是幫你分清楚哪些是哪些。
FAQ
AI API 金鑰跟一般 API 金鑰的治理差在哪？
AI API 金鑰直接綁著會持續燒錢的額度，外洩的損失不是「資料被看到」而是「帳單失控」；所以花費上限、獨立金鑰、到期輪替這些控制比一般 API 更重要。
金鑰接近上限時系統會主動通知我嗎？
目前沒有面向客戶的自動推播告警，用量查詢是自助式（Dashboard 或 API）。若這條對你很重要，建議用排程腳本定期呼叫用量查詢 API 自行告警。
員工離職，金鑰會自動回收嗎？
金鑰支援手動撤銷（DELETE），但沒有與 HR 系統自動串接的離職回收流程；建議把金鑰盤點與撤銷寫進公司既有的離職／專案結案 SOP。
管理型金鑰和一般金鑰差在哪？
管理型金鑰能建立／修改／撤銷其他金鑰但不能呼叫模型；一般金鑰能呼叫模型但不能管理其他金鑰。兩種權限天生分離，符合最小權限原則。