Google Gemini API密钥泄露事件：一墨西哥小公司48小时被刷8.2万美元，揭露AI时代云安全风险

一家平时每月只花 180 美元 调用 Google 服务的小公司，突然在 48 小时 里被刷出 82,314.44 美元（约 56.98 万元人民币） 账单。这起事件迅速在技术社区发酵，直指云服务商与开发者在人工智能时代面临的共同困境。

最早发帖的是一名 Reddit 用户，他称公司在 2026 年 2 月 11 日至 12 日 之间遭遇 API key 被盗，异常消费几乎全部来自 Gemini 3 Pro Image 和 Gemini 3 Pro Text。

这家位于墨西哥、仅有3名开发者的小公司，在发现异常后立即采取了措施：删除被泄露的密钥、禁用 Gemini API、轮换所有凭据、全面启用双因素认证（2FA）、加固 IAM 策略并提交了支持工单。

然而，他们仍然面临着高额账单是否会被 Google 追缴的巨大不确定性。发帖人表示：“如果 Google 试图强制执行哪怕三分之一的这笔费用，我们公司就会破产。”

这起事件之所以引发广泛共鸣，不只因为金额惊人，更因为从安全研究来看，它可能不是孤例。

规则已变：“旧钥匙”悄然打开了“新门”

安全公司 Truffle Security 在 2026 年 2 月 25 日 披露了一份报告，称他们扫描了数百万个网站后，发现了 2863 个仍然活跃且暴露在公开环境中的 Google API 密钥，而这些密钥在许多情况下仍可被用于访问敏感的 Gemini 服务。

此事的核心痛点在于：过去很长一段时间里，Google 告诉开发者，像 Maps、Firebase 等服务使用的 API 密钥更像一个“项目标识符”，而非需要严格保密的“密钥”。这类密钥可以被安全地嵌入到前端代码中。

例如，在 Google Maps Platform 的官方教程中，API 密钥就被直接放在前端 HTML 的 <script> 标签里：

<script src="https://maps.googleapis.com/maps/api/js?key=API_KEY&libraries=maps"></script>

问题在于，当开发者基于这种认知，将过去用于公开服务的“非秘密”密钥沿用下来，并在同一 Google Cloud 项目中启用 Gemini 后，这把“旧钥匙”就意外地获得了访问高成本、高敏感性的人工智能服务端点的权限。Truffle Security 的总结一针见血：规则变了，但大量开发者并没有得到及时、清晰的提醒。

Google 的 Firebase 文档本身也埋下了混淆的种子：它一方面说 Firebase API 密钥“不是秘密”，另一方面又建议，对于非 Firebase 的 Google Cloud API（尤其是计费服务），应使用单独的、受限制的密钥。然而，在实际开发中，团队很容易形成惯性思维，沿用旧有配置。

对小公司而言：这不是技术事故，而是现金流事故

从受害者描述来看，最令人担忧的并非密钥泄露本身，而是异常消费的失控速度和缺乏平台级保护。

• 48 小时 vs 8.2 万美元：对于一个每月正常账单仅 180 美元的小团队而言，消费激增 455 倍，这完全超出了其风险承受能力。
• 缺乏熔断机制：发帖人质疑，为何没有基于历史消费的自动硬性限额（如 5 倍或 10 倍）？为何在出现极端峰值时没有强制确认或临时冻结机制？
• AI 服务的高成本特性：与传统的 API 调用不同，大模型（尤其是图像生成和长文本处理）的单次调用成本要高得多。恶意攻击者可以在极短时间内制造出毁灭性的账单，这使得传统的“事后发现、手动处理”的应对模式失效。

这场事故刺中的不仅是某个开发者的安全意识，更是许多初创公司最脆弱的现实：他们承受不起一次 AI 接口调用事故。当技术风险直接转化为即时的、巨额的财务风险时，公司的生存便岌岌可危。

Google 的回应与平台责任的边界

面对外界的广泛质疑，Google 已经采取了一些措施。在 Gemini API 的官方排障文档中，Google 承认识别到一个问题：部分 API 密钥可能已被公开暴露。作为应对，Google 表示已开始主动封禁已知泄露的密钥，并引导用户在 AI Studio 中检查密钥状态。

同时，Google 建议受影响的用户提交账单支持申请。他们还表示，未来通过 AI Studio 创建的新密钥，将默认只限于 Gemini 和 AI Studio 使用，以减少跨服务混用的风险。

这些动作表明，Google 没有将问题简单归咎于“用户保管不善”。但更深层次的拷问依然存在：为何平台不能在事前提供更强大的保护？为何旧密钥的权限变更没有更醒目的提示？为何高额消费没有默认的阈值和熔断机制？

本质上，提供强大 AI 能力的平台正在继承传统云基础设施的定位，但与之匹配的风险管控“护栏”尚未完全建立。Truffle Security 的报告指出了一个更广泛的隐忧：这种“公开标识符悄然获得敏感权限”的模式，可能不只存在于 Google 的生态中。随着各平台竞相将生成式 AI 能力集成到现有产品和服务里，历史上遗留的各种令牌、密钥和配置文件，都可能在不经意间变成新的攻击面。

这次 Gemini API 密钥事件如同一记警钟，提醒所有开发者和企业，在拥抱 AI 带来的效率革命时，必须重新审视和加固自身在 云平台 上的安全配置与管理策略。对于如何平衡创新便利性与安全责任，欢迎到 云栈社区 的相关板块与更多开发者交流探讨。