Your Old Google API Key Might Be a Gemini Credit Card (And That’s the Problem)
Attackers are abusing exposed Google Cloud API keys to run up expensive Gemini usage—often on legacy “AIZA…” keys—leaving developers staring at five- and six-figure bills and (sometimes) support refusals.
Imagine this: you wake up, check your inbox, and there’s a Google Cloud billing alert that looks like it belongs to a Fortune 500 company… not your side project. You open the console and see Gemini requests flying like it’s Black Friday. Except you didn’t run them. Someone else did—using your API key.
That’s basically the latest wave of news around Google Gemini API key abuse: attackers are finding exposed Google Cloud API keys (often the older “AIZA…” ones), using them to call expensive Gemini endpoints, and regular developers are getting handed the bill. And yeah, in a bunch of cases, people say Google support initially refused to waive charges, leaning on the “shared responsibility” model. Fun.
What’s actually happening (in plain English)

Attackers aren’t doing magic. They’re doing key hunting:
- Find exposed Google API keys in public GitHub repos, client-side JavaScript, Android apps, tutorials, you name it.
- Use those keys to hit Gemini APIs—text, image, video generation—anything with tasty per-request pricing.
- Run up massive usage fast (thousands to six figures), because AI workloads scale like a teenager with a parent’s credit card.
- Owner notices late due to reporting/alert lag, then scrambles to revoke keys and shut APIs off.
Here’s what most people miss: many of these keys were created back when Google’s docs treated them like “non-sensitive identifiers” for stuff like Maps or Firebase. Historically, embedding certain keys in front-end or mobile apps wasn’t unusual. Then Gemini arrives, gets enabled on a project, and suddenly those same legacy keys can become valid credentials for expensive AI calls—sometimes without the developer explicitly realizing they’ve just upgraded an old key into a financial liability. Reports and researcher writeups call this a systemic design/permissioning problem, not pure developer negligence. [2] [5] [6]
Stats spotlight: the bills people are reporting
Not “a few dollars.” More like “I need to lie down.” Public reporting includes:

- ~$8,000 after a project jumped from under $50/month, tied to unauthorized Gemini inferencing. [1] [5]
- $15,400 for a solo developer who revoked the key within minutes—billing lag meant it was already too late. [2]
- $82,314.44 in ~48 hours for a three-dev startup in Mexico (normal spend ~ $180/month). [6]
- $128,000 for a Japanese company, reportedly even with some IP restrictions in place. [2]
- $18,000+ for a user who thought they had a tiny budget and a spending cap—yet woke up to ~60,000 Gemini requests. [4]
Why people are getting stuck with the bill
Look, I’ll be honest… this is the part that makes developers feel gaslit.
Based on multiple reports, the stuck-with-the-bill pattern typically comes from five forces colliding:
- Shared responsibility (Google’s stance) Google secures the cloud platform. You secure your keys, restrictions, and monitoring. If an attacker used a valid key, it often gets treated as “your usage.” [3] [6]
- “Compliant then, risky now” key usage Some keys were implemented in ways that matched older guidance (especially around “public” keys). Then Gemini privileges entered the picture and the risk profile changed. [2] [5]
- Protections weren’t on by default People later discover restrictions/quotas/guardrails that could’ve limited blast radius—but they were optional or buried, especially for older projects. [4] [5]
- Billing/alert lag Even if you react quickly, usage can accumulate before it’s visible. That’s how someone can revoke a key in minutes and still get hit with five figures. [2]
- “Legacy” keys becoming Gemini-capable Researchers describe this as old, widely-exposed key formats (like “AIZA…”) effectively becoming more powerful once Gemini is enabled—turning “project identifiers” into “authentication tokens” for costly AI calls. [2] [6]
The Bottom Line (TL;DR)
The bottom line is… exposed Google Cloud API keys are being actively abused to call expensive Gemini APIs, and due to a mix of legacy key behavior, optional guardrails, and billing lag, developers can end up owing huge amounts—sometimes with limited immediate refund relief. [2] [4] [6]
So what’s new on Google’s side?
There are signs Google is moving, but it’s uneven.
- New Gemini key type (reported as “AQ…” prefix) separate from older “AIZA…” keys. [5]
- Separation between Gemini and Maps access: Google said you can’t create a single key that accesses both. [5]
- API restrictions required on new keys rather than optional. [5]
- Bug reclassification: after researcher disclosure, Google reportedly reclassified from “Customer Issue” to a “Bug” with increased severity. [6]
- Talk of spending caps/alerts for Gemini, but users say enforcement and lag still bite. [2] [5]
Common mistakes (don’t do this)
- Assuming a “public” key is harmless If it can be used to authenticate billable calls, it’s not harmless. Period.
- Leaving old keys alive “because nothing uses them” Attackers love abandoned doors. Rotate or delete.
- Enabling Gemini on a project with legacy keys without auditing key restrictions first This is where a lot of the horror stories start. [5] [6]
- Relying on alerts as your main defense Alerts are a smoke detector. You still need sprinklers (quotas/restrictions).
FAQ

1) Is this just developers leaking secrets on GitHub?
Sometimes, yes. But researchers argue a big chunk is legacy behavior: keys that were historically treated as low-risk identifiers became high-value once Gemini was enabled. [2] [6]
2) Can revoking the key stop the bill instantly?
It stops future usage, but due to reporting lag you can still be billed for usage that already happened but wasn’t surfaced yet. [2]
3) Will Google refund fraudulent Gemini usage?
Public accounts suggest refunds/credits aren’t automatic. Some users report initial refusals citing shared responsibility, though situations vary. [3] [6] [8]
4) How big is the exposure?
Truffle Security reported finding 2,863 live exposed keys that could authenticate to Gemini. CloudSEK found exposed keys across Android apps with 500M+ installs in aggregate. [2] [6]
Action challenge: do one thing today
If you only do one thing after reading this, do this: search your repos for “AIZA” and inventory every key you find. Then go into Google Cloud Console and restrict or delete anything you don’t fully understand. Is it a little annoying? Yep. Is it less annoying than an $18,000 surprise? Also yep.
Sources
- The Register reporting on Gemini key abuse and billing spikes (example case: ~$8K jump). [1]
- TechRadar Pro: leaked Google API keys abused for Gemini, billing lag and large fraud cases. [2]
- The Register: support disputes and “shared responsibility” responses. [3]
- Tom’s Hardware: $18,000+ bill despite perceived caps; protections off by default. [4]
- The Register: new Gemini key type, forced restrictions, separation from Maps. [5]
- The Register: Mexico startup $82,314 case; Truffle Security findings. [6]
- CyberNews: additional case studies and patterns in delayed detection. [8]