2025 年 6 月，LiteLLM 供應鏈內一個被攻陷的 PyPI 套件，從每月 9,500 萬次套件安裝中竊走 API key。2026 年 3 月，一家公司因為一把沒有支出上限的 API key，一個月燒掉 $500M。之間還有幾十件較小的意外——金鑰被提交進公開 repo、暴露在用戶端程式碼、在 Slack 訊息裡被分享——讓團隊花了數千美元與數週修復。我們的23 個 LLM API 錯誤指南前六項裡有五項是安全失敗——洩漏金鑰、缺預算上限、扁平金鑰架構。
2026 年的 LLM API 安全不是理論。攻擊面是真的。一把單一洩漏金鑰的財務爆炸半徑，以每分鐘美元計算。LLM 應用程式的 OWASP Top 10 編目了最關鍵的風險——這篇文章把十項最可執行的安全基線對應到那些風險。這是 TokSpan 部落格上 API 認證與金鑰管理的權威參考——其他文章連結到這裡取得完整實作細節。
基線 1：集中式機密保險庫
.env 檔裡不放 API key。原始碼裡不放金鑰。Slack、Notion、聊天記錄裡不放金鑰。每把供應商金鑰都住在加密機密保險庫——AWS Secrets Manager、HashiCorp Vault、Azure Key Vault 或 Doppler。
金鑰在執行期注入——絕不在建置時烤進容器映像。帶內嵌憑證的容器映像，在映像離開你的私有 registry 的那一刻就是一組洩漏的憑證。Kubernetes Secrets Store CSI Driver 把機密從你的保險庫同步到 pod，金鑰完全不碰 Kubernetes Secret 物件——普通的 K8s Secrets 對任何有 get secrets RBAC 的人來說都容易被掀開。
最小可行實作： 一個保險庫——自架用 HashiCorp Vault、託管用 Doppler。所有供應商金鑰加密存放。應用程式啟動時透過保險庫 SDK 取金鑰。金鑰絕不出現在設定檔、磁碟上的環境變數或版本控制裡。時間投資與洩漏金鑰的成本成正比——而一把沒預算上限的洩漏 GPT-5.5 金鑰，一個月可以花掉 $500M。
基線 2：有範圍的金鑰架構
「扁平金鑰」反模式——每家供應商一把 API key，所有環境、所有應用程式、所有開發者共用——與稽核準備、成本控制、事故圍堵格格不入。
實作有範圍的階層：
| 範圍 | 用途 | 預算上限 | 模型白名單 |
|---|---|---|---|
| 生產環境（對外客戶） | 即時使用者流量 | $5,000/month | 僅限固定、帶版本的模型 ID |
| 生產環境（內部工具） | 內部儀表板、分析 | $1,000/month | 較廣，但排除實驗模型 |
| Staging | 上線前測試 | $200/month | 生產模型＋評估候選 |
| Development | 實驗 | $50/month | 最廣，附每人上限 |
每個範圍有自己的 API key、模型白名單、預算。好處：歸屬——每個請求都能追溯到特定應用程式與環境。爆炸半徑圍堵——被攻陷的開發金鑰碰不到生產模型或預算。安全輪替——金鑰依範圍、以獨立時程輪替，不用組織級協調部署。
通往有範圍金鑰最簡單的路，是支援虛擬 API key 的平台——為每個環境建立獨立金鑰、帶每把 key 預算與模型限制。供應商帳號不用動。供應商金鑰留在平台保險庫。應用程式用限定在自身需求的短期虛擬金鑰。虛擬 API key、範圍權限、每把 key 預算實際上怎麼運作，見TokSpan 認證文件。
基線 3：代理/閘道層
應用程式不該直接持有供應商 API key。它們用短期、有範圍的虛擬金鑰向閘道認證。閘道持有真正的供應商金鑰、執行模型白名單、套用預算檢查、記錄每個請求、轉發給供應商。
架構： 應用程式——虛擬金鑰——閘道——供應商金鑰——LLM 供應商。
這確保供應商金鑰永遠不會送達瀏覽器、行動 App 或用戶端程式碼。它們絕不出現在應用程式日誌。應用程式的虛擬金鑰被攻陷時，你在閘道撤銷它——供應商金鑰從未被暴露。傳播是逐請求的、效果近乎即時。
閘道可以自架（LiteLLM）或託管（聚合平台）。安全特性類似。營運開銷不同——自架要維護閘道基礎設施；託管平台幫你處理。TokSpan 的安全架構文件化閘道層實際上怎麼實作——金鑰隔離、請求層級稽核日誌、每把 key 預算執行。
基線 4：自動金鑰輪替
時程： 所有供應商金鑰每 90 天——範圍廣的金鑰更頻繁。緊急輪替： 開發者離職、筆電遺失、偵測到暴露——連疑似都算——立即。
藍綠輪替程序： 在供應商生成新金鑰。加進保險庫、放在舊金鑰旁邊。部署——應用程式兩把都拿到。觀察 15–30 分鐘——所有請求用新金鑰成功。在供應商撤銷舊金鑰。因為金鑰選擇由閘道處理，轉換無縫。應用程式永遠不知道金鑰換了。
沒有閘道層，輪替需要在每個用那把 key 的應用程式協調部署——帶停機風險的數小時作業。有閘道，是 30 分鐘、零停機的作業。
基線 5：硬性預算上限
在三個層級設支出限制。供應商儀表板： 最後防線——在源頭設上限，連平台被攻陷都超不過。平台/閘道層級： 營運控制——環境別、應用程式別的上限，在到達供應商前擋住失控支出。每把 key： 歸屬——開發者別、功能別的上限，圍堵暴走迴圈或攻陷金鑰的爆炸半徑。
每個上限的 80% 警示。100% 硬拒絕。那張 $500M 月帳單會發生，是因為某個組織三個層級全都是零上限。一個設定變更就能阻止。
基線 6：最小權限模型白名單
每把 key 只該能存取它需要的模型。生產顧客向金鑰：固定、帶版本的模型 ID——gpt-5.5-2025-06-15，絕不用 gpt-5.5 這個別名。別名會默默升級到可能改變行為的新快照。開發金鑰：實驗用更廣的存取，但絕不能存取未經你使用情境核准的模型。
操作限制：純推理金鑰不該能呼叫微調、管理或帳單端點。預設拒絕立場：新金鑰從零存取開始。模型與操作都要明確授予。
基線 7：CI/CD 機密偵測
在合併前抓住 LLM API key 的決定性掃描。在 Python、JavaScript、Java、C#、Go、.env 檔、YAML 設定、JSON 設定、CI 管線日誌裡偵測 sk-proj-*（OpenAI）、sk-ant-*（Anthropic）及其他供應商金鑰模式。偵測到重大或高信賴機密就擋下合併。把 LLM key 當第零層憑證——和雲端 IAM 憑證同樣嚴重。
基線 8：完整稽核軌跡
每個 API 呼叫都必須能沿這些維度追蹤：使用者 ID、應用程式 ID、環境、模型、供應商、消耗 Token、成本、時間戳、請求 ID、護欄結果。記到集中系統、最少 90 天熱保留——受規管工作負載 1 年冷保留。寫入持久儲存前，先把機密模式（API key、PII）從日誌裡刪掉。
稽核日誌實際上抓到的東西：2026 年 1 月，某 Series A SaaS 公司的開發者在除錯 CI 故障時，誤把一把開發範圍的 API key 提交到公開 GitHub Gist。金鑰在 UTC 凌晨 2:14 洩漏。到早上 6:30，SOC 收到閘道的自動警示——那把 key 的請求量飆了 40 倍。因為每個請求都記錄了使用者 ID、應用程式 ID、模型、Token 數，團隊 11 分鐘就追完完整暴露：4 小時內 37 個請求、全部對著固定版 GPT-4.0 模型、沒有任何一個碰到生產資料或微調端點。有範圍的金鑰和每把 key 的預算上限把損失壓在 $18。沒有那些日誌，團隊會花好幾天重建爆炸半徑——或預設最壞情況、對每個客戶觸發不必要的洩漏揭露。稽核軌跡把一次憑證洩漏變成確認過的「沒出事」。
在 HIPAA 之下，稽核軌跡必須回答：「這天哪些系統存取過 PHI？哪個模型處理的？在哪個 BAA 之下？」沒有使用者層級歸屬的扁平金鑰架構答不了這些問題。帶閘道層級日誌的有範圍金鑰架構可以。
基線 9：PII 刪除與資料隱私
在提示詞離開你的基礎設施前，刪掉個人識別資訊。用閘道層級 PII 偵測——Portkey 的護欄、自訂中介軟體或專用工具。了解每家供應商的資料使用政策：你的方案允許用 API 資料做訓練嗎？有退出機制嗎？機密工作負載用帶合約式資料處理協議的供應商——或透過提供該協議的平台路由。
基線 10：文件化的事故回應
金鑰洩漏時，回應是時間敏感的——沒有預算上限的被攻陷金鑰，每小時能產生數千美元的不當使用。程序： 立即在閘道撤銷金鑰——傳播是逐請求的、效果近乎即時。輪替可能被暴露的供應商金鑰。在供應商儀表板設支出上限當緊急防線。稽核暴露期間該範圍的請求日誌：提示詞裡有什麼資料？有沒有異常活動？補上漏洞——通常是缺一道護欄、過寬的 CORS 來源、或一個沒有明確同意閘門的工具。若涉及 PII 或 PHI，向受影響方揭露。
LLM API 安全成熟度模型
你不需要第一天就全部十條基線。下面的成熟度模型把基線對應到你的組織階段——依「現在一次違規會花你多少錢」來排優先。
基礎（新創/個人開發者）：基線 1、5、7。 集中機密保險庫把金鑰擋在 .env 檔與版本控制之外。供應商儀表板的硬性預算上限防止單一洩漏演變成災難性支出。CI/CD 機密偵測在金鑰進公開 repo 前抓住它們。這三條基線防止最常見的兩種故障模式——被提交的金鑰與無上限的支出。實作時間：Doppler＋供應商儀表板上限＋pre-commit hook，一個下午。
標準（成長團隊/多環境）：基礎＋基線 2、3、4、6。 環境別的有範圍金鑰圍堵爆炸半徑。閘道層確保應用程式永不直接持有供應商金鑰——洩漏的虛擬金鑰什麼都露不出來。自動輪替把金鑰暴露視窗從數月縮到 90 天。模型白名單執行最小權限存取、擋住 staging 金鑰呼叫生產專用模型。只要你有超過一個環境，這些基線就變成必要——每家供應商一把扁平 key，是 API 安全的「沒有 MFA 的 root 帳號」。實作時間：帶託管閘道一週。
企業（受規管/需合規）：標準＋基線 8、9、10。 帶使用者層級歸屬的完整稽核軌跡滿足 HIPAA、SOC 2、ISO 27001 要求——你可以在任何稽核視窗回答「誰在何時、透過哪個模型、存取過哪些資料」。閘道層級 PII 刪除在提示詞離開基礎設施前抹掉機敏資料。文件化且測試過的事故回應 playbook，讓 SOC 在 5 分鐘內執行撤銷-輪替-稽核工作流程——不是 5 小時。這一層，安全不再是功能——是整個 LLM 基礎設施的控制面。
常見問題
LLM API 第一大安全錯誤是什麼？
原始碼或 .env 檔裡的寫死金鑰被提交進版本控制。LiteLLM 供應鏈攻擊從每月 9,500 萬次安裝竊走金鑰——但更常見的向量是簡單地 git push 進公開 repo。用機密保險庫。永遠不寫死。
我真的需要環境別的 API key 嗎？
要。被攻陷的開發金鑰不得授予對生產模型或預算的存取。有範圍的金鑰圍堵爆炸半徑。每家供應商一把扁平 key，是 LLM API 安全的「沒有 MFA 的 root 帳號」。
聚合平台比直連 API 更安全還是更不安全？
實作良好的平台更安全：虛擬金鑰永不暴露供應商憑證、每把 key 預算與白名單內建、稽核軌跡統一、金鑰輪替集中。實作不良的平台更不安全。投入前先評估平台的安全文件。自架需求，LiteLLM 提供相同安全特性、並對基礎設施保有完全控制。
用 LLM API 時怎麼符合 HIPAA？
用帶 BAA 支援的閘道、把每個請求歸屬到使用者與目的的稽核日誌、把 PHI 留在合規基礎設施內的資料落地選項、以及供應商不會拿你的資料訓練的合約保證。直連 API 需要每家供應商各自談 BAA。聚合平台可以把這整合成一份協議。
API key 洩漏了怎麼辦？
立即：在閘道撤銷。輪替供應商金鑰。設支出上限。接著：查稽核日誌確認存取過什麼。補上漏洞。資料若被暴露就揭露。前三步應該 5 分鐘內完成。後三步可能要好幾天。在需要之前就先把程序文件化，就是「事故」與「大災難」的差別。
這裡涵蓋的十條基線，構成 LLM API 安全的一份具體檢查清單。拉遠看，業界浮現一個更廣的模式：安全不再是外掛的功能，而是其他一切運行的基礎。十年前雲端 IAM 發生過同樣的轉變——從合規勾選框變成整個基礎設施的控制面。LLM API 安全正走在同一條軌跡上。把這些基線當基礎架構、而不是上線後稽核項目的團隊，才是能快而不壞——不壞東西、也不壞預算——的團隊。
保護你的 API key——虛擬金鑰、範圍權限、每把 key 預算、統一稽核日誌。十條基線裡有七條預設執行。