I recently had the chance to speak with Francis de Souza, Google Cloud’s COO, backstage at an event in Los Angeles. Surrounded by the noise of the crowd, de Souza—who speaks with the calm, deliberate tone of a university professor—offered practical guidance for companies navigating today’s AI security landscape. “There’ll be a transition period,” he noted, “and then I think we get to this better place.”

While he wasn’t specifically discussing Google at that moment, it’s evident that even the tech giant is still working through challenges. De Souza’s core message echoed what security professionals have long urged executives to embrace, now made critical by AI: security cannot be an afterthought. “As companies embark on this AI journey, they need to take a platform approach,” he explained. “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 specifically warned about “shadow AI”—employees using consumer tools without organizational oversight—and argued that companies must 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.”

EMBED_PLACEHOLDER_0

Notably, he wasn’t simply pitching Google Cloud. When I pointed out that his advice sounded like a Google advertisement, he pushed back. Google, he said, is committed to a multicloud approach, and he argued that companies believing they operate on a single cloud almost certainly don’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 highlighted that the threat landscape has shifted so fundamentally that older 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 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 often goes overlooked: AI agents moving through a company’s internal systems can uncover forgotten data repositories that haven’t been touched 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 solution, 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.”

EMBED_PLACEHOLDER_1

But even as AI takes on more defensive work, the people qualified to oversee it remain scarce—and the vulnerabilities AI itself introduces 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. This brings us back to the platform providers themselves. Over the past several weeks, a series of reports have documented a wave of Google Cloud developers hit with five-figure bills following unauthorized API calls to Gemini models—services many 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. Isuru Fonseka, a Sydney-based developer, woke up to charges of roughly AUD $17,000 despite believing he had a $250 spending cap in place. Neither knew 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 initial report was published. Still, Google stated it has no plans to change its automatic tier-upgrade policy, saying it prioritizes preventing service outages over enforcing users’ stated budget preferences.

EMBED_PLACEHOLDER_2

In the meantime, there’s the separate question of what happens when a developer tries to shut things down. One report detailed 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 noted 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 observed 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 what the platforms are prescribing and how fast they are themselves adapting, and it’s good to be aware of this, too.