\n<\/p>\n
I recently had the opportunity to sit down with Francis de Souza, COO of Google Cloud, backstage at an event <\/a>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\u2019re all living through, noting that \u201cthere\u2019ll be a transition period, and then I think we get to this better place.\u201d<\/p>\n He wasn\u2019t speaking about Google at that moment, but it\u2019s clear that even Google is still figuring things out.<\/p>\n De Souza\u2019s core message was one security professionals have been trying to get executives to internalize for years, now made urgent by AI: security can\u2019t be an afterthought. \u201cAs companies embark on this AI journey, they need to take a platform approach,\u201d he said. \u201cSecurity is not something you can bolt on later, and it\u2019s not something you can leave up to employees to do on their own.\u201d He warned specifically about \u201cshadow AI\u201d \u2014 employees reaching for consumer tools without organizational oversight \u2014 and argued that companies need to demand security, governance, and auditability from their platforms from the start. \u201cThere\u2019s no such thing as an AI strategy without a data strategy and a security strategy. They need to go hand in hand.\u201d<\/p>\n Worth noting: he wasn\u2019t 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\u2019re operating on a single cloud almost certainly aren\u2019t. \u201cEven if they pick a single cloud, they\u2019re relying on SaaS applications, there are business partners that may be using different clouds,\u201d he said. \u201cIt\u2019s important for companies to have a security posture that is consistent across clouds, across models.\u201d<\/p>\n 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. \u201cIn 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.\u201d<\/p>\n One threat de Souza flagged that doesn\u2019t get enough attention: agents moving through a company\u2019s internal systems can surface forgotten data repositories that nobody has thought about in years. \u201cA lot of organizations have old SharePoint servers [and access controls] they haven\u2019t really updated, but it didn\u2019t 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.\u201d<\/p>\n The answer, in his view, is to meet machine speed with machine speed. \u201cWe\u2019re now seeing the emergence of an AI-native, fully agentic defense where organizations can run agents driving their defense,\u201d he said. \u201cInstead of having a human-led defense or even a human in the loop, you can now have humans overseeing a fully agentic defense.\u201d He added that this has become a leadership issue, not just a technology one. \u201cThis is a board-level issue and an executive team issue. It\u2019s not just a security team\u2019s issue.\u201d<\/p>\n But even as AI takes on more of the defensive workload, the people qualified to oversee it are in short supply \u2014 and the vulnerabilities that AI itself is introducing are multiplying faster than security teams can address them. \u201cWe\u2019re going to need people to deal with the bug-pocalypse,\u201d LinkedIn\u2019s chief information security officer Lea Kissner told the New York Times<\/a> this week, adding that she doesn\u2019t expect the industry to understand AI security in any sustainable long-term way for at least several years.<\/p>\n 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 \u2014 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\u2019s own instructions, had quietly become capable of accessing Gemini after Google expanded their scope without clearly disclosing the change.<\/p>\n Rod Danan, CEO of interview-prep platform Prentus, said his bill hit $10,138 in roughly 30 minutes<\/a> 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\u2019s automated systems had upgraded their billing tiers based on account history, raising their effective ceilings to as high as $100,000 without explicit consent.<\/p>\n 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\u2019 stated budget preferences.<\/p>\n In the meantime, there is the separate question of what happens when a developer tries to shut things down. The Register reported this week<\/a> 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\u2019s findings, attackers can apparently continue using that key for up to 23 minutes because Google\u2019s revocation propagates gradually across its infrastructure. Aikido researcher Joseph Leon told The Register that during that window, success rates are unpredictable \u2014 in some minutes over 90% of requests still authenticated \u2014 and attackers can use the time to exfiltrate files and cached conversation data from Gemini.<\/p>\n Leon also noted that Google\u2019s own newer credential formats don\u2019t appear to have the same problem: service account API credentials revoke in about five seconds, and Gemini\u2019s newer AQ-prefixed key format takes about a minute. \u201cBoth run at Google scale,\u201d he wrote in Aikido\u2019s related paper. \u201cBoth suggest this is technically solvable for Google API keys, too.\u201d In short, according to Leon, the 23-minute window isn\u2019t an engineering constraint but a matter of priorities for the company.<\/p>\n That\u2019s worth considering when reading de Souza\u2019s advice, which is sound and should be taken very seriously. He\u2019s not wrong, but there is currently a gap between the platforms are prescribing and how fast they are themselves adapating, and it\u2019s good to be aware of this, too.<\/p>\n<\/div>\n When you purchase through links in our articles, we may earn a small commission<\/a>. This doesn\u2019t affect our editorial independence.<\/em><\/p>\n