Everyone is navigating AI security in real time — even Google

每个人都在实时应对 AI 安全挑战——包括谷歌

I recently had the opportunity to sit down with Francis de Souza, COO of Google Cloud, backstage at an event in Los Angeles. Amid the din around us, de Souza, who speaks in the calm, measured manner of a university professor, offered useful advice for companies navigating the AI security moment we’re all living through, noting that “there’ll be a transition period, and then I think we get to this better place.” He wasn’t speaking about Google at that moment, but it’s clear that even Google is still figuring things out. 最近，我有机会在洛杉矶的一次活动后台与谷歌云（Google Cloud）首席运营官 Francis de Souza 进行了一次交谈。在周围的嘈杂声中，说话风格冷静、从容如大学教授般的 de Souza，为那些正处于 AI 安全转型期的企业提供了宝贵的建议。他指出：“这会有一个过渡期，之后我认为我们会进入一个更好的阶段。”他当时谈论的并非谷歌本身，但显而易见，即便是谷歌也仍在摸索之中。

De Souza’s core message was one security professionals have been trying to get executives to internalize for years, now made urgent by AI: security can’t be an afterthought. “As companies embark on this AI journey, they need to take a platform approach,” he said. “Security is not something you can bolt on later, and it’s not something you can leave up to employees to do on their own.” He warned specifically about “shadow AI” — employees reaching for consumer tools without organizational oversight — and argued that companies need to demand security, governance, and auditability from their platforms from the start. “There’s no such thing as an AI strategy without a data strategy and a security strategy. They need to go hand in hand.” De Souza 的核心观点是安全专家多年来一直试图让高管们内化的理念，而 AI 的出现使其变得更加紧迫：安全不能是事后补救措施。“当企业踏上 AI 之旅时，他们需要采取平台化的方法，”他说，“安全不是你可以稍后才添加的插件，也不是你可以留给员工自行处理的事情。”他特别警告了“影子 AI”——即员工在没有组织监管的情况下使用消费级工具——并主张企业必须从一开始就要求其平台具备安全性、治理能力和可审计性。“没有数据战略和安全战略，就不存在所谓的 AI 战略。它们必须齐头并进。”

Worth noting: he wasn’t pitching Google Cloud alone. When I observed that his advice sounded like a Google advertisement, he pushed back. Google, he said, is committed to a multicloud approach, and he made the case that companies that think they’re operating on a single cloud almost certainly aren’t. “Even if they pick a single cloud, they’re relying on SaaS applications, there are business partners that may be using different clouds,” he said. “It’s important for companies to have a security posture that is consistent across clouds, across models.” 值得注意的是，他并非仅仅在推销谷歌云。当我指出他的建议听起来像是在为谷歌做广告时，他予以了反驳。他说，谷歌致力于多云战略，并指出那些认为自己只使用单一云服务的公司，几乎可以肯定并非如此。“即使他们选择了一个云平台，他们也依赖于 SaaS 应用，而且业务合作伙伴可能正在使用不同的云，”他说，“对于企业而言，拥有跨云、跨模型的统一安全态势至关重要。”

He also made the case that the threat landscape has changed so fundamentally that old defensive models are too slow. He noted that the average time between an initial breach and the handoff to the next stage of an attack has dropped from eight hours to 22 seconds, and that the attack surface has expanded well beyond the traditional network perimeter. “In addition to your usual estate, you have models now. You have data pipelines used to train the models. You have agents, you have prompts. All of this needs to be protected.” 他还指出，威胁环境已经发生了根本性的变化，旧的防御模型反应太慢。他提到，从最初的入侵到攻击进入下一阶段的平均时间已从 8 小时缩短至 22 秒，且攻击面已远远超出了传统的网络边界。“除了你通常的资产外，现在还有模型。你有用于训练模型的数据管道。你有智能体（agents），你有提示词（prompts）。所有这些都需要受到保护。”

One threat de Souza flagged that doesn’t get enough attention: agents moving through a company’s internal systems can surface forgotten data repositories that nobody has thought about in years. “A lot of organizations have old SharePoint servers [and access controls] they haven’t really updated, but it didn’t matter because nobody really knew where they were. But agents roaming your enterprise will find those data assets and will expose the data on them.” De Souza 强调了一个未得到足够重视的威胁：在公司内部系统中移动的智能体可能会挖掘出多年来无人问津的遗忘数据存储库。“许多组织都有旧的 SharePoint 服务器 [及访问控制]，他们并没有真正更新过，但这以前无关紧要，因为没人知道它们在哪里。但穿梭于你企业内部的智能体将会找到这些数据资产，并暴露其中的数据。”

The answer, in his view, is to meet machine speed with machine speed. “We’re now seeing the emergence of an AI-native, fully agentic defense where organizations can run agents driving their defense,” he said. “Instead of having a human-led defense or even a human in the loop, you can now have humans overseeing a fully agentic defense.” He added that this has become a leadership issue, not just a technology one. “This is a board-level issue and an executive team issue. It’s not just a security team’s issue.” 在他看来，解决之道是以机器的速度应对机器的速度。“我们现在看到了一种 AI 原生、完全智能化的防御系统的出现，组织可以运行智能体来驱动防御，”他说，“与其依靠人工主导的防御，甚至仅仅是人在回路（human in the loop）的防御，你现在可以让人员去监督一个完全自动化的智能防御系统。”他补充说，这已经成为一个领导力问题，而不仅仅是技术问题。“这是董事会层面和执行团队层面的议题，而不仅仅是安全团队的问题。”

But even as AI takes on more of the defensive workload, the people qualified to oversee it are in short supply — and the vulnerabilities that AI itself is introducing are multiplying faster than security teams can address them. “We’re going to need people to deal with the bug-pocalypse,” LinkedIn’s chief information security officer Lea Kissner told the New York Times this week, adding that she doesn’t expect the industry to understand AI security in any sustainable long-term way for at least several years. 然而，即使 AI 承担了更多的防御工作，具备监督能力的人才依然短缺——而且 AI 本身引入的漏洞增加速度远超安全团队的处理能力。“我们需要有人来应对这场‘漏洞末日’（bug-pocalypse），”领英（LinkedIn）首席信息安全官 Lea Kissner 本周告诉《纽约时报》，并补充说，她预计在未来几年内，整个行业都无法以可持续的长期方式真正理解 AI 安全。

Which brings us back to the platform providers themselves. The Register has published a series of reports over the past several weeks documenting a wave of Google Cloud developers hit with five-figure bills following unauthorized API calls to Gemini models — services many of them had never used or intentionally enabled. The cases followed a familiar pattern: API keys originally deployed for Google Maps, placed publicly per Google’s own instructions, had quietly become capable of accessing Gemini after Google expanded their scope without clearly disclosing the change. 这让我们回到了平台提供商本身。《The Register》在过去几周发布了一系列报道，记录了大量谷歌云开发者在未经授权的情况下调用 Gemini 模型 API 后，收到了五位数账单的事件——而这些服务许多开发者从未主动使用或启用过。这些案例遵循着一种熟悉的模式：最初为谷歌地图部署的 API 密钥，按照谷歌自己的说明公开放置，在谷歌扩大了其权限范围且未明确披露该变更后，悄然具备了访问 Gemini 的能力。

Rod Danan, CEO of interview-prep platform Prentus, said his bill hit $10,138 in roughly 30 minutes after attackers exploited his compromised API key. Isuru Fonseka, a Sydney-based developer whose account was similarly compromised, woke up to charges of roughly AUD $17,000 despite believing he had a $250 spending cap in place. What neither knew was that Google’s automated systems had upgraded their billing tiers based on account history, raising their effective ceilings to as high as $100,000 without explicit consent. 面试准备平台 Prentus 的首席执行官 Rod Danan 表示，在攻击者利用他泄露的 API 密钥后，他在大约 30 分钟内收到了 10,138 美元的账单。悉尼开发者 Isuru Fonseka 的账户也遭遇了类似攻击，他醒来时发现账单高达约 17,000 澳元，尽管他认为自己设置了 250 美元的消费上限。他们两人都不知道的是，谷歌的自动化系统根据账户历史记录升级了他们的计费层级，在未经明确同意的情况下，将他们的实际消费上限提高到了 10 万美元。

Google refunded both after The Register published its initial report. Still, Google told The Register it has no plans to change its automatic tier-upgrade policy, saying it prioritizes preventing service outages over enforcing users’ stated budget preferences. In the meantime, there is the separate question of what happens when a developer tries to shut things down. The Register reported this week on research by security firm Aikido finding that even developers who catch a compromised key and immediately delete it may not be safe. According to Aikido’s findings, attackers can apparently continue using that key for up to 23 minutes because Google’s revocation propagates gradually across its infrastructure. 在《The Register》发布初步报道后，谷歌向两人退了款。尽管如此，谷歌告诉《The Register》，它没有计划改变其自动升级层级的政策，称其优先考虑防止服务中断，而非强制执行用户设定的预算偏好。与此同时，还有一个独立的问题：当开发者试图关闭服务时会发生什么？《The Register》本周报道了安全公司 Aikido 的一项研究，发现即使是那些发现密钥被泄露并立即删除的开发者也可能并不安全。根据 Aikido 的发现，攻击者显然可以继续使用该密钥长达 23 分钟，因为谷歌的撤销操作在其基础设施中是逐步传播的。