即使是谷歌也难以跟上 ─ AI时代的安全性已成为“以秒为单位”的战斗

即使是Google也进入了“边跑边守”的时代

AI既是提升企业生产力的工具，同时也是安全负责人面临的新攻击面。生成AI、内部代理、学习数据、提示、外部SaaS、多云环境。过去只需关注网络边界、终端、服务器、身份管理的防御对象，如今已扩展到“AI所触及的一切”。

TechCrunch报道了Google Cloud COO Francis de Souza的发言，象征着这种变化。他强调，如果企业要引入AI，安全性不应该是事后添加的，而应该从一开始就融入平台设计。员工擅自使用外部AI工具的“影子AI”、跨多个云的数据管理、可审计性、治理。这些已经不再仅仅是信息系统部门的问题，而是需要管理层和董事会处理的风险。

特别重要的是，AI引入不仅仅是“添加便利的新功能”。当AI代理开始跨越内部系统运行时，可能会挖掘出人们遗忘的旧数据存储、未更新的访问权限、被遗弃的SharePoint或旧业务文件。过去因为“没人发现所以没问题”的数据，可能会被AI一举可视化。换句话说，AI不仅能快速发现攻击者，还能发现企业内部“过去的管理疏漏”。

攻击以“秒”而非“时间”推进

de Souza解释说，从入侵到进入下一个攻击阶段的平均时间已经从过去的几个小时缩短到了秒。这对安全负责人来说意义重大。人类查看警报、确认情况、召集相关人员、判断、手动阻断。期间，攻击已经进入了下一个阶段。

在这种情况下，Google Cloud给出的答案是“AI原生防御”。不是由人类直接操作一切，而是由AI代理进行监控、防御、初步响应，人类进行监督。如果攻击以机器的速度推进，那么防御也必须以机器的速度进行。

这种思路本身是合理的。但同时，也存在一个大的矛盾。要用AI进行防御，AI本身必须是安全的。AI参考的数据、调用AI的API、AI使用的认证信息、管理AI使用费用的计费系统。如果这些基础设施有漏洞，AI防御就不是防御，而是新的风险。

Gemini API密钥问题显示了“旧假设”的崩溃

此次TechCrunch的文章有趣之处在于，不仅介绍了Google Cloud的安全建议，还触及了Google自身面临的问题。特别引人注目的是围绕Gemini API的一系列高额账单问题。

问题的核心在于Google Cloud的API密钥处理。长期以来，在Google Maps和Firebase等服务中，将API密钥嵌入客户端代码并不罕见。对于开发者来说，这并不一定被视为“公开密码”。它被视为可以公开的用于服务识别和计费的密钥。

然而，当像Gemini API这样高昂的AI推理服务在同一项目中启用时，现有的API密钥可能也能用于AI请求。如果这些密钥留在旧网站的JavaScript、公开的代码库或过去的设置中，攻击者可能会找到它们，并向Gemini或图像、视频生成模型发送大量请求，从而给开发者的账单账户带来巨额费用。

这不仅仅是“开发者疏于管理密钥”的问题。因为一些开发者是按照当时的文档和一般惯例使用密钥的。被认为可以公开的标识符，后来变得接近于高额AI服务的认证角色。这就是AI时代安全的难点。昨天还安全的设计，今天因新功能的添加而变得危险。

“上限”本应是上限却不是的信任危机

进一步加剧开发者不信任的是，关于使用上限和计费上限的问题。The Register的报道中介绍了Google Cloud开发者因不当API使用而收到数千到数万美元账单的案例。有的情况下，通常每月几十美元的使用费用在短时间内飙升至超过1万美元，或者本以为设置了250美元的上限，却因账户历史自动提升到更高的使用额度。

Google的理由是，为了避免服务中断，使成长中的客户能够顺利扩大使用。确实，对于流量突然增长的合法服务，僵化的上限可能导致障碍。在AI应用快速增长的时代，自动扩大使用额度在提升开发者体验方面也有好处。

然而，一旦发生不当使用，这种设计就会反向运作。对于攻击者来说，盗取的密钥可以使用得更多。对于用户来说，就会有“本应设置了上限却停不下来”的感觉。社交媒体上最强烈的反应也集中在这一点。开发者们呼吁“需要真正能停止的上限，而不是警报”。

Reddit上蔓延的愤怒和恐惧

在Reddit的r/googlecloud上，关于Gemini API和Google Cloud高额账单的帖子接连不断。一位发帖者表示，运营B2B SaaS的他们，通常每月约50美元的Google Cloud账单因Veo 3和Gemini图像输出令牌而飙升至超过1万美元。本人并未在产品中使用这些服务，并向Google支持投诉不当使用，但最初被告知“无法确认不当的证据”。

另一则帖子中提到，旧的Google Maps用API密钥在启用Gemini API后被滥用，导致约3万6800欧元的账单。在评论中，有人惊讶地表示“这个问题早该被报道，为什么行为还没有改变”，还有人说“Google Cloud控制台变得可怕，持有能产生数万美元的密钥不值得信任”。

一位自称日本小型企业的发帖者也因Gemini API的不当使用面临约12万8000美元的账单风险，甚至提到了破产的可能性。评论中，很多人认为Google应该提供任意的硬性停止机制，即超过一定金额后确保项目或API停止。随着AI编码工具的普及，接触Google Cloud的开发者越来越多，“所有人都能完美保护密钥”的假设不再现实。

Reddit的反应中不仅有愤怒，还有实用的规避措施。建议包括不使用API密钥，转而使用服务账户或更有限的认证方式，组织层面禁用Gemini API，将公开服务和AI使用分为不同项目，务必设置API限制。换句话说，社区在批评Google的同时，也成为了分享自卫措施的平台。

Hacker News上对“设计理念”的批评强烈

在Hacker News上，关于设计理念的讨论尤为显著。在围绕Truffle Security调查的帖子中，Google API密钥长期以来被视为“可以公开的标识符”，但由于Gemini的出现，实际上成为了高额AI使用或数据访问的钥匙，这一点被视为问题。

有评论指出，每个API密钥应该有明确的支出上限，比如10美元、100美元。有人认为OpenAI或OpenRouter等在密钥单元和账户单元上更容易进行支出管理，而Google Cloud的账单警报有延迟，无法真正成为防波堤。

此外，还有批评称“这就像用用户名当密码一样”。当然，将所有责任推给Google过于简单化。Gemini API默认并未对所有项目启用，需要项目所有者启用。因此，项目应分离、限制密钥、保持最小权限的观点也很有力。

然而，整体讨论中，认为AI使“旧的云惯例”变得危险的观点更为强烈。公开前提的密钥、高额AI推理、延迟的计费数据、自动扩展的使用额度。单独看是可以解释的规格，但组合起来对小规模开发者来说是致命的风险。

即使删除密钥也无法结束的“23分钟”问题

Aikido Security的调查进一步引发了不安。根据该公司的验证，即使删除Google API密钥，部分请求仍可能在最多约23分钟内被认证。在大规模分布式系统中，设置更改传播到所有服务器需要时间并不罕见。但对于认证信息的失效，这种延迟直接成为攻击时间。

如果攻击者持有泄露的密钥，即使用户慌忙删除密钥，之后仍可能继续发送大量请求。如果Gemini API有效，不仅会产生费用，还会带来已上传文件或缓存对话内容的访问风险。

这一点接近AI安全的核心。对于传统的云资源，几分钟的延迟可能是可接受的场景。然而，针对AI模型的请求昂贵，数据也高度机密。几分钟足以让攻击者运行大量推理。在AI时代，“最终一致”的认证思路在成本和数据保护方面都很危险。

Google的建议是正确的。因此更值得质疑

这里重要的是，Google Cloud COO的建议本身没有错。AI战略需要数据战略和安全战略，不能放任影子AI。跨越多云、SaaS、外部合作伙伴、内部代理，应该有一致的安全姿态。既然攻击已经达到机器速度，防御也需要利用AI。

问题在于，平台提供商自身能在多大程度上安全地提供执行这些正确建议的基础。如果要求企业“不要事后添加安全性”，那么云端也必须避免“因后期添加AI功能导致现有认证和计费设计变得危险”的情况。

此次事件不仅是Google的问题。这是对所有云提供商、AI平台、SaaS企业的共同警告。当AI功能不断被整合到现有服务中时，过去的设计假设必须重新审视。可以公开的密钥、仅内部使用的密钥、计费上限、数据访问范围、失效处理、审计日志、支持体系。若沿用AI之前的常识，必然会在某处崩溃。

企业和开发者现在应该立即重新审视的事项

从这个问题中获得的实际教训是明确的。首先，将启用AI的项目与用于公开前端、Maps、Firebase等的项目分离。其次，为所有API密钥设置API限制和应用限制，并禁用不必要的API。第三，确认不仅是账单警报，而是真正能停止的支出上限或配额。第四，清点旧网站、旧代码库、旧移动应用中残留的密钥。第五，在AI使用中优先考虑服务账户、OAuth、最小权限的认证设计，而不是API密钥。

而管理层需要将AI引入视为伴随财务风险和信息泄露风险的基础设施变更，而不是“现场的便利工具”。如果一个密钥泄露可能导致数千万规模的账单或机密数据泄露，那么这不仅是CISO和开发团队的主题，也是CFO、法律、管理会议的主题。

AI安全的真正挑战不是“速度差”，而是“责任设计”

AI时代的安全确实在实时化。攻击快，防御也必须快。然而真正的挑战不仅仅是速度。谁承担风险，谁有权停止，什么是默认安全，优先避免障碍的设计还是阻止不当使用的设计。即是“责任设计”被质疑。

即使是Google，也在摸索中度过这个过渡期。因此，其他企业在无防备的情况下推进AI引入是危险的。AI能保护，AI能检测，AI能自动化。在这些期待之前，必须首先检查围绕AI的认证、计费、数据、权限、审计机制。

AI安全不是未来的话题。已经进入了API密钥一把、旧项目一个、延迟警报一封就能左右企业存续的阶段。

来源URL

TechCrunch「Everyone is navigating AI security in real time — even Google」
Google Cloud COO Francis de Souza关于AI安全的发言、影子AI、多云、代理型防御、Gemini API相关问题的提及。
https://techcrunch.com/2026/05/24/everyone-is-navigating-ai-security-in-real-time-even-google/

The Register「Google users fight for refunds as unauthorized API usage bills soar」
Google Cloud/Gemini API密钥滥用导致的高额账单、Rod Danan和Isuru Fonseka的案例、Google的解释。
https://www.theregister.com/ai-ml/2026/05/13/google-users-fight-for-refunds-as-unauthorized-api-usage-bills-soar/5239160

The Register「Google reimburses Register sources who were victims of API fraud」
Google对部分开发者进行了退款，但仍维持自动使用额度扩大的方针。
https://www.theregister.com/devops/2026/05/15/google-reimburses-register-sources-who-were-victims-of-api-fraud/5241429

The Register「Threat hunters find Google API keys still usable 23 minutes after deletion」
API密钥删除后仍可使用最多约23分钟的Aikido调查及其影响。
https://www.theregister.com/devops/2026/05/21/threat-hunters-find-google-api-keys-still-usable-23-minutes-after-deletion/5244504

Aikido Security「Google API keys keep working after you delete them」
Google API密钥删除后的失效延迟、验证方法、Gemini有效时的数据和计费风险。
https://www.aikido.dev/blog/google-api-keys-deletion

Truffle Security「Google API Keys Weren't Secrets. But then Gemini Changed the Rules.」
Google Maps和Firebase等使用的API密钥因Gemini API启用而风险化的结构、公开密钥调查。
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules

Google官方博客