Google Cloud COO Francis de Souza on AI Security and Platform Challenges

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. 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. 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.