故事得从2025年11月说起，安全公司Truffle Security通过扫描发现，居然有多达2863个Google的API密钥躺在众多网站上，任何人都能随意拿来使用。虽然这些密钥看起来普通，开头都是固定的“AIza…”格式，原本只是作为公开项目的标识符用于计费或者接入Firebase/Maps服务，并不具备认证功能。然而Google在推出Gemini服务时，悄悄地把“可公开查询”升级成了“可认证访问”，这就给黑客留下了可乘之机。攻击者只需要在搜索引擎里找到一条这样的“AIza”字符串，就能顺藤摸瓜拿到对应的项目ID，进而直接调用Gemini API来跑大模型或者上传文件、缓存数据，所有产生的费用都会算在原账户主人头上。 发现这个问题后，Truffle Security在2025年11月向Google漏洞披露项目提交了报告，结果却被当作“预期行为”给打发了。直到12月1日，研究人员给出了Google自己基础设施上的示例证明漏洞确实存在，这才让情况变得紧迫起来。Google随后紧急修复了问题并索要暴露的密钥清单，但修复工作一直持续到了2月2日才真正完成。 而在这个漏洞爆发之前，有个墨西哥的三人开发团队也深受其害。短短48小时内，他们账户里的8.2万美元（约合314.44美元每小时）就被不明攻击者给刷走了。这个金额简直是天文数字，足足相当于他们公司正常月支出的46,000倍。事后他们在Reddit上发帖求救说自己“处于震惊和恐慌状态”，哪怕删除了密钥、禁用了Gemini服务、轮换了所有凭据并提交了支持工单也无济于事。Google客服回复说这笔费用不能免除，因为按照“共同责任”模式，平台只负责安全管理的这部分工作，用户必须管好自己的工具。开发者无奈地表示如果只收三分之一的费用他们就会破产，语气里满是绝望。 其实这种情况并不罕见。“公开标识符悄悄获得敏感权限”并不是Google一家独有的问题。随着越来越多的组织把AI功能搬到现有平台上，传统凭据的攻击面正在以意想不到的方式扩大。为了避免重蹈覆辙，Truffle Security的Joe Leon在博客中给出了三步自查建议：第一是定期轮换密钥；第二是把密钥加密存储或者放入KMS（Key Management Service）中；第三是实时监控API的使用情况和异常流量。开发者可以用开源工具TruffleHog来扫描代码、CI/CD管道和网络资产查找泄露的API密钥并立即下线。 整件事暴露出了两大问题：一个是格式固定且公开可查的密钥模型在引入新服务时必须重新评估权限边界；另一个是在“共同责任”原则下如果用户缺乏安全意识和预算可能真的会被一次异常调用拖垮。对开发者来说不如事先加固好安全措施；对平台来说当规则被利用导致用户巨额损失时是否应该提供更灵活的补偿机制值得探讨。毕竟安全不是一句“你也有责任”就能推给用户的。