48 小時燒掉 57 萬。。。一次密鑰泄露。。。差點判了一家小公司死刑。。。

一家平時每月只花180 美元調用 Google 服務的小公司，突然在48 小時里被刷出82,314.44 美元（56.98 萬元人民幣）賬單。

最早發帖的是一名 Reddit 用戶，他稱公司在2026 年 2 月 11 日至 12 日之間遭遇 API key 被盜，異常消費幾乎全部來自Gemini 3 Pro Image和Gemini 3 Pro Text。

這家公司位于墨西哥、只有 3 名開發者，已在刪除密鑰、輪換憑據并提交工單后，仍面臨高額費用是否會被追繳的不確定性。

這起事件之所以迅速引發共鳴，不只是因為金額驚人，更因為它看上去并不是一樁孤立事故。

安全公司 Truffle Security 在2026 年 2 月 25 日披露稱，他們掃描了數百萬個網站后，發現2863 個仍然活躍的 Google API keys已暴露在公開環境中，而這些 key 在不少情況下還能被用于訪問 Gemini。

換句話說，外界擔心的已經不是“某個開發者倒霉中招”，而是大量原本被視為普通項目標識符的 key，隨著 Gemini 接入，突然具備了新的權限與新的風險。

問題不只是泄露，而是“舊鑰匙”悄悄開了新門

這場風波最讓開發者不安的地方，在于很多 Google API key 過去并不被當成傳統意義上的“秘密憑據”。

Truffle Security 直言，Google 多年來一直告訴開發者，像 Maps、Firebase 等場景中的 API key 更像項目標識符，并非真正的 secret；但到了 Gemini 時代，同樣格式、同樣管理方式的 key，卻可能被 Gemini 端點接受，進而訪問更敏感的資源。

Truffle 對此的總結很直接，規則變了，但大量開發者并沒有及時被提醒。

Google 自家的 Firebase 文檔，其實也能解釋為什么很多團隊會形成這種使用習慣。文檔明確寫道，Firebase 服務使用的 API key 通常不需要像秘密信息那樣嚴密保管，甚至可以出現在代碼或配置文件中；但同時，Google 也強調，凡是用于非 Firebase 的 Google Cloud API，尤其是計費型服務，應該使用單獨、受限制的 key。

問題恰恰在這里，不少團隊歷史上留下的是“可以公開放在前端”的 key，而一旦同一項目后來啟用了 Gemini，這把舊鑰匙就可能獲得開發團隊最初并未預期的新用途。

這也是為什么這次事件的行業意義，遠大于一張天價賬單。

它揭示的不是單點失誤，而是云平臺在疊加生成式 AI 能力之后，舊憑據體系、舊開發習慣和新計費接口之間出現了錯位。開發者以為自己還在使用一把“公開標識符”，平臺卻已經讓它在某些場景下變成了“可調用高成本 AI 服務的入口”。

對小公司來說，這不是技術事故，而是現金流事故

從那位開發者的遭遇看，真正令人后背發涼的并不是密鑰泄露本身，而是異常消費失控的速度。

兩天時間，8.2 萬美元，對大廠可能只是需要內部審批的一筆異常支出，但對一家只有 3 個人的小團隊來說，可能就是直接壓垮公司的現金流。

發帖人自己就寫道，如果 Google 強制收取這筆費用，可能會破產。

外界對 Google 的一個核心批評是，為什么在如此極端的調用異常出現時，沒有更強的自動熔斷、凍結或消費保護機制。

這也是 AI API 與傳統云接口最不同的地方。

過去很多 API 被濫用，損失可能主要體現在配額被占、服務變慢，或者產生可控的超額費用；但大模型接口本身是高單價、高彈性的服務，一旦密鑰被盜，損失會被放大得非?？臁?/p>

尤其圖像生成、長文本處理這類調用，本來就比傳統請求更貴，攻擊者根本不需要持續數周，幾小時甚至幾十小時，就足以制造出一家小公司無法承受的賬單。

所以，這件事真正刺中的并不是“某個開發者安全意識不足”，而是很多創業公司最脆弱的現實，他們承受不起一次 AI 接口事故。在生成式 AI 被越來越多產品接入的當下，技術風險已經在直接轉化為財務風險，而財務風險又會反過來決定公司還能不能繼續活下去。

Google 已開始補洞，但更大的問題是責任邊界

面對爭議，Google 目前已經在 Gemini API 官方排障文檔中公開承認：公司識別到一個漏洞，部分 API keys 可能已經公開暴露。為防止數據訪問和未授權費用，Google 表示已開始主動封禁已知泄露的 key，用戶可以在 Google AI Studio 中查看哪些 key 被阻止調用 Gemini；如果因為這一漏洞出現異常賬單，官方建議用戶提交billing support case。同時，Google 還表示，今后通過 AI Studio 新申請的 key，會朝著默認只限 Gemini / AI Studio 使用的方向收緊，以減少跨服務混用的風險。

這說明 Google 至少已經不再把問題簡單歸結為“用戶自己沒保管好密鑰”。

但從外部觀感來看，平臺真正面臨的考題還沒有結束。因為開發者最關心的，不只是事后怎么補救，而是事前為什么沒有更強的保護。

為什么舊 key 的權限變化沒有更醒目的提示，為什么異常調用沒有更主動的攔截，為什么高額消費沒有更默認化的閾值和熔斷機制。

說到底，AI 平臺正在繼承傳統云平臺的基礎設施地位，卻還沒有完全建立起與之匹配的風險護欄。

Truffle Security 在報告里有一句判斷很重要：這種“原本公開的標識符，悄悄獲得敏感權限”的模式，并不只屬于 Google。隨著越來越多平臺把 AI 能力接到舊產品、舊接口和舊項目體系上，歷史遺留的 token、key、配置文件，都可能在開發者沒來得及更新認知之前，先一步變成新的攻擊面。也就是說，Gemini 這次風波只是先把問題捅破了，類似風險未必只存在于 Gemini。

云頭條聲明：如以上內容有誤或侵犯到你公司、機構、單位或個人權益，請聯系我們說明理由，我們會配合，無條件刪除處理。