By ByteBot
You just deleted that leaked Google API key. It’s still working. Researchers at Aikido Security confirmed this week that deleted Google API keys remain fully functional for up to 23 minutes after deletion — long enough for an attacker to rack up a five-figure bill on your account. Google reviewed the report and closed it: “Won’t Fix (Infeasible).”
What Aikido Found
Security researcher Joseph Leon ran 10 trials over two days, sending 3–5 authenticated requests per second after deleting a key. The result: some of those requests authenticated for up to 23 minutes post-deletion. The success rate fluctuated sharply — over 90% of requests authenticated in some windows, fewer than 1% in others. That’s not random noise. That’s eventual consistency across Google’s global infrastructure, and it means an attacker only needs to keep retrying until they hit a node that hasn’t received the deletion update yet.
Testing spanned US East Coast, Western Europe, and Southeast Asia. Singapore picked up deletions faster than expected — suggesting Google’s routing is more complex than simple geographic CDN propagation. The inconsistency makes the window hard to predict and therefore hard to defend against.
Google Says This Is Intentional
Aikido filed a security report. Google’s response, per The Register: “the delay due to propagation of the deletion of these keys is working as intended.” Closed as “Won’t Fix (Infeasible).”
That’s a significant stance. It means every developer who has ever deleted a Google API key in response to a leak was operating on a false assumption — that deletion equals revocation. It doesn’t. The exposure window exists permanently, by design, with no fix planned.
The Financial Blast Radius
This matters most when keys are tied to expensive services. Google has an automatic billing tier upgrade mechanism most developers don’t know about: accounts active 30 or more days with $1,000 or more in lifetime spending get automatically upgraded to a $100,000 spending limit. Your starting cap is $250. If your account has been active a while, that cap may already be $100,000 — and an attacker hammering Gemini or Veo 3 APIs for 23 minutes can make serious use of it. Beyond billing fraud, the window also lets attackers exfiltrate uploaded files and cached AI conversations before the key goes cold.
AWS Fixed This. Google Won’t.
AWS had a similar problem — a 4-second credential revocation gap disclosed in December 2025. AWS patched it. Google’s 23-minute window is 345 times longer, disclosed now, and the company has explicitly decided not to fix it. The comparison matters because it establishes that this kind of problem is solvable. It’s an infrastructure choice, not an immutable constraint.
What Developers Need to Do Now
Since Google won’t close the window, you have to work around it:
- Never treat key deletion as instant revocation. Budget for a 30-minute minimum exposure window after deletion. Update your incident response runbooks accordingly.
- Restrict keys from creation. Every API key should have API restrictions, IP allowlists, or referrer restrictions set at creation. A restricted key is far less useful to an attacker.
- Set hard billing budget caps. Google Cloud Billing supports hard budget thresholds. Set one that reflects your actual expected usage — not the default ceiling Google assigns.
- Use service accounts with short-lived tokens for production. Service account tokens expire. API keys persist until deletion — and then for another 23 minutes after that.
- Use Secret Manager instead of raw API keys. It provides centralized rotation and auditing that raw key management can’t match. See Google’s remediation guide for migration steps.
- Enable Security Command Center. Real-time anomaly detection catches unusual API usage before the bill arrives.
The Bigger Problem
Developers have been told for years that the correct response to a leaked key is to delete it immediately and rotate. That advice is still correct — but “delete it immediately” now means “delete it and treat it as still-live for the next 30 minutes.” Google has made its position clear. The 23-minute window isn’t going away. Incident response planning needs to account for it.
