HomeAI StartupsA Google Cloud developer woke up to a $17,000 bill from API...

A Google Cloud developer woke up to a $17,000 bill from API calls he never made, and what really matters is what it reveals about how cloud platforms set their own security standards.

Google Cloud’s COO spent part of last week explaining to executives that security can’t be baked into AI strategies as an afterthought. That same week, security researchers released findings showing that deleted Google API keys remain usable by attackers for up to 23 minutes, and Google Cloud developers continued to seek reimbursement for five-figure bills triggered by API calls they never authorized. The gap between advice and practice is the story.

Photo by Panumas Nikhomkhai on Pexels

The Order

Francis de Souza, COO of Google Cloud, explained at a recent event in Los Angeles that companies must demand security, governance, and auditability of their platforms from the start, and warned specifically against “shadow AI” – employees seeking consumer tools without organizational oversight. His framing: “There is no AI strategy without a data strategy and security strategy. They must go hand in hand.”

The framing of the threat landscape is equally striking. Google’s Mandiant M-Trends 2026 report, presented at RSAC, found that adversary coordination reduced the time between initial access and handover to a subsequent attacker to 22 seconds. The implication: Human-led defense is structurally too slow. Google Cloud’s proposed response, articulated at Cloud Next 2026, is a shift from human-in-the-loop defense to AI-led defense, with humans supervising rather than operating in the loop.

The Practice

While this case was being presented, The Register was documenting a different story on the same platform. Prentus CEO Rod Danan saw his Google Cloud bill rise to $10,138 in about 30 minutes after attackers used a compromised API key. Sydney-based developer Isuru Fonseka woke up to charges of around AUD17,000 when it thought it had a $250 spending cap in place. Google later refunded both after the report came out, but said it would not change the underlying policy.

The mechanism deserves attention. A February analysis by Joe Leon, a security researcher at Truffle, documented that API keys initially deployed for Google Maps — keys that Google’s own documentation required developers to publicly paste into HTML — quietly became capable of accessing Gemini models after Google expanded their scope. Truffle’s analysis of public web sources revealed 2,863 live Google API keys exposed to this vector. Separately, Google’s automated systems enhanced users’ billing levels based on account history, increasing effective caps up to $100,000 without explicit consent. Google said it would continue this policy of automatically upgrading tiers, citing a preference for preventing service outages rather than enforcing user-reported budget caps.

The 23 Minute Window

The issue of credential revocation is the more revealing of the two. Aikido Security researchers, led by Joe Leon, found that even developers who detect a compromised key and immediately remove it may not be safe. Over the course of ten controlled trials, the revocation window varied from about eight minutes to almost 23 minutes, with a median around 16. During this window, success rates are unpredictable: within a few minutes, more than 90% of requests are still authenticated; in others, less than 1%. Attackers can take advantage of this time to exfiltrate cached Gemini chat files and data.

Aikido’s analysis indicates that Google’s new credential formats don’t have the same problem: Service Account API credentials are revoked in about five seconds, and Gemini’s AQ-prefixed key format takes about a minute. Both work at Google scale, which suggests that this is also technically solvable for standard Google API keys. Google told Aikido that it has no plans to close this gap, closing the report as “will not fix (infeasible)” and describing the propagation delay as working as intended. In other words, the 23-minute window is a question of priorities rather than technical constraint.

Why It Is Important Structurally

The standard interpretation of such incidents is that they reflect implementation gaps that a large platform will eventually fill. Institutional reading is more difficult. Cloud platforms simultaneously sell AI infrastructure, AI security tools, and analytical frameworks that customers use to think about AI risks. The same company that prescribes the standard also defines what counts for meeting it and operates with internal incentives (availability, billing continuity, default extension of API scope) that do not always match the customer’s declared security posture.

De Souza himself was candid that the industry was still figuring this out, telling TechCrunch that everyone is “navigating AI security in real time” and that a long-term sustainable understanding of AI security remains several years away. This is a frank assessment from someone whose job it is to have answers.

Silicon Canals has previously examined how the AI industry’s confidence in its own architecture is quietly being questioned in private, even as it is marketed in public. The security layer follows a similar pattern. The advice from the platform’s leaders is sound. The practice on the same platforms lags behind the board by several steps. Both things are true, and clients are asked to follow the prescription while absorbing the cost of the deviation.

API key vulnerabilityPhoto by Tima Miroshnichenko on Pexels

Source

“`

Must Read
Related News

LEAVE A REPLY

Please enter your comment!
Please enter your name here