Gemini API密钥被盗，初创团队48小时损失57万面临破产。谷歌“共享责任”模式引争议，API安全风险凸显。
原文标题：Gemini 账户 48 小时被盗刷 57 万，三人创业团队站在破产边缘
原文作者：AI前线
冷月清谈：
怜星夜思：
2、你认为谷歌的“共享责任模式”在这种情况下是否合理？平台应该承担多少责任？
3、从技术角度来看，如何避免类似Gemini API密钥泄露导致的巨额损失？你有什么好的实践建议？
原文内容
“我现在处于震惊和恐慌之中。”
这是帖子的开头。没有铺垫，没有背景说明，只有一句情绪几乎溢出屏幕的自白。
在 Reddit 发帖的人，是一家位于墨西哥的初创公司联合创始人，公司只有三名开发者，规模很小，每月在谷歌云服务上的正常支出大约 180 美元。对他们来说，云账单是一项可控成本，是创业早期可以精确计算的变量。
但 2 月 11 日至 12 日这 48 小时，一切都失控了。
在这两天里，他们的 Google Cloud API 密钥被盗用。具体怎么发生的，他们至今不清楚。“我们不知道是怎么回事，也没有发现明显的错误。”他说。
但账单记录非常清晰：总额 82,314.44 美元（约合人民币 57 万）。几乎全部来自两项服务——Gemini 3 Pro 图像与 Gemini 3 Pro 文本。
180 美元与 82,314 美元之间，是 457 倍的差距。
那一刻，这不再是技术问题，而是生存问题。
他们第一时间采取了所有能想到的补救措施：删除泄露的密钥，禁用 Gemini API，轮换全部凭证，在所有账号上启用双因素认证，收紧身份与访问管理（IAM）权限，并向谷歌提交了支持请求。从操作流程上看，这是一次标准、迅速且完整的安全响应。
但真正让他感到恐慌的，是随后与平台沟通的结果。
根据他的说法，谷歌方面提到了 Google Cloud 的“共享责任模式”——平台负责基础设施安全，用户负责凭证管理。因此，这笔未经授权产生的 API 费用，仍然需要由客户承担。
“这真的让我非常担心。”他写道，“如果谷歌试图强制收取哪怕三分之一的费用，我们公司就会破产。”这不是夸张的修辞。对一家现金流本就紧张、寄希望于产品爆发的三人团队而言，哪怕 2 万多美元的账单，都足以击穿银行账户余额。
他反复强调，他们是一家小公司。这笔账单远远超出了公司的承受能力。
但让他难以理解的，不只是费用归属问题，而是整个系统的风控逻辑。
在他看来，这 82,000 多美元并不是“正常波动”，而是明显的异常滥用行为。48 小时内，从月均 180 美元的基线，暴涨到 8.2 万美元，系统却没有触发任何强制停止机制。
“为什么没有针对灾难性使用异常情况的基本防护措施？”他提出一连串问题——
为什么当使用量达到历史水平的 5 倍或 10 倍时，没有自动硬性停止？
为什么在极端峰值下，不需要强制确认？
为什么在审查期间，没有临时冻结？
为什么没有默认的单 API 消费上限？
这些问题并不带有攻击性，更像是一个技术人员在复盘事故时的困惑。对他来说，API 密钥被盗已经是既成事实，但计费系统为什么允许异常规模在 48 小时内持续放大，是另一层无法理解的风险。
帖子的最后，他向社区求助：有没有人成功申诉过类似情况？有没有减免费用的经验？他甚至向 FBI 提交了网络犯罪报告，希望通过正式渠道记录这次攻击。
截至发帖时，谷歌方面的态度仍然是：除了付款，没有别的选择。
这篇帖子之所以引发大量关注，并不是因为 8 万美元这个数字本身，而是它折射出的结构性焦虑。生成式 AI API 的调用成本远高于传统 Web 服务接口，一旦凭证泄露，高并发调用可以在极短时间内累计巨额费用。对于大企业而言，这或许只是一次可谈判的异常账单；对于小团队而言，却可能是一次致命打击。
“简而言之，”他在帖子中总结，“Gemini API 密钥被盗，48 小时内产生 82,314 美元费用。我们正常月费 180 美元，飙升 457 倍。我们已经采取安全措施，但谷歌以‘共同责任’为由拒绝赔偿。如果坚持收取费用，我们将破产。”
目前尚不清楚这家墨西哥公司的最终结局。是否减免费用、是否达成和解、是否能继续运营，都还是未知数。但可以确定的是，这 48 小时，已经成为他们创业过程中最沉重的一课。
《The Register》援引安全公司 Truffle Security 安全研究员 Joe Leon 的博客内容，进一步揭示了问题的结构性根源。Leon 在 2 月 25 日的文章中写道：“有了有效的密钥，攻击者就可以访问上传的文件、缓存的数据，并将 LLM 使用量计入您的帐户。”
它意味着风险并不局限于“刷调用次数”导致账单飙升，还可能涉及数据访问与缓存内容读取。API Key 不再只是计费通道，而可能成为访问路径。
Joe Leon 在博客中详细解释了为什么谷歌 API 密钥（例如用于地图、Firebase 等服务的密钥）并非秘密这件事在以前没什么问题，但 Gemini 出来后，情况就变了，核心问题到底是什么。
Joe Leon 在博客中提到，Google Cloud 使用单一 API 密钥格式 ( AIza...) 用于两个根本不同的目的：公开身份识别 和 敏感身份验证。
多年来，谷歌一直明确告知开发者，API 密钥可以安全地嵌入客户端代码中。Firebase 自身的安全检查清单也指出，API 密钥并非秘密信息。
注意：这些与用于支持 GCP 的服务帐户 JSON 密钥截然不同。
Google Maps JavaScript 文档还直接指示开发者将密钥直接粘贴到 HTML 中。
这合情合理。这些密钥被设计为用于计费的项目标识符，并且可以通过诸如 HTTP Referer 允许列表之类的（可绕过的）控制措施进一步限制。它们并非设计为身份验证凭据。
但 Gemini 出现后情况变了。
在 Google Cloud 项目中启用 Gemini API（生成式语言 API）时，该项目中现有的 API 密钥（包括网站公共 JavaScript 代码中的密钥）可能会在后台静默访问敏感的 Gemini 端点。
没有任何警告、确认对话框或电子邮件通知。
这就产生了两个截然不同的问题：
-
追溯性权限扩展。比如三年前，您创建了一个 Maps 密钥，并按照 Google 的指示将其嵌入到您网站的源代码中。上个月，您团队的一位开发人员为内部原型启用了 Gemini API。现在，您的公钥已变成 Gemini 凭证。任何抓取该凭证的人都可以访问您上传的文件、缓存的内容，并导致您的 AI 费用飙升。没有人告诉过您这一点。
-
不安全的默认设置。在 Google Cloud 中创建新的 API 密钥时，默认设置为“不受限制”，这意味着它立即对项目中所有已启用的 API（包括 Gemini）都有效。用户界面会显示“未经授权使用”的警告，但这种默认架构完全开放。
结果是：数千个原本作为良性计费 token 部署的 API 密钥现在变成了存在于公共互联网上的 Gemini 实时凭证。
之所以说这是权限提升而不是配置错误，是因为事件发生的顺序。
-
开发者创建了一个 API 密钥并将其嵌入到地图网站中。（此时，该密钥是无害的。）
-
Gemini API 已在同一项目中启用。（现在，同一个密钥可以访问 Gemini 的敏感端点。）
-
开发人员从未被告知密钥的权限在其底层发生了变化。（密钥从公共标识符变为秘密凭证
虽然用户可以限制 Google API 密钥（按 API 服务和应用程序），但漏洞在于不安全的默认设置 (CWE-1188) 和不正确的权限分配 (CWE-269)：
-
隐式信任升级：Google 将敏感权限追溯性地应用于已在公共环境中合法部署的现有密钥（例如，JavaScript 包）。
-
密钥分离不足：安全的 API 设计需要针对不同的环境（公开密钥与私钥）使用不同的密钥。如果对两者都使用同一种密钥格式，系统就容易出现安全漏洞和混乱。
安全默认值失效：通过 GCP API 面板生成的密钥的默认状态允许访问敏感的 Gemini API（假设已启用）。用户在为地图组件创建密钥时，会在不知情的情况下生成具有管理权限的凭据。
那攻击者能做什么？
攻击者访问您的网站，查看页面源代码，并 AIza... 从地图嵌入中复制您的密钥。然后他们运行：
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
403 Forbidden 他们得到的不是 a，而是 200 OK。攻击者由此可以：
-
访问私有数据。`and`/files/ 端点可以 /cachedContents/ 包含上传的数据集、文档和缓存的上下文。项目所有者通过 Gemini API 存储的任何内容均可访问。
-
账单飙升。Gemini API 的使用并非免费。根据具体模型和上下文窗口，攻击者如果滥用 API 调用，可能每天仅一个受害者账户就会产生数千美元的费用。
用完您的配额。这可能会导致您的 Gemini 合法服务完全停止。攻击者根本不会触碰你的基础设施。他们只是从公共网页上窃取密钥。
为了解问题的严重程度， Truffle Security 扫描了 2025 年 11 月的 Common Crawl 数据集，这是一个庞大的（约 700 TiB）网页存档，其中包含从互联网上公开抓取的 HTML、JavaScript 和 CSS 网页。 Truffle Security 团队发现了 2,863 个存在权限提升漏洞的 Google API 密钥。
前端源代码中用于 Google Maps 的示例 Google API 密钥，但也可以访问 Gemini。
Truffle Security 团队指出，这些并非业余爱好者的副业项目。受害者包括大型金融机构、安全公司、全球招聘公司，以及谷歌自身。如果供应商自己的工程团队都无法避免这个陷阱，指望每个开发者都能正确应对是不现实的。
在 Truffle Security 团队提出一系列漏洞及其相关证据后，GCP VDP 团队开始认真对待这个问题。
他们扩展了泄露凭证检测流程，将 Truffle Security 团队报告的密钥纳入其中，从而主动保护真正的谷歌客户免受利用其 Gemini API 密钥的威胁行为者的侵害。他们还承诺修复根本原因，但 Joe Leon 表示他们尚未看到具体成果。
Joe Leon 写道：“构建像谷歌这样规模的软件极其困难，而 Gemini API 沿用了为不同时代设计的密钥管理架构。谷歌已经意识到我们报告的问题，并采取了切实有效的措施。目前尚待解答的问题是：谷歌是否会告知客户其现有密钥存在的安全风险，以及 Gemini 最终是否会采用不同的身份验证架构。”
这位墨西哥开发者的经历，很快在技术社区引发了广泛讨论。围绕责任归属、平台机制以及开发者自身配置问题，观点分化明显。
不少 Reddit 用户对他的处境表示强烈同情。一位网友直言，如果自己遇到这种情况，“恨不得飞到谷歌总部，跪在地上求他们退款。”在这些人看来，对于一家仅有三名成员的小公司而言，8 万多美元的账单几乎等同于“致命打击”。即便技术上存在疏漏，平台也应在极端异常场景下提供更多缓冲或协商空间。
但也有用户将讨论焦点转向机制设计本身。他们指出，Google Cloud 的 API Key 体系确实应该提供更明确、可配置的“硬性消费上限”。一旦触及某个阈值，系统应自动中断服务，而不是仅发送提醒。与此同时，也有人提到技术实现层面的复杂性——云费用往往并非实时结算，而是在产生后 24 小时甚至 36 小时内逐步计入账单。如果计费数据本身存在延迟，那么要做到真正意义上的“即时硬性封顶”，在系统架构上可能并不简单。
还有网友认为谷歌方面没什么错，而是他们自己忽略硬性设置造成的错误。他表示：
“但现在已经有了这些硬性限制设置，我完全不明白楼主为什么还要因为他们糟糕的配置错误而责怪谷歌……至少要承认，没有设定硬性限制是一个巨大的错误。”
在这起 API 账单风波引发广泛讨论后，一位有多年云服务经验的网友给出了相对冷静的分析。
他首先提出一个关键问题：“所谓‘被盗’，究竟是什么意思？”在他看来，这个定义本身至关重要。
“是有人真正入侵了系统、突破防线窃取数据？还是开发者在配置或代码管理过程中无意间泄露了凭证？这两种情况在责任划分与后续处理上完全不同。如果是系统层面的安全入侵，性质更严重；如果是凭证暴露，则更可能被视为配置风险。厘清这一点，是与平台沟通的第一步。”
这位网友还提醒，当事人应检查是否拥有网络安全或技术责任相关的保险。有些公司会为云服务异常账单或安全事件投保，在特定条件下可以申请理赔。虽然这并不能解决根本问题，但在现金流紧张时，可能成为缓冲手段。
还有网友表示，通过权限访问比通过密钥访问要靠谱得多。
“这就是为什么应该通过权限而不是密钥来授予访问权限，以及为什么工作负载身份如此重要的原因。”
参考链接：
https://old.reddit.com/r/googlecloud/comments/1reqtvi/82000_in_48_hours_from_stolen_gemini_api_key_my/
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules
。开玩笑，正经的还是得走正规渠道，收集证据，联系平台，寻求法律帮助。同时，也提醒其他开发者朋友，注意安全防范，避免踩坑。