Google Cloud 高層倡「安全內建於 AI」，自家平台卻浮現完全相反的開發者惡夢

2026 年 5 月，Google Cloud 營運長暨安全產品總裁 Francis de Souza 在洛杉磯的一場活動中，對正擁抱 AI 的企業傳遞了一項明確訊息：安全、治理與可稽核性，必須在 AI 平台設計的第一天就內建其中。他強調「安全不是事後再拼湊補上的東西」，並力勸企業採取「平台思維」，將這些控制措施原生嵌入 。他特別點出了「影子 AI」——員工在缺乏組織監管下擅自使用消費級工具——以及不斷擴大的攻擊面，包括模型、數據管線和提示詞 。

然而就在同一個星期，多份獨立報導相繼揭露了 de Souza 所警示的那種「事後補強式安全失效」事件，而且就發生在 Google 自家的 Gemini API 平台上。這位高層的公開指引，與一線開發者的親身經歷之間，出現了巨大的落差，正好說明了企業在 AI 安全上面臨的現實挑戰。

未授權 API 使用與五位數的驚人帳單

使用 Gemini API 的開發者，通報了一波 API 金鑰遭入侵的事件，導致在幾分鐘內產生巨額的未授權費用。在 Google 自家的開發者論壇上，有用戶記錄了一筆高達 861,344 盧比（約 10,300 美元）的爭議費用，追查後發現流量來自一組由 Firebase 自動配置的 Android API 金鑰——這組金鑰從未被預期用來存取 Gemini，卻在專案啟用 Generative Language API 時，默默地變成了一組有效的憑證 。另一名開發者則通報，一組在 2022 年就外洩的客戶端金鑰，為他帶來了一張 4,368 美元的帳單 。

在一則被廣為引用的案例中，一位 Google Cloud 客戶的帳戶，因帳單容量自動升級，在幾分鐘內就被扣了 17,000 美元 。《The Register》詳細報導了多位客戶因外洩的 API 金鑰，而收到使用昂貴 AI 推論工作負載所產生的五位數帳單，並指出 Google 是在該媒體進行詢問後，才對受害者進行補償 。一位開發者告訴《The Register》，他對於 Google 會在未經明確同意的情況下，自動升級帳單級距的政策感到「措手不及」 。

問題的規模遠不止於少數幾件個案。報導指出，過去只產生小額月費的帳戶，突然因為高成本的 AI 模型而出現急遽的費用飆升，自動化系統甚至將支出上限提高到 100,000 美元，使得未授權的使用能在違背用戶預設預算上限的情況下持續進行 。

金鑰撤銷的延遲：長達 23 分鐘的黃金攻擊窗

若 API 金鑰遭入侵，標準的安全回應程序就是立刻將其撤銷。但安全公司 Aikido 在 2026 年 5 月發表的研究指出，即便開發者已刪除遭入侵的 Google API 金鑰，攻擊者最長仍能在長達 23 分鐘的時間內繼續使用它 。研究人員證實，從刪除動作啟動後，驗證功能在這整整 23 分鐘內都是成功的，中位數時間約為 16 分鐘 。

此一時間差的存在，是因為金鑰的刪除動作並非在 Google 所有的基礎設施上同步生效，而是逐步傳播的 。對於一個正在瘋狂燒錢呼叫付費 API 的自動化攻擊者來說，23 分鐘足以造成可觀的財務損失。這項發現直接牴觸了安全控制措施應在觸發時立即生效的基本原則——而這正是任何處理帳單事件的平台，都應當滿足的基本期待。

會覆寫使用者上限的自動帳單級距升級

或許最根本的結構性問題，在於 Google Gemini API 計費級距的設計方式。該系統根據付款紀錄，自動升級用量級距：第 1 級上限為每月 250 美元，第 2 級為 2,000 美元，第 3 級則在 20,000 美元至超過 100,000 美元之間 。使用者可能會因為累積消費與帳戶存在時間增長而自動升級，且在 2026 年還調降了升級的資格門檻 。

更關鍵的是，《The Register》報導指出，即便在補償了幾位備受矚目的受害者之後，Google 仍表示將堅守其自動擴展用戶消費限額的政策 。這意味著一個註冊時以為擁有 250 美元上限的使用者，可能會在未經明確同意或充分預警的情況下，暴露在高出一個數量級的費用風險中。

Google 確實在 2026 年 3 月推出了「專案花費上限」（Project Spend Caps），作為對公眾強烈反彈的直接回應。此功能讓開發者可以在 AI Studio 中，針對個別專案設定 Gemini API 的每月美元花費上限 。然而，這項補救措施附帶一個重大但書：約 10 分鐘的強制執行延遲，而使用者對該延遲期間產生的任何費用仍負有財務責任 。對於每分鐘處理數千次 API 呼叫的應用程式來說，10 分鐘不受限的帳單意味著實質的財務曝險。

對企業導入 AI 的啟示

de Souza 的指引與 Google 自家平台表現之間的脫節，正好點出了企業在導入 AI 時所面臨的更深層挑戰。這位高層的建議——從一開始就嵌入安全與治理、避免影子 AI、要求可稽核性——固然穩健且必要。但正如 TechCrunch 在報導這場矛盾時所下的註解：「每個人都在即時摸索 AI 安全——就連 Google 也不例外」。

對於正在 AI 平台上建構的組織而言，Gemini API 的這些事件提供了幾項務實的教訓。首先，API 金鑰管理與憑證衛生仍是最根本的基礎：嵌入在客戶端程式碼中、由 Firebase 等服務自動配置卻未設限制，或是在專案中無限制的金鑰，遲早都會被發現並利用。其次，帳單治理必須被視為一項安全功能。一個有 10 分鐘執行延遲的消費上限，或是會覆寫使用者意圖的自動升級機制，都不算是真正的控制措施。第三，可稽核性不能只靠記錄——它還要求像是憑證撤銷這類的安全動作，必須在供應商的基礎設施中，跨區域地立即且全面生效。

de Souza 曾警告，從最初入侵到攻擊進入下一階段的平均時間，已從 8 小時縮短至 22 秒，這凸顯了情況的急迫性 。當攻擊面擴展到包含模型、數據管線和代理程式時，容錯的空間就大幅縮小了。一個 23 分鐘的金鑰撤銷空窗期，或是在攻擊進行中觸發的自動級距升級，並非無關緊要的不便——它是一個會直接導致財務損失的安全失效。