Unrestricted API key + AI Studio silently enabled Gemini — $14k bill on a small family brazilian tire shop

Gemini API
1

Hello everyone,

I’m from Brazil and run a simple website for my family’s tire shop, hosted on Google Cloud since 2020. Our monthly bill was always around $44 USD. That changed overnight.

What happened:

  • In 2021 I created an unrestricted API key exclusively for Google Maps (used on our public site with Elementor).

  • In late 2025 I used AI Studio to build a small internal app for tire classification. AI Studio asked to enable the Gemini API — I approved. It did not warn me that this would give every unrestricted key in the project access to Gemini.

  • On June 10, 2026, within a single hour, our credit card was charged **$7,500** (and another $6,500 is pending). Over 600k Gemini API calls were made using that old 2021 key — an obvious exploit.

Key evidence that this is a platform‑side risk:

Just today I received the attached email from the Gemini API team. It states:

“API keys generated by Google AI Studio are restricted by default… A project that contains additional, unrestricted API keys can pose a risk… Possible impacts may include: Financial risk… Data exposure…”
And they’re now requiring all unrestricted keys to be restricted by June 19, 2026.

This is exactly what hit us: a silent permission inheritance that turned a Maps key into a Gemini key with no warning.

Additionally, a YouTube video from March 2026 (https://www.youtube.com/watch?v=z5wfFb33RtM) already exposed that the default Google Maps API setup leaves keys unrestricted and public. Google is only fully enforcing restrictions on June 19 — 9 days after my family’s card was drained.

I’ve already secured everything (rotated keys, applied restrictions), but the financial damage is done. We cannot afford to pay this bill. I opened billing case #72154838 and security incident #72156050 within hours, but the billing data took 10 hours to appear, and I only received an automated “suspicious activity” alert 2 hours after the attack.

I have filed a bank dispute as a precaution, but I truly want to resolve this amicably with Google. I’m asking for a full refund of the fraudulent Gemini charges, given that:

  1. AI Studio silently expanded the key’s permissions without clear consent.

  2. Google’s own Gemini team now acknowledges this unrestricted‑key risk as a financial danger.

  3. The vulnerability was publicly known for months before Google acted.

If anyone from the Google Cloud or AI Studio team sees this, please take a look at case #72154838 (billing) and #72156050 (security). I’ll share some screenshots translated to English below.

Thank you for any help or visibility you can give.

Best regards,
Lúcio

image
image571×892 45.3 KB

image
image2532×368 59.1 KB

image
image2547×705 98 KB

2

Hi Lucio. I am Shivam, founder of Sunja Labs from India. I completely empathise with you and we are also in a similar situation where we were charged around 80k USD in a few early morning hours.

We have been adjusted 75% of the amount and are now left with a 20k USD bill which is 100x of what we spend in a month. We were running our infra with 2000 USD startup credits that would have given us one year infra runway. We were running an ed tech startup completely bootstrapped with huge personal loans and at a time where we were super cash starved, we are hit with 20k USD bill. We were creating 10 dollars solutions for students in examination space where competitors are charging 200 dollars. And now our product is frozen and our apps are not working and trying to get a full refund so that we get our product back on track.

This bill risks shutting down our startup and pushing us into years of further debt in addition to debt that we had already taken to run our startup. Hope for a peaceful resolution as well and we too are arguing that we had done 100% everything we could do security wise. We were running infrastructure for a previous company for 8 years and we did everything every day security wise. And this API key that was used unauthorised was for an AI studio account that was not being used live in any of our products. Our Google cloud case no is #71428196. Hoping that Google does the right thing for us and for you Lucio.

Thanks.

3

@Mustan_lokhand and @Logan_Kilpatrick - i would appreaciate if you read my topic and give a little of attention into my cases opened at google support

4

New updates from the case.

Thanks to @Mustan_lokhand, the case has been escalated.

I also conducted a forensic investigation into my account using Cloud Shell and AI.

These are the results:

Full forensic analysis (collected from Google’s own APIs, inside Google Cloud Shell, read-only and fully reproducible — your team can re-run every query and get the same numbers):

1. Attribution is conclusive. Cloud Monitoring’s credential_id label attributes 593,546 of ~594,000 Gemini API calls to API key uid d514********e5241 — “API key 2”, created on June 12, 2021 for Google Maps on our public website, with no restrictions (the default at the time, for a key type that is designed to be publicly exposed in HTML).

2. The silent scope expansion is in the audit logs. On Dec 27, 2025, the Generative Language API was enabled on the project through the AI Studio flow. AI Studio created its own keys already restricted to Gemini — proof the system knows Gemini keys must be restricted — yet the same enablement silently extended Gemini access to my unrestricted 2021 Maps key, with no warning.

3. The attack profile is professional, not accidental usage. Scanner probes of 1 call/day hit the key on June 8–9. A 104-call test ran at 12:00 UTC on June 10. The attack itself ran 15:00–17:00 UTC on June 10: 515,226 calls in the first hour, 78,886 in the second (~143 requests/second), including 481k GenerateContent, 88k StreamGenerateContent, 43 video-generation operations (PredictLongRunning, with 66 file downloads) and 1,725 Search-grounding requests.

4. My account was never compromised. The Admin Activity audit log shows zero third-party actions — no IAM changes, no keys created by anyone but me. This was pure abuse of a publicly exposed Maps key string. There is no password or account negligence on my side to point to.

5. I responded fast. I disabled the service at 20:23 UTC the same day, then rotated and restricted every key — exactly what the Gemini API team’s email now requires of everyone by June 19 (an email that itself describes unrestricted keys as a “financial risk”). My family was hit 9 days before that enforcement.

Complete evidence package (raw JSON exports of audit logs, metric time series, key configurations, plus methodology with every source command and a SHA-256 integrity manifest): link provided upon request…

I truly want to resolve this amicably — Google has already made affected users whole in similar Maps-key-to-Gemini incidents, and I’m hopeful my family’s case will be treated the same way.

5

Just found another critical flaw in how the Gemini API and Google Cloud billing systems handle security: the automated billing threshold escalation.

The system essentially weaponizes its own auto-scaling billing limits during an attack, without any anomaly detection triggering a hard stop for accounts with no previous high-volume usage.

Here is the exact timeline of the rapid threshold expansion that hit my account on June 10 (times in UTC-3):

  • 12:22: Billed R$ 2,000.00, around 400 usd;

  • 12:26: Escalated to R$ 5,000.00, around 1000 usd;

  • 12:37: Escalated to R$ 10,000.00, around 2000 usd;

  • 12:53: Escalated to R$ 20,000.00, around 5000 usd;

In exactly 31 minutes, the system automatically approved four escalating billing tiers, successfully draining my entire corporate credit card limit. The next attempted charge (which I suspect was going to be around R$ 30,000.00) only failed because my credit card maxed out and blocked the transaction.

Given that my historical Gemini usage was practically zero, the attackers exploited this rapid, unchecked billing escalation to drain the card. If I had an infinite credit limit, the automated system would have happily generated an unpayable debt before sending any real-time fraud alerts or rate-limiting the requests. This is a massive vulnerability for small businesses.

7

Furthermore, this incident exposes a severe architectural failure regarding Credential Isolation and the Principle of Least Privilege.

In any secure cloud environment, credentials must be strictly service-specific. An API key generated in 2021 exclusively for a client-side, inherently public service (Google Maps rendering) should never be technically capable of crossing domains to access a high-cost, server-side service (Generative AI).

By allowing a legacy Maps key to silently function as a Gemini key, the platform fundamentally broke credential isolation. The system effectively transformed a key that is designed to be exposed in public HTML into a weaponized AI credential, without requiring the generation of a new, service-specific token. Security by design dictates that high-risk AI endpoints should explicitly reject credentials that were minted for front-end web mapping.

8

The core issue isn’t that my key was “unrestricted” — it’s the timeline and Google’s own decade of guidance.

I want to address the framing that this was a configuration mistake on my end, because the chronology makes that untenable.

The key in question was created in 2021. The service that generated these charges — the Generative Language API — did not exist at that time. Google’s generative endpoint (the PaLM API, the direct predecessor) was only announced in March 2023 and entered public preview in May 2023. There was no generative AI behind the AIza... key format when I created the credential. I cannot meaningfully be said to have “failed to restrict” a key against a high-cost service that would not be invented for another two years.

This matters because of what the AIza... key format was for over a decade. By Google’s own published guidance, these keys were public identifiers — explicitly documented as safe to embed in client-side HTML and JavaScript, used for a narrow set of low-sensitivity services (Maps, YouTube Data, Custom Search, etc.). The high-value Cloud services have always required OAuth or service accounts, never a bare AIza key. So in 2021 this credential was, by design and by documentation, a low-risk public identifier — not an authentication secret.

What happened is that the Gemini/Generative Language API was later wired to accept that same key format, and once the API became enabled on the project, the existing key silently gained access to a billable, server-side AI endpoint — no warning, no confirmation dialog, no email. This is precisely the “retroactive privilege expansion” / credential scope drift documented in Truffle Security’s February 2026 disclosure. It is not user misuse; it is a platform design decision applied retroactively to credentials minted under a different, explicitly-public security contract.

And Google appears to agree it was a defect. As of June 19, 2026, the Gemini API will reject requests from unrestricted standard keys, and new AI Studio keys now default to scoped auth keys restricted to the Gemini API. That fix targets exactly the mechanism that drained my account. You don’t ship that change for behavior that was working as intended.

Given all of the above, I’m asking that these charges be treated as the product of a platform-side design defect — a credential created in 2021 for a service that did not exist, retroactively granted access to a high-cost endpoint with no notification — and reversed accordingly.

9

A question, did you accidentally embedded API secret key in client side application or you didn’t implement rate limit in your application to avoid users abuse your services that cause money?

Just want to learn from other users.

10

Good question — answering both parts actually clarifies how this class of attack works.

On embedding the key client-side: yes, the key was in client-side code — because it was a Maps key, and for over a decade Google’s own documentation explicitly stated that Maps/AIza keys are not secrets and are meant to be embedded directly in client-side HTML and JavaScript. So the key being public wasn’t a slip on my part; it was the documented, intended usage for that key type. The problem is that Google later made that same public-by-design credential able to authenticate to a billable, server-side AI endpoint once the Generative Language API became enabled on the project — silently, no warning.

On rate limiting in my application: this is the central misconception, and it’s worth understanding. App-level rate limiting wouldn’t have helped at all, because the abuse never passed through my application. Once the key was scraped, the attacker called the Gemini endpoint directly (server-to-server, curl-style), bypassing my front end entirely. My app’s rate limits only govern traffic flowing through my app — they’re invisible to someone hitting generativelanguage.googleapis.com directly with a valid key.

For the same reason, HTTP referrer / IP restrictions offer little protection here: they constrain where a key can be used from, not which APIs it can reach — and a Referer header is trivially spoofable from a server.

The only controls that would actually have stopped this are on Google’s side: (1) API restrictions scoping the key so it can’t call the Generative Language API at all, and (2) a hard spending cap. Neither is on by default — and budgets are alerts, not caps; there’s no native hard limit. That combination — public-by-design key + retroactively-granted AI access + no hard cap — is what turned a scraped Maps key into a five-figure bill.

Happy to share the audit steps I’m using to lock things down, if useful.

11

Not accidental. Google Maps SDK require you to publish the key within the javascript import. This was this guidelines forever, even today. By default, newly generated Google Maps API keys are unrestricted. Since this is the default behaviour, you can fairly assume a lot of websites do have this even today.

Now, when you use AI Studio, the studio creates api key, then enables Gemini API project wide, and maps Gemini API to all keys, including the old unrestricted keys - this is where Google went wrong - and they never informed the user either of this backend change to old keys.

Worst part, Google knew about this issue for 6 months now but didn’t fix it yet by removing Gemini APIs access across all unrestricted keys. What Google could have fixed long back, is now finally getting fixed by June 19 after all the harassment the existing customers went through. This is very shameful. I hope Google resolves these threads ASAP, even we are waiting on 13k USD refund from them for over a month now. I can imagine they must be bombed with many such cases since this is a systemic issue.

12

@Shekhar_Chatterjee — reading that you’ve been waiting over a month on a 13k refund, and that you read this as systemic, is somehow both a relief and a gut-punch. A relief, because for days wondered whether I was the unlucky outlier or just the canary. A gut-punch, because it confirms there are real people and real small businesses bleeding money while Google takes its time.

And the bleeding is the part I need to put on the record here, because in our case it’s getting worse, not better.

The refund itself has become a second injury. From what we’re seeing, Google is either not recognizing the refund at all in some cases, or “refunding” it as platform credits — which, for a small family tire shop, is almost insulting. We will never burn through that balance in cloud usage; at our scale it would take something like five years to consume it. A credit you can’t realistically use is not a refund. It’s the same charge, repackaged.

Meanwhile the clock that actually matters keeps running. The fraudulent usage landed on a credit-card invoice we couldn’t pay — roughly 8k USD now overdue — and the bank doesn’t care whose fault it was. Interest is compounding on money we never spent, for a service we never knowingly enabled, on a credential Google itself silently rewired. So we are paying — in interest, in cash flow, in sleep — for Google’s defect, while the “remedy” on offer is store credit.

What we need, and what I’d urge everyone in this thread to insist on, is a genuine cash refund to the original payment method — fast enough to stop the financial damage that is still accruing right now. Not credits. Not only a June 19 patch that closes the door after the house has already burned.

I’m glad you’re documenting your 13k here too. The more of us who put the actual numbers on the record, the harder this becomes to wave away as a handful of edge cases.

13

Still waiting for support… While the credit card bill is coming…

14

I just want to add something practical here for anyone who’s already been hit with a huge, unexpected Gemini API bill — because at this point it’s clear this isn’t a handful of isolated cases, and people are genuinely panicking.

If you’ve already received the full charge, here’s the approach that seems to be helping others the most:

1. Treat this as a platform‑side billing error, not user error.
Gemini API was silently enabled on existing keys with no confirmation, no spending caps, and no alerts. That’s not a configuration mistake — that’s a systemic issue.

2. Contact your bank immediately and dispute the charge.
Tell them the usage was unauthorised and caused by a platform defect. Several people have reported that banks will pause interest and collections while the dispute is active. This stops the financial damage from getting worse while Google investigates.

3. Open a Google Billing dispute and insist on a refund to the original payment method.
Credits don’t help small businesses who now have overdue credit‑card balances and interest accumulating. A credit is not a refund.

4. Document everything.
Screenshots of usage, timestamps, API key settings, credit‑card statements, and your support ticket numbers. This protects you with both Google and the bank.

5. Keep your case visible.
People who post updates publicly seem to get faster movement. It also helps others realise they’re not alone — which matters when you’re staring at a $10k+ bill you never authorised.

This situation is clearly affecting multiple small businesses, and the financial impact is real. The more people share their experience and the actual numbers, the harder it becomes for this to be dismissed as isolated “edge cases”.

:brazil: For users in Brazil

Brazil has some of the strongest consumer‑protection laws in the world. If you’ve been hit with a huge, unexpected Gemini API bill:

• Dispute the charge with your bank (contestar cobrança)
Banks can freeze interest and temporarily reverse the charge while they investigate.

• File a complaint with PROCON
This is Brazil’s main consumer‑protection authority. They can pressure companies directly.

• Open a case on Consumidor.gov.br
Google is registered there and legally required to respond. Cases here get faster attention than normal support tickets.

• Escalate to Banco Central if the bank mishandles the dispute
If your bank refuses to help, Banco Central forces them to follow proper procedure.

• Use Juizado Especial Cível (Small Claims Court)
For claims under 20,000 BRL, you don’t need a lawyer. Judges often side with consumers when services were activated without consent.

Silent activation of a paid API without user confirmation is considered an abusive practice under the Brazilian Consumer Defense Code (CDC).

:india: For users in India

India also has strong digital‑consumer protections. If you’re in India and got hit with an unexpected bill:

• Dispute the charge with your bank/card issuer
Indian banks must investigate unauthorised or disputed transactions under RBI rules.

• File a complaint on the National Consumer Helpline (NCH)
This creates an official record and triggers follow‑up with the company.

• Use the Consumer Protection Act (CPA 2019)
If Google refuses a proper refund, you can escalate to a Consumer Commission (District level).
These courts handle digital‑service billing disputes regularly.

• RBI Ombudsman (if the bank mishandles the dispute)
If your bank refuses to freeze interest or open a dispute, the RBI Ombudsman can intervene.

• MeitY grievance portal
For issues involving digital platforms operating in India, you can file a grievance under IT Rules 2021.

15

Thank you, Terry — this is genuinely useful, and the Brazil-specific roadmap especially. I’ve documented all of it. I’m posting this update partly so the thread doesn’t go quiet, and partly so anyone else caught by this knows what the road actually looks like after the bill lands.

Let me be clear about where I stand: I’m not here to fight Google. I’ve trusted my entire stack to this company since 2020 — Workspace and Drive run my law practice, Google Cloud hosts the servers and sites for my other businesses. I still want to resolve this directly and amicably. That’s exactly why the next part is hard to write.

Because over five days I’ve had three live-chat escalations, with three different agents, and each one started from zero.

June 10, within hours of the attack. The billing dashboard showed nothing — no anomaly, no usage, just my father’s card already drained by ~R$37,000. The agent literally could not see the incident, because billing data lags roughly 32 hours. So I was told to “wait for propagation,” handed a spend-cap link, and promised an email update. That email never came.

June 13. A second agent told me she had added a high-priority note, attached my full forensic ZIP, escalated the case to Trust & Safety and Billing Escalation, and placed a hold against automated suspension.

June 15. A third agent submitted a brand-new adjustment request — which can only mean the previous two escalations went nowhere. When I asked for four simple things — the case status, a tracking number for the adjustment, an SLA, and written confirmation that the specialized team had ever actually opened the file — I got “we are unable to disclose internal information,” and another round of “rest assured.”

Here is the part that should worry Google, not me: the people hit hardest by a flaw Google itself is patching on June 19 are being routed into a Tier 1 loop with no case continuity, no ticket for the adjustment, no SLA, and promised emails that don’t arrive. And the billing-propagation lag means the very first agent you reach — in the panic of the first hour — structurally cannot see what happened. The clock starts late, and the entire burden of proof lands on the victim.

It isn’t for lack of evidence. I did the forensics myself, read-only and reproducible, from Google’s own Cloud Monitoring APIs: 593,546 of ~594,000 calls attributed to a single 2021 Maps key; the Dec 27, 2025 audit-log entry where enabling Gemini silently extended access to that unrestricted key; zero third-party admin actions — no compromise, no negligence on my side. I handed all of it over. The evidence isn’t missing. It just has nowhere to land.

And this is not an edge case. Truffle Security disclosed this exact privilege-escalation in February 2026; Google first called it “intended behavior,” then reclassified it as a bug. The root-cause fix lands June 19. My family was charged on June 10 — nine days inside that gap.

So my ask to anyone from Google reading this is simple. I don’t need another “rest assured.” I need case #72154838 to actually reach the specialized team, and one written status update confirming it’s there. @Mustansir_Lokhandwala already confirmed on this forum that the case was escalated — I’m just asking that the escalation be real on the inside, not only on the transcript.

I want to resolve this with Google directly, and I want to keep believing in the company I built my work on. Help me do that.

— Lúcio

16

Lúcio — here’s a clear next‑step plan based on what you described.

  1. Ask Google support to confirm in writing that case #72154838 has been opened by the Billing Specialist Team or Trust & Safety.

  2. Dispute the charge with your bank immediately — this freezes interest and forces a regulated investigation.

  3. File a complaint on Consumidor.gov.br — Google is legally required to respond there.

  4. If needed, escalate to PROCON.

  5. Keep posting updates publicly — your documentation is strong and helps others.

  6. Keep emphasising that the charge occurred inside the known vulnerability window (June 10 vs June 19 fix).

You’ve done everything right so far. The issue now is getting your case out of the Tier‑1 loop and into the specialist team that can actually resolve it.. I am 84 years old. I am always happy to help someone in need

Terry Mechan UK Here is my background as heard on BBC recently. medteach..placemeguardian.com/bbcinterview

17
18

You are a great help man! Thank you…