[HN] €54k spike in 13h from unrestricted Firebase browser key accessing Gemin…

那張 €54k 的帳單我去年其實就看過草稿版。2024 年 6 月我把 Firebase Auth 接進報價系統時 Google 默默把 Gemini scope 綁到同一顆 AIza key 上，那時我就跟朋友說「總有一天有人會為此破產」。只是沒想到賬單來得這麼徹底：13 小時燒掉 54000 歐，預算警報延遲 3 小時，看到信號時已經沉沒 28k

最讓人挫折的不是錢——而是 Google 那句「valid usage」。十年來他們一直教育大家「瀏覽器 key 不是秘密」，現在一句話把責任推給開發者。我不會說這是故意的，但把新 API 的收費開關直接綁到舊 key 上，怎麼看都是很算計的決定

我兩條自動產線（Next.js+Vercel 的爬蟲發布、CrewAI 影片工廠）全跑 GCP。出事的隔天我用腳本把 17 顆 AIza key 全部加上 service 白名單 + 每小時 1 USD 的硬預算。聽起來保險，但也增加維護成本：每次要開新功能就得回去改 IAM，踩出來的痛點就是流程變得比以前笨重兩倍

更難搞的是 Truffle Security 的掃描結果：他們找到 3000 顆公開網站的 AIza key，現在都能打 Gemini，連 Google 內部測試站也中招。這說明問題不在單一開發者，而是整個生態被迫為官方的權限擴張買單

想聽大家的經驗：你們是怎麼處理「前端 key + AI scope」的預算防線？除了 referrer 和硬預算，還有什麼不會讓上下文斷層的做法？