内容来源：https://techcrunch.com/2026/05/24/everyone-is-navigating-ai-security-in-real-time-even-google/

内容总结：

洛杉矶专访谷歌云首席运营官：AI安全不能“事后补漏”，企业需建立平台级防护

在洛杉矶一场活动的后台，谷歌云首席运营官弗朗西斯·德索萨接受了采访。面对当前企业普遍面临的AI安全挑战，他以大学教授般的沉稳语调指出，业界正经历一个过渡期，但最终将走向更安全的境地。

德索萨的核心观点是：安全绝不能成为事后补救措施。他强调，企业在推进AI应用时，必须采取平台化策略。“安全不是事后能‘打补丁’的，也不能完全交给员工自行处理。”他特别警告了“影子AI”的风险——即员工在缺乏组织监管的情况下擅自使用消费级AI工具。他认为，企业应从一开始就要求平台具备安全性、可治理性和可审计性。“没有数据战略和安全战略，就不存在所谓的AI战略，三者必须齐头并进。”

值得注意的是，德索萨并未单纯推销谷歌云。当被问及建议是否带有广告色彩时，他反驳称谷歌致力于多云架构。他指出，即使企业声称只使用单一云服务，实际上也往往依赖SaaS应用或与使用不同云服务的合作伙伴打交道。“企业必须确保跨云、跨模型的安全态势保持一致。”

德索萨还指出，当前的威胁环境已发生根本性变化，传统防御模式反应太慢。从初始入侵到攻击下一阶段交接的平均时间已从8小时骤降至22秒，攻击面也远超传统网络边界。“除了常规资产，你现在还要保护模型、训练数据管道、智能体以及提示词。”他特别提到一个被忽视的威胁：智能体在企业内部系统中移动时，可能会发现被遗忘多年、未更新权限的旧数据存储库，从而将数据暴露。

应对之道在于“以机器速度对抗机器速度”。德索萨认为，AI原生、完全智能化的防御体系正在兴起，企业可部署智能体自主驱动防御，人类则从直接指挥转变为监督角色。他强调这已不仅是技术问题，更是董事会和高管层需要关注的战略议题。

然而，就在AI承担更多防御任务的同时，合格的安全人才极度短缺，而AI自身引入的漏洞增长速度快于安全团队的应对能力。领英首席信息安全官莉亚·基斯纳坦言，业界至少还需要数年才能可持续地理解AI安全问题。

与此同时，一系列关于谷歌云开发者的报告揭示了一个严峻现实：许多开发者因未授权的Gemini模型API调用而收到五位数账单。这些API密钥原本用于谷歌地图，且按谷歌官方说明公开部署，但谷歌在未明确告知的情况下扩大了其权限范围，导致密钥被攻击者利用。一位初创公司CEO在30分钟内账单即达10138美元；另一位悉尼开发者醒来后发现被扣约1.7万澳元，尽管他设定的是250美元上限。两人均不知谷歌自动系统已根据账户历史将其计费等级提升至10万美元，且未获明确同意。

虽然谷歌在事件曝光后退款，但表示不打算更改自动升级计费等级的政策，理由是优先确保服务不中断，而非强制执行用户的预算设定。更糟的是，据安全公司研究，即使开发者发现密钥泄露并立即删除，攻击者仍可在最长23分钟内继续使用该密钥，因为谷歌的撤销操作在基础设施中逐步生效。在此期间，超90%的请求仍能通过认证，攻击者可趁机窃取文件和对话缓存数据。研究员指出，谷歌其他新凭证格式的撤销仅需数秒，说明该问题并非技术瓶颈，而是公司优先级的体现。

这让人在回看德索萨的建议时不得不思考：他提出的原则无疑是正确且应被认真对待的，但平台目前在安全上的实际响应速度与其倡导的理念之间，仍存在值得警惕的差距。

中文翻译：

我近日在洛杉矶一场活动的后台，有机会与谷歌云首席运营官弗朗西斯·德苏萨进行了一次对谈。在周遭的嘈杂声中，德苏萨以大学教授般沉稳而有条理的语调，为正在经历人工智能安全这一历史性时刻的企业提供了宝贵建议。他指出：“会有一个过渡期，然后我相信我们会到达一个更好的境地。”他当时并非在谈论谷歌自身，但显而易见，即便是谷歌也仍在摸索之中。

德苏萨的核心观点，多年来安全专业人士一直试图让企业高管真正内化，而人工智能的崛起使其变得尤为紧迫：安全绝不能事后补救。“企业在开启人工智能之旅时，必须采取平台化的方法，”他说，“安全不是事后可以随意添加的组件，也不能将其完全交由员工自行处理。”他特别警告了“影子人工智能”的风险——即员工在缺乏组织监管的情况下擅自使用消费级工具——并主张企业从一开始就需要要求其平台具备安全性、可治理性与可审计性。“没有数据战略和安全战略，就不存在什么人工智能战略。它们必须齐头并进。”

值得留意的是：他并非仅仅在推广谷歌云。当我指出他的建议听起来像谷歌的广告时，他予以了反驳。他表示，谷歌致力于多云战略，并论证了那些认为自己在单一云上运营的企业几乎肯定并非如此。“即便他们选择了一个单一的云，他们也在依赖SaaS应用程序，而他们的商业伙伴可能正在使用不同的云，”他说，“企业需要在跨云、跨模型的环境中保持一致的安防态势，这一点至关重要。”

他还指出，威胁格局已发生根本性变化，传统的防御模式过于迟缓。他指出，从初始入侵到攻击进入下一阶段的平均时间已从八小时缩短至22秒，并且攻击面已远远超出传统的网络边界。“除了你常规的资产，你现在还有模型。你还有用于训练模型的数据管道。你还有智能体，有提示词。所有这些都需要被保护。”

德苏萨特别提到一个尚未引起足够重视的威胁：在企业内部系统中移动的智能体可能会挖掘出那些被遗忘多年、无人问津的数据存储库。“许多组织拥有陈旧的SharePoint服务器和访问控制，它们很久没有更新，但之前这无所谓，因为没人真正知道它们在哪里。但在企业内游走的智能体会找到这些数据资产，并暴露其中的数据。”

在他看来，解决方案是用机器速度来应对机器速度。“我们现在正看到一种原生人工智能、完全智能体化的防御体系的出现，组织可以运行智能体来驱动其防御，”他说，“不再是人工主导的防御，甚至不限于人机协作，而是由人类来监督一个完全智能体化的防御系统。”他补充道，这已不仅仅是一个技术问题，更是一个领导力问题。“这是一个董事会和执行团队层面的议题，而不仅仅是安全团队的课题。”

然而，即便人工智能承担了越来越多的防御工作，能够胜任监督这些工作的专业人才依然稀缺——而人工智能自身引入的漏洞，其增长速度已远超安全团队的处理能力。“我们将需要人手来处理这场‘漏洞大爆发’，”领英首席信息安全官莉亚·基斯纳本周对《纽约时报》表示，并补充说她预计在未来几年内，整个行业都无法以任何可持续的长期方式真正理解人工智能安全。

这让我们回到了平台提供商本身。过去几周，《The Register》发布了一系列报道，记录了大量谷歌云开发者因向Gemini模型发起未经授权的API调用而收到五位数账单的事件——许多开发者从未使用过或有意启用这些服务。这些案例遵循一个相似的模式：原本为谷歌地图部署的API密钥，按照谷歌自身的说明被公开放置，却在谷歌扩大其使用范围且未明确披露变更后，悄然具备了访问Gemini的能力。

面试准备平台Prentus的首席执行官罗德·达南表示，在攻击者利用他遭泄露的API密钥后，他的账单在大约30分钟内飙升至10,138美元。悉尼开发者伊苏鲁·丰塞卡的账户也遭到类似入侵，尽管他自认为设置了250美元的消费上限，醒来时却发现产生了约1.7万澳元的费用。两人均不知道的是，谷歌的自动化系统根据账户历史记录升级了他们的计费级别，在未经明确同意的情况下，将他们的实际消费上限提高到了高达10万美元。

在《The Register》发布初步报道后，谷歌向两人退还了费用。尽管如此，谷歌告诉《The Register》，它没有计划改变其自动升级级别的政策，并称其优先考虑的是防止服务中断，而非强制执行用户自行设定的预算偏好。

与此同时，另一个独立的问题是，当开发者试图关闭服务时会发生什么。《The Register》本周报道了安全公司Aikido的研究，该研究发现，即使开发者发现密钥泄露并立即删除，也可能并不安全。根据Aikido的调查结果，攻击者似乎可以继续使用该密钥长达23分钟，因为谷歌的撤销操作在其基础设施中需要逐步传播。Aikido研究员约瑟夫·莱昂告诉《The Register》，在此期间，成功率难以预测——某些时段内，超过90%的请求仍能通过认证——攻击者可以利用这段时间从Gemini窃取文件及缓存的对话数据。

莱昂还指出，谷歌自身较新的凭证格式似乎不存在同样的问题：服务账户的API凭证大约在五秒内即可撤销，而Gemini较新的AQ前缀密钥格式则需要大约一分钟。“两者都在谷歌规模下运行，”他在Aikido的相关论文中写道，“这都表明，从技术上讲，谷歌API密钥的问题同样是可以解决的。”简而言之，根据莱昂的说法，这23分钟的空窗期并非工程限制，而是公司对优先级的选择。

在理解德苏萨的建议时，这一点值得深思。他的建议本身是合理的，也应被认真对待。他说的没有错，但目前平台所倡导的原则与其自身调整的速度之间确实存在差距，认识到这一点同样至关重要。

英文来源：

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.
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.”
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.”
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.”
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.”
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.”
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.
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.
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.
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. Aikido researcher Joseph Leon told The Register that during that window, success rates are unpredictable — in some minutes over 90% of requests still authenticated — and attackers can use the time to exfiltrate files and cached conversation data from Gemini.
Leon also noted that Google’s own newer credential formats don’t appear to have the same problem: service account API credentials revoke in about five seconds, and Gemini’s newer AQ-prefixed key format takes about a minute. “Both run at Google scale,” he wrote in Aikido’s related paper. “Both suggest this is technically solvable for Google API keys, too.” In short, according to Leon, the 23-minute window isn’t an engineering constraint but a matter of priorities for the company.
That’s worth considering when reading de Souza’s advice, which is sound and should be taken very seriously. He’s not wrong, but there is currently a gap between the platforms are prescribing and how fast they are themselves adapating, and it’s good to be aware of this, too.