I recently had the chance to talk with Francis de Souza, COO of Google Cloud, behind the scenes at an event in Los Angeles. Despite the noise around us, de Souza, who speaks with the calmness of a university professor, shared valuable insights for companies dealing with the current AI security challenges. He remarked, “there’ll be a transition period, and then I think we get to this better place.”
While not discussing Google specifically at that moment, it’s evident that even Google is still navigating these complexities.
De Souza’s main point echoed a long-standing message from security professionals: security should not be an afterthought, especially in light of AI’s rise. “As companies embark on this AI journey, they need to take a platform approach,” he stated. “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 cautioned about “shadow AI,” where employees use consumer tools without company oversight, stressing the need for platforms to have built-in security, governance, and auditability from the outset. “There’s no such thing as an AI strategy without a data strategy and a security strategy. They need to go hand in hand.”
Importantly, he wasn’t solely promoting Google Cloud. When it was suggested that his advice resembled a Google pitch, he disagreed. Google, he emphasized, is dedicated to a multicloud strategy. He pointed out that companies that believe they operate on a single cloud usually 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 explained. “It’s important for companies to have a security posture that is consistent across clouds, across models.”
De Souza also highlighted how the threat environment has evolved significantly, rendering old defense models too slow. He noted that the time between an initial breach and the next stage of an attack has plummeted from eight hours to just 22 seconds, and the attack surface now extends far beyond the traditional network boundaries. “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.”
He identified another underappreciated threat: agents within a company’s systems can uncover long-forgotten data repositories. “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.”
His solution is to combat 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 emphasized that this issue is not just technological but also a leadership concern. “This is a board-level issue and an executive team issue. It’s not just a security team’s issue.”
Despite AI taking on more defensive roles, there are not enough qualified individuals to manage it, and AI’s vulnerabilities are increasing faster than security teams can manage. “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, noting that a sustainable long-term understanding of AI security is still some years away.
This brings us back to the platform providers. The Register has reported on numerous Google Cloud developers facing hefty bills after unauthorized API calls to Gemini models — services many hadn’t used or enabled knowingly. These situations arose from API keys initially set up for Google Maps, publicly deployed as per Google’s instructions, which later became capable of accessing Gemini without clear disclosure from Google.
Rod Danan, CEO of the interview-prep platform Prentus, experienced a bill of $10,138 in roughly 30 minutes after attackers exploited his API key. Similarly, Isuru Fonseka, a developer from Sydney, was charged around AUD $17,000 despite believing he had a $250 spending cap. Neither was aware that Google’s automated systems had increased their billing tiers based on account history, extending potential charges up to $100,000 without direct consent.
Google refunded both after The Register’s initial report. However, Google stated it has no intention of altering its automatic tier-upgrade policy, prioritizing service continuity over enforcing user budget preferences.
Meanwhile, there remains the issue of what happens when a developer seeks to terminate usage. The Register reported this week on findings by the security firm Aikido, which revealed that even if developers delete a compromised key immediately, attackers might still use it for up to 23 minutes as Google’s revocation process spreads gradually through its infrastructure. Aikido researcher Joseph Leon noted that during this period, success rates can vary — sometimes over 90% of requests are still authenticated — allowing attackers to potentially exfiltrate files and cached conversation data from Gemini.
Leon also mentioned that Google’s newer credential formats do not have this issue: 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 paper. “Both suggest this is technically solvable for Google API keys, too.” According to Leon, the 23-minute delay is not an engineering limitation but a matter of company priorities.
This context is important when considering de Souza’s advice, which remains valid and crucial. While his points are accurate, there is a noticeable gap between what platforms recommend and their own pace of adaptation. It is essential to recognize this as well.
When you purchase through links in our articles, we may earn a small commission. This doesn’t affect our editorial independence.
