Your Old Google API Key Might Be a Gemini Credit Card (And That’s the Problem)

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)

Developer laptop screen with billing alert banner and rapidly rising cloud cost chart.
If your costs look like a hockey stick, it’s time to assume compromise.

Attackers aren’t doing magic. They’re doing key hunting:

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:

Isometric servers and API gateway funneling requests into a Gemini model icon and cost gauge.
One leaked key + a pricey endpoint = a very bad weekend.

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:

  1. 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]
  2. “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]
  3. 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]
  4. 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]
  5. “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.

Common mistakes (don’t do this)

FAQ

Infographic dashboard showing five factors that lead to large Gemini abuse bills.
Print this mentally and tape it to your cloud console.

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

  1. The Register reporting on Gemini key abuse and billing spikes (example case: ~$8K jump). [1]
  2. TechRadar Pro: leaked Google API keys abused for Gemini, billing lag and large fraud cases. [2]
  3. The Register: support disputes and “shared responsibility” responses. [3]
  4. Tom’s Hardware: $18,000+ bill despite perceived caps; protections off by default. [4]
  5. The Register: new Gemini key type, forced restrictions, separation from Maps. [5]
  6. The Register: Mexico startup $82,314 case; Truffle Security findings. [6]
  7. CyberNews: additional case studies and patterns in delayed detection. [8]