配額上限才是防線，預算提醒只是紙老虎
預算提醒只會發郵件，配額上限才會拒絕請求。這是 API 安全防護的第一道防線，但大多數開發者沒有配置。
預算提醒不會自動斷電
大多數開發者在設定 API 金鑰時，都會開啟預算提醒（Budget Alert）。心想：有異常消費就會收到郵件通知，應該足夠了。
但這裡有個致命的假設：預算提醒只會發郵件，不會停止 API 呼叫。
如果你的金鑰洩露給攻擊者，他們可以無限制地調用你的 API，直到你看到郵件、反應、登入控制台、手動禁用金鑰。在這段時間差裡，費用已經滾雪球了。預算提醒是被動的監控，不是主動的防護。
真正的防線是配額上限（Quota Cap）。當請求超過上限，API 直接回傳 429（Too Many Requests），拒絕執行。攻擊者再怎麼濫用，也只能燒到你設定的額度，然後被硬生生斷掉。
同一把金鑰，損失可能差 100 倍
這裡涉及一個更深層的架構決策：你選擇哪個層級的 API 配額，直接決定了金鑰洩露時的最大傷害。
免費層通常沒有綁定信用卡，配額限制嚴格。即使金鑰洩露，損失可能是 $0，因為你根本無法超額扣款。
但如果你用的是付費層（比如 Google 的 Tier 2-3），RPM（每分鐘請求數）可能高達數萬。在沒有配額上限的情況下，攻擊者可能在 2-3 小時內燒光你的整月預算。我們說的不是 $100，而是 $10,000-$100,000 級別的損失。
這不只是成本問題。這是你在設計階段就必須做出的風險分層決策。
- 生產環境用哪個層級？
- 這個層級的最大損失上限是多少？
- 我能承受嗎？
- 如果不能，要降級還是加配額限制？
大多數開發者沒有明確回答過這些問題。
配置化防線才是責任共擔的現實
Google 的責任共擔模式很清楚：Google 保護雲端基礎設施，你保護金鑰和配置。
許多團隊在應用層下了功夫——環境變數、密鑰管理服務、輪換機制。這些都對。但他們往往忽視了配額層面的防線。
這是一個「防守深度」的問題。即使金鑰最終還是洩露了，配額上限可以作為最後一道防線。但這道防線需要你主動配置。
Google 不會自動幫你設定。預設狀態下，配額上限往往是「無限」或「很高」。你必須登進控制台，找到配額設定，手動降低上限。
這不是 Google 的疏漏，而是一個設計原則：默認給你充足的空間，安全防線由你決定。
如果你的金鑰只用於內部服務、流量可預測，可以設定一個遠低於峰值的配額上限。比如正常流量是 1000 RPM，就設 1500。超過這個數字，本身就是異常信號。
這樣做的好處：
- 金鑰洩露時，損失被硬上限控制
- 異常流量會立即被拒，你能更快發現問題
- 不需要依賴郵件通知和人工反應時間
一個待驗證的觀察
我懷疑很多費用爆表的事件，其實源於「配置不完整」而非「金鑰被盜」。開發者設定了預算提醒，覺得已經足夠安全，但沒有加配額上限。然後一個 bug、一個意外的流量尖峰、或一個被遺忘的測試環節，就足以造成幾千塊的損失。
這些不是安全問題，是設計問題。但結果是一樣的：你掏錢。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。