2026年上半年，多地开发者和中小团队遇到了同一件怪事：没有订阅任何新服务，项目也很久没动过，谷歌云账单却从几十美元一路飙到数万美元，清一色指向同一个服务——Gemini API。
这些事故的共同点，不是谁新做了什么操作，而是很多年前少做了一步。而这一步，在当年的官方规则里完全合规。
当年，官方说这种 Key 不算机密
如果你做过调用谷歌地图、YouTube 嵌入或网页字体的前端项目，一定见过以 AIza 开头的 Key。它们直接写进网页代码，任何人打开源码就能看到完整内容。这不是开发者不小心——谷歌长期告诉开发者，这类 Key 不属于机密，可以嵌入前端，只要加上“应用限制”、指定哪些域名能调用就够了。超对齐于是过去十年里，大量 AIza Key 被写进网页、公开仓库、教程文档甚至构建日志，这在当时是标准做法。
转折：项目一启用 Gemini，老 Key 悄悄“升级”了
2026年2月，安全公司 Truffle Security 发布研究：同一批 AIza 格式的 Key，在其所属谷歌云项目启用 Generative Language API（Gemini 的服务入口）之后，可能获得访问 Gemini 相关接口的能力——调用模型、读取文件和缓存内容、消耗调用额度，全部费用记在 Key 主人账上。原本为低风险项目生成的 Key，在项目启用 AI 能力后被自动赋予高成本 AI 接口权限，而且这种变更往往没有任何提醒。AI寰宇者
暴露面也不小。Truffle Security 扫描了2025年11月的 Common Crawl 公开网页数据集，发现2863个暴露在公网且仍然有效的谷歌 API Key 存在相关风险，涉及金融机构、安全公司、全球招聘公司，甚至包括谷歌自己的旧公开 Key。超对齐这些 Key 当年被放在公开位置时“只调过地图”，如今它们能做的事已经完全变了。
半年里，一串天价账单
机制被讲清、暴露的 Key 被列出来之后，灰产只剩下动手。
先倒下的是最小的团队。2026年2月，墨西哥一家初创企业每月 AI 支出只有约180美元，因为一个 Gemini API Key 不慎泄露，48小时内被恶意调用高单价模型，账单滚到了57万元人民币。AI寰宇者与之对得上的，是另一个广为流传的版本：一个三人创业团队在开源项目里不小心硬编码了 Gemini API Key，被人扫描到后疯狂调用，48小时内被刷走约56万元人民币，差点破产。知乎两个版本细节互相吻合，大概率是同一起事故。谷歌云的计费是延迟结算，等当事人发现时，欠款已经滚大；虽然谷歌后来免除了部分费用，团队仍然伤筋动骨。
6月6日，Reddit 的 r/googlecloud 板块又出现一个帖子，称 Gemini API 使用量在3小时内飙升，Key 疑似被盗用，账单达到约3.5万美元。超对齐这个自述案例尚未被谷歌或第三方独立确认，但它不是孤立传闻——同一板块下方还能看到一串类似帖子，号称1.5万、5.5万、8.2万美元。
个人开发者同样没能幸免。5月，一位开发者讲述了自己只是在某个第三方平台填写过 Key，随后就被盗刷的经历。他设置的月预算是1500港币，账单却一路刷到2955港币才停。知乎
这些被盗的 Key 去了哪里？路径很短：中转商低成本收 Key，拿去转卖算力，或直接用于模型蒸馏。上面那位开发者后来发现，自己2900港币的消耗被中转商拿去做蒸馏，对方可能只卖了几百块钱。知乎出现在公开仓库、网页源码、教程文档里的 Key，被爬虫抓走是以秒计算的，等主人反应过来，Key 早已转手好几轮。
三个误区，第一个坑的人最多
误区一：设了域名限制就安全了。并不安全。应用限制管的是“从哪调用”，API 限制管的是“能调用什么服务”，两者是独立的两项配置。就算把 Key 的调用来源锁死在自己的域名上，攻击者绕开网页直接调接口，域名白名单形同虚设；而只要没设 API 限制，这把 Key 就能调用项目里已启用的全部服务，包括 Gemini。控制台上，这类 Key 会挂着“不受限制”的警告。
误区二：我的 Key 只调过 Maps，跟 Gemini 无关。Key 能调用什么，不取决于它当年被谁用过，而取决于它所属的项目现在启用了哪些 API、Key 本身设了什么限制。安全公司 CloudQuery 举过一个极端例子：一个2019年部署在网页里的 Maps Key，今天可能让别人访问 Gemini 文件存储、缓存提示词，并把 AI 推理费用记到你的账户上。超对齐你要查的，是项目启用列表里有没有 generativelanguage.googleapis.com。
误区三：设了预算告警，损失大不了有限。预算告警和预算上限是事后机制，不是事前熔断。谷歌之前对这个问题的解释就是，虽然你设置了上限，但我怕你服务断了，不会完全按照这个来。知乎等告警传到你手机上，调用量可能已经冲了好几个小时，再叠加延迟结算，等你反应过来，损失往往已经放大数倍。
四步自查清单
第一步，盘点项目。登录谷歌云控制台，逐个检查哪些项目启用了 generativelanguage.googleapis.com（Generative Language API）。想不起来自己启用过的，更要查——部分教程、模板和 SDK 初始化流程会在你无感知的情况下替你启用。
第二步，交叉核对 Key。对第一步命中的项目，打开凭据页面，逐个检查每把 Key 是否设置了 API 限制。“已启用 Gemini”和“Key 未设 API 限制”的交集，就是你的优先处理名单。
第三步，排查暴露面。检查名单上的 Key 是否出现在前端代码、公开仓库、教程文档或构建日志里。注意：删除 commit 没有用，历史记录还在，爬虫也早已快照过；正确动作是直接在控制台吊销这把 Key。
第四步，轮换加设防。新建 Key 替换旧 Key，新 Key 记得设 API 限制；同时配置预算上限、调用配额、速率限制和异常告警。最后一条同样重要：不要把自己的 Key 填进任何第三方平台。
谁最该先查，接下来盯什么
四类人建议优先动手：调用谷歌系服务（地图、YouTube、字体、翻译等）的前端项目，尤其是老项目；跟着教程试过 Gemini API、或被初始化向导自动启用过的；有公开仓库、教程站点、示例代码的；个人开发者和小团队——延迟结算加软上限，对你们杀伤最大，目前公开的天价账单几乎都发生在小团队身上。
接下来有两件事值得盯。一是谷歌官方是否回应“旧 Key 静默升权”的争议——目前这套机制已被多家安全公司描述，但谷歌尚未把它当成需要修复的缺陷公开承认。二是云厂商会不会把“账单硬上限”做成默认，而不是软告警。在这两件事落地之前，花半小时自查，是当下唯一能用的防线。
