€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

https://discuss.ai.google.dev/t/unexpected-54k-billing-spike-in-13-hours-firebase-browser-key-without-api-restrictions-used-for-gemini-requests/140262

by zanbezi • 3 months ago

400 282 3 months ago

discuss.ai.google.dev

patcon• 3 months ago

That's fucking bonkers that nothing in the system could see this as unusual and worthy of throttling. The embarrassment of this -- that a company LITERALLY SELLING machine learning services and expertise -- cannot spot such a thing... This should have led them to deal with this internally and refund it. Just... Wow Google.

lukewarm7072• 3 months ago

there is no way to cap your billing on gcp.

you can get notifications but that's it.

i don't want to get throttled below my quota but some type of spend limit would be good.

rvnx• 3 months ago

and the notifications can be delayed because the spending system is not updated in real-time, so even if you have a Cloud Task triggering on spending to disable the project it may be too slow and several thousands may already be spent.

bombcar2• 3 months ago

Is there a cloud provider that does have hard unbreakable billing caps? Everything I've seen has always been notifications or soft caps.

Not talking about fixed-access things like a Hetzer box.

trick-or-treat3• 3 months ago

This is GCP's revenue model, lol. Let's provide a (semi) generous free tier and trick people into accidentally going over it.

voidUpdate• 3 months ago

The company selling machine learning services would probably love a €54k bonus

owebmaster2• 3 months ago

It's so funny seeing people thinking this is not by design

lukewarm7072• 3 months ago

i have seen this so many times...

i'm thinking it's time we replaced api keys.

some type of real time crypto payment maybe?

freedomben3• 3 months ago

Oh please no. And the "alternatives" to API keys aren't going to help much either, they'll just add friction to getting started (as reference: see the pain involved in writing a script that hits gmail or calendar API)

trick-or-treat3• 3 months ago

Prepaid only is a fantastic idea, especially for dumb-ass startups. Limiting your liability to $100 or so sound like a big-ass W.

freedomben3• 3 months ago

Prepaid only is a fantastic idea, until your site goes (desirably) viral and then gets shut off right as traffic is picking up, or you grow steadily and forget to increase your deposit amount and suddenly production is down. Billing alerts are a much better solution IMHO.

100ms2• 3 months ago

Implementing this in any meaningful manner quickly begins to look like every read becoming a globally synchronised write. Of course it doesn't have to be perfect, but even approximating perfection doesn't look much different. Also, can you imagine the kind of downtimes and complaints that would inevitably originate from a fully synchronous billing architecture?

eru3• 3 months ago

Yes, pre-paid would be fine and it's a well-understood pattern.

No need to retire API keys.

christkv• 3 months ago

Open ai has this

mdrzn2• 3 months ago

drtz• 3 months ago

Are there recommended safeguards beyond ... moving calls server-side?

This implies the API calls originated in the client, suggesting the client may have had they API key.

embedding-shape5• 3 months ago

Yeah, the amount of people creating, running and maintaining websites yet don't understand how websites actually work in practice is very high and seems we haven't even come close to the ceiling yet.

dpkirchner2• 3 months ago

That's standard for Firebase apps. It's also recommended by Google (they describe the keys as "public by design").

Retr0id• 3 months ago

Feels like a confusing thing to name "key" if it's presumably more of an identifier.

pwdisswordfishs5• 3 months ago

It's "implied" throughout the whole post (or more like assumed that the reader understands this, because it's the basic premise of the problem). It's why they link to a post that explains the basic concept after a remark that "This describes our issue in more detail".

tl;dr Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.

From Google themselves, in the Firebase docs:

API keys for Firebase services are not secret. Firebase uses API keys only to identify your app's Firebase project to Firebase services, and not to control access to database or Cloud Storage data, which is done using Firebase Security Rules. For this reason, you do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code.

<https://firebase.google.com/support/guides/security-checklis...>

... or at least that's what it used to say, until they quietly updated the docs to say this:

API keys for Firebase services are not secret. API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.
All Firebase-provisioned API keys are automatically restricted to Firebase-related APIs. If your app's setup follows the guidelines in this page, then API keys restricted to Firebase services do not need to be treated as secrets, and it's safe to include them in your code or configuration files.

Followed later by (in different section):

Use your Firebase-provisioned API keys only for Firebase-related APIs. If your app uses any other APIs (for example, the Places API for Maps or the Gemini Developer API), use a separate API key and restrict it to the applicable API.

embedding-shape5• 3 months ago

Considering the amount of repositories on public GitHub with hard-coded Gemini API tokens inside the shared source code (https://github.com/search?q=gemini+%22AIza%22&type=code), this hardly comes as a surprise. Google also has historically treated API keys as non-secrets, except with the introduction of the keys for LLM inference, then users are supposed to treat those secretly, but I'm not sure everyone got that memo yet.

Considering that the author didn't share what website this is about, I'd wager they either leaked it accidentally themselves via their frontend, or they've shared their source code with credentials together with it.

ckbkr10• 3 months ago

theres not a single real gemini api key in the results

embedding-shape5• 3 months ago

Setup a watcher and you'll come across live ones eventually :)

dminik2• 3 months ago

Try this one. Should remove most readme keys:

Edit: self censor based on a request

imdsm• 3 months ago

https://github.com/JustForSO/Sentra-Auto-Browser/blob/c048d3...

singpolyma3• 3 months ago

Um. What? In what world are API keys not secrets?

embedding-shape5• 3 months ago

In the frontend world where you have client-side API keys talking directly to 3rd party services from the client. Think things like Google Maps and similar.

darrenf• 3 months ago

In Firebase world API keys are for identification, not authorisation.

https://firebase.google.com/docs/projects/api-keys

Public by design: API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.

boredpudding• 3 months ago

Google API keys have been used for ages on the frontend. For example on Google Maps embeds. Those are not possible without exposing a key to the frontend. They weren't secret, until Gemini arrived.

https://trufflesecurity.com/blog/google-api-keys-werent-secr...

https://medium.com/@ahhyesic/your-google-maps-api-key-now-ha...

https://www.malwarebytes.com/blog/news/2026/02/public-google...

fg137• 3 months ago

Google's world. They explicitly tell you that API keys are not secrets.

https://trufflesecurity.com/blog/google-api-keys-werent-secr...

lxgr8• 3 months ago

Public API keys are a thing. Arguably they are poorly named (it's really more of a client identifier), and modeling them as primarily a key instead of primarily as a non-secret identifier can go very wrong, as evidenced here.

zozbot2343• 3 months ago

Google also has historically treated API keys as non-secrets, except with the introduction of the keys for LLM inference, then users are supposed to treat those secretly

This was reported a long time ago, and was supposed to be fixed by Google via making sure that these legacy public keys would not be usable for Gemini or AI. https://news.ycombinator.com/item?id=47156925 https://ai.google.dev/gemini-api/docs/troubleshooting#google... "We are defaulting to blocking API keys that are leaked and used with the Gemini API, helping prevent abuse of cost and your application data." Why are we hearing about this again?

PunchyHamster2• 3 months ago

the topic is cost overruns. they still allow for cost overruns. What's so hard to comprehend ?

addandsubtract• 3 months ago

FWIW, I just create a new Gemini API key today, and it had a different format than my old ones (created 10 days ago). So maybe they changed something?

mdrzn2• 3 months ago

...JCip3SJw => Your API key was reported as leaked. Please use another API key.

...afnt0t-E => Your API key was reported as leaked. Please use another API key.

...-UYzYTYU => Your API key was reported as leaked. Please use another API key.

I think they all get immediately reported as leaked and invalidated.

luanmuniz• 3 months ago

Unfortunately, yet just another story like this. One of these unexpected usage charges in the thousands appears every month, and with the same automatic denied too. This is one of the reasons I just stopped using these kinds of pay-per-usage cloud services long ago. At best, I still use services that have hard-bounded usage limits, like EC2 from AWS, where one instance can never go beyond 24h/day usage and is always capped, with shutdowns when exceeded, and limited credit cards, too.

It's super frustrating that this is the only option to realistically deal with this issue, since all stories end up the same way: The cloud company just saying "f* you, we don't care, pay up." and legal fees are always expensive :(

embedding-shape5• 3 months ago

At best, I still use services that have hard-bounded usage limits, like EC2 from AWS, where one instance can never go beyond 24h/day usage and is always capped, with shutdowns when exceeded, and limited credit cards, too.

Is this possible on AWS today? I'm the same way, if I cannot set a hard-limit for the billing so I can know for a fact how much it'll maximum cost in a month, I'm not interested in using that service for anything. Which is one of the top reasons I've stayed clear of AWS, they used to have only billing-alerts, but you couldn't actually set limits, guess one step forward that they've finally implemented that now.

827a3• 3 months ago

I said this when this finding was originally posted and I'll say it again: This is by far the worst security incident Google has ever had, and that's why they aren't publicly or loudly responding to it. It's deeply embarrassing. They can't fix it without breaking customer workflows. They really, really want it to just go away and six months from now they'll complete their warning period to their enterprise contracts and then they can turn off this automated grant. Until then they want as few people to know about it as possible, and that means if you aren't on anyone's big & important customer list internally, and you missed the single 40px blurb they put on a buried developer documentation site, you're vulnerable and this will happen to you.

Disgusting behavior.

100ms2• 3 months ago

This is only a little billing leakage, Operation Aurora in 2009 was 100x worse

827a3• 3 months ago

It's actually much more than a billing leak [1]; again, most people don't know how bad this is, because Google is trying to keep it hush-hush. These keys don't just grant access to Gemini completions; they grant access to any endpoint on the generative AI google cloud product. This includes: seeing all of the files that google cloud project has uploaded to gemini, and interacting with the gemini token cache.

[1] https://trufflesecurity.com/blog/google-api-keys-werent-secr...

zarzavat• 3 months ago

It's not a security incident because it makes Google money. It's extra revenue. They are embarrassed all the way to the bank.

At some point, when it appeared 2 months ago on HN and they still did nothing about it, intentionality can be assumed.

bombcar2• 3 months ago

This is exactly it - and the normal "resolution" is a class-action lawsuit but no doubt their terms and conditions forbid that.

However, anyone affected should probably pollute their docket with lawsuits anyway.

tantalor• 3 months ago

What does this have to do with security?

827a3• 3 months ago

Billing control is security, to be clear, but beyond that: The key permissions that enable anyone to generate text also grant access to all GCP Generative AI endpoints in the project they were provisioned in. That includes things like Files that your system might have uploaded to Gemini for processing, and querying the Gemini context caches for recent Gemini completions your system did. Both of these are likely to contain customer-facing data, if your organization & systems use them.

If you're hearing this and your gut reaction is This can't be real; We're on the same page. Its a staggering issue that Google has categorically failed to respond to. They automatically added this permission to existing keys that they knew their customers were publishing publicly on the internet, because the keys are legitimately supposed to be public for things like client-side Firebase access & Google Maps tile rendering.

They did not notify customers that they were doing this. They did not notify customers after this issue was reported to them months later by Truffle. They did not automatically remove the additional key grants for customers. They continue to push guidance targeted at novices like "just put the Gemini key behind a proxy (that's also publicly exposed on the internet)", which might solve the unintentional files and caching endpoint leaks but doesn't solve the billing issue. They denied that Truffle's initial report was even valid, until Truffle used the Internet Archive to find a Google internal key from 2023, published for a Google Maps widget or something, before Gemini was even released, that was still active, and used it to demonstrate to Google that, hey, anyone can use this key to get Gemini completions on the house, is there anyone driving this ship??" Google fixed the permissions on that specific key. And did nothing else.

JackSlateur• 3 months ago

And this is why we invented segmentation, and everybody that are still not doing that are paying now and this is fine

Google is not the only culprit here;

p2detar• 3 months ago

I read the following [0] and immediately went to my firebase project to downgrade my plan. This is horrific.

Yes, I’m looking at a bill of $6,909 for calls to GenerativeLanguage.GenerateContent over about a month, none of which I made. I had quickly created an API key during a live Google training session. I never shared it with anyone and it’s not pushed to any public (or private) repo or website.

0 - https://discuss.ai.google.dev/t/unexpected-gemini-api-billin...

jasonjmcghee• 3 months ago

So someone took a picture of the key at the live training session or something? What's the suspected cause?

mcccsm2• 3 months ago

Two things that should be default on any GCP project touching generative-AI APIs:

1 API-key restrictions by HTTP referrer AND by API (`generativelanguage.googleapis.com` only),

2 a billing budget with a Pub/Sub "cap" action, not just an email alert. Neither is on by default, and almost nobody sets them before shipping. 13 hours is actually fast for detection. most teams find out at end-of-month reconciliation.

PunchyHamster2• 3 months ago

I want API keys with monthly and hourly quotas and RATE LIMITING.

like 50k requests per hour, above that 1/s/client up to 20 req/sec.

I don't want to shotgun my service for every user if one user is misbehaving. I want to set rate of bleeding

mcccsm2• 3 months ago

yet another case of incentive misalignment between user and provider. and unfortunately it's a pattern that extends well beyond AI vendors. it's just a feature of the whole shitshow we live in

dabedee• 3 months ago

As others have said, this is a "feature" for Google, not a bug. There is no easy way to set a hard cap on billing on a project. I spent the better time of an hour trying to find it in the billing settings in GCP, only to land on reddit and figuring out that you could set a budget alert to trigger a Pub/Sub message, which triggers a Cloud Function to disable billing for the project. Insanity.

onemoresoop• 3 months ago

Call it for what it is, an antifeature, a trap for the user.

alasano2• 3 months ago

My favorite Google LLM benchmark is asking Gemini models to create a script that fetches API usage (just request counts) for a project from GCP.

100% failure rate.

dpkirchner2• 3 months ago

I've yet to receive an accurate response from Gemini about GCP services, beyond completely trivial topics. The most recent, I think, was Gemini advising me that I could attach an existing pd SSD PVC to a n4 or c4 VM. For whatever unknowable reason, Google doesn't allow this and doesn't offer a migration path, and Gemini doesn't "know" anything about it either. It's wild.

intended• 3 months ago

As the other user said - this would be an anti-feature and user hostile.

This is a sign that somehow there isn’t sufficient incentive to work on these features.

imafish2• 3 months ago

This is from my experience the same in AWS and Azure. I would love for a kill-switch if the usage goes above a critical threshold. 5 hours down time will not kill my app but a huge cloud bill might.

coredog642• 3 months ago

It's been a year since I last looked at this, but when I did you could get near-realtime cost metrics for AWS Bedrock via CloudWatch (you get input & output token counts and have to generate the actual price yourself)

lxgr8• 3 months ago

This is presumably by design: How can it be the vendor's fault if your custom billing protection implementation failed you at a critical time? Much harder to defend against a switch on their dashboard allowing billing overshoot.

croes2• 3 months ago

Insanity

You mean cash machine

thedangler• 3 months ago

Also, can't you tie a key to a domain or IP address to help stop unauthorized usage?

littlecranky672• 3 months ago

Not if its publicly called from Javascript, as your user's browser will make those requests. You neither know their IP addresses, nor is the referer or origin header a safe choice as it can be spoofed outside of a browser.

lucavice• 3 months ago

If it's called from Javascript in the browser, it's not a secret API key....

JohnScolaro• 3 months ago

We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours. By the time we reacted, costs were already around €28,000.

I had a similar experience with GCP where I set a budget of $100 and was only emailed 5 hours after exceeding the budget by which time I was well over it.

It's mind boggling that features like this aren't prioritized. Sure it would probably make Google less money short term, but surely that's more preferable to providing devs with such a poor experience that they'd never recommend your platform to anyone else again.

zanbezi• 3 months ago

Exactly my thoughts, can not really understand how delayed alerts are acceptable... Have you managed to settle the cost with Google, what was the outcome?

sillysaurusx6• 3 months ago

Back in 2020 I had a similar situation. Ended up charging $500 due to an overnight TPU training run using egress bandwidth across zones.

Google support was surprisingly understanding, after I explained the issue. They asked some clarifying questions. Then they said that they can offer a one time refund for this case.

Since then I was paranoid not to accidentally do it again. I don't know whether GCP would refund a second time.

Hamuko• 3 months ago

Which cloud provider actually prioritises features that cut off your money supply? Because AWS sure as shit doesn't either.

benterix5• 3 months ago

Amazon, Microsoft and Google don't offer hard cap. Most other/smaller public cloud providers do. The reasons are quite obvious.

miltonlost• 3 months ago

Sure it would probably make Google less money short term, but surely that's more preferable to providing devs with such a poor experience that they'd never recommend your platform to anyone else again.

Welcome to late-stage capitalism, where there is no long-term thinking, only short-term profit stealing, and Fuck You I Got Mine.

arcticfox2• 3 months ago

I get furious every time this comes up and somehow there are bootlickers ready to defend big tech on it.

My ~2 person small business was almost put out of business due to a runaway job. I had instrumented everything perfectly according to the GCP instructions - as soon as billing went over the cap the notification was hooked up to a kill switch, which it did instantly.

GCP sent the notification they offered as best practice 6 HOURS late. They did everything they could to not credit my account until they realized I had the receipts. They said an investigation revealed their pipeline was overwhelmed by the number of line items and that was the reason for the lag. ... The exact scenario it is supposed to function in. JFC.

Barbing7• 3 months ago

Almost wish the people defending it were paid. Almost more intelligent to rush to the defense if there were a direct financial benefit.

Part of it is possibly the curse of knowledge. Someone in the 99th percentile of cloud configuration experts simply can't recall their junior dev days.

bcjdjsndon• 3 months ago

I thought the pricing model was meant to be a benefit of the cloud? All of a sudden, shock horror, paying by the minute turns out to be no cheaper and maybe even more expensive than just doing it yourself

comrade1234• 3 months ago

Can you pre-load money into your account and have that be used until it's zero, at which time you have to load more? Deepseek does it this way.

ok123456• 3 months ago

No GCP is not prepay.

Maxious3• 3 months ago

https://ai.google.dev/gemini-api/docs/billing#prepay

Bridged77562• 3 months ago

No. I believe all major cloud providers are Pay As You Go. I think only Azure has a tier where you can run on free credits for a while.

hypercube33• 3 months ago

The only thing I've seen is in MECM (SCCM) the azure extension will hard shut down when you hit a limit. if you want.

pwdisswordfishs5• 3 months ago

There's a brand-new, Gemini-specific feature for that (as new as March 23), but historically the answer has tended to be "no" from all the cloud providers. Most giants and indies alike have always been strongly opposed to implementing this feature for business reasons. (When you run across something that does let you do things that way, it's one of a handful of exceptions.) Their response is to tell you to set up budget alerts, which is not a solution, as described in this post.

<https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...>

CWwdcdk7h• 3 months ago

Google doesn't allow disconnecting credit card from account unless you close it. That includes situation when you are just trying out free tier.

draygonia• 3 months ago

Does Google allow a privacy card that you can control whether an account is connected to it or not? That wouldn't help if someone racked up a ton of charges and Google bills daily, though.

Maxious3• 3 months ago

When your Prepay credit balance on the billing account hits $0, all API keys in all projects linked to that billing account will stop working simultaneously. Prepay credits apply only to Gemini API usage costs; you can't use them to pay for other Google Cloud services.

https://ai.google.dev/gemini-api/docs/billing#prepay

imafish2• 3 months ago

OpenAI also worked like this last time I used it - not sure if that's changed.

lxgr8• 3 months ago

I doubt most cloud providers are even technically ready for true prepaid billing (which requires things such as estimating and reserving funds prior to paid operations, corresponding real-time two-way interfaces instead of just eventually consistent billing event aggregation etc).

In early mobile networks, the feature set for prepaid used to always lag behind, since real-time billing wasn't really a design consideration from the beginning.

I suppose rather than taking on that extra work or offering a reduced feature set or by building something best-effort and taking financial responsibility for its failures, if cloud providers can just get away with making this the user's problem, why wouldn't they?

Illniyar• 3 months ago

I think the logistics of calculating cost in real time is something that is extremely hard. I don't think there is one big cloud service provider that has hard limits instead of alerts.

As long as they revert the charge when notified of scenarios like this , and they have historically done so for many cases, it's fine. It's an acceptable workaround for a hard problem and the cost of doing business ( just like Credit Cards accept a certain amount of loss to fraud as part of business)

zulban• 3 months ago

Ridiculous. They are clearly not trying at all. A hard wall preventing going over budget by 100x in a couple hours is not some devilishly complicated decentralized system problem.

Don't tote the party line.

Same reason why Azure AI only has easy rate limits by minute, not by day or week or month. Open source proxy projects do it easily tho. Think about the incentives.

Going over a hard cap by 3% would be a reasonable failure to make, not by 30000%.

EdwardDiego• 3 months ago

I think the logistics of calculating cost in real time is something that is extremely hard.

What makes you think that?

wongarsu• 3 months ago

Cutting off at the exact cent is difficult, but a hard limit that triggers within one dollar of the actual limit should really be possible

If for some resources you can't sample measurements fast enough you could weaken it to "triggers within one dollar or five minutes after cost overrun, whichever comes later". But LLM APIs are one of those cases where time isn't a factor, your only issue is that if you only check quota before each inference a given query might bring you over

Nathanba• 3 months ago

Why would it be hard to calculate cost? Multiply a fixed price * requests/time ? It doesn't have to be exact in real time, it just has to report something approximately useful in realtime.

It's absolutely not fine to be at the mercy of other people, that's what we buy cloud products or really any products for: So that we are not at the mercy of hardware faults, bad weather, bad teeth, hunger, thirst, [insert anything]

mexicocitinluez• 3 months ago

I'm guessing the answer is simply money. It's less expensive to deal with people like this this than it probably was to prevent it. Right now, they seem to run very sparsely, so ramp that up (if it's every 3 hours and they want to change to 5 minutes that's like a 6000% increase) and they're probably paying more than it costs to employ people to return credits or fears of people leaving.

It sucks, but that's unfortunately the world we live in until something changes.

The US could rely on an agency like the CFPB to prevent this, but that was gutted under the current admin.

cryptonym• 3 months ago

They don't have to compute it in real time. They can cut service when they detect it reached the cost and the difference is free of charge.

Overcharge protection doesn't have to be free. It could be +5% on prices or a fee of 25% when you reach the threshold.

They would have financial interest in calculating cost in real time and it'd magically become more and more precise over releases.

bossyTeacher• 3 months ago

As always, you will need to make lots of noise on here and similar channels visited by influential people so stuff can get actioned.

Leading tech companies in 2026, folks.

__natty__• 3 months ago

It's terrible that giant cloud providers such as Google or AWS doesn't allow for hard cap at project levels or prepaid. And that especially because alerts are delayed as author stated "We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours. By the time we reacted, costs were already around €28,000.".

alibarber• 3 months ago

Forgive my ignorance - but what's the payoff for fraudsters in getting access to a generative AI service for a short-ish period of time, before they get cut off?

With EC2 / GCC credentials, I could understand going all out on bitcoin mining - but what are they asking the AI to do here that's worth setting up some kind of botnet or automation to sift the internet for compromised keys?

varispeed2• 3 months ago

If they work for hostile state, the payoff is destruction of economy and social contract. Damage here, damage there. It all adds up.

lxgr8• 3 months ago

There are plenty of services offering AI inference at a discount. Some of these will be using your data for future distillation; others might be making use of bulk discounts and passing these through to a number of individual users (while taking on billing, support etc. risk) – and maybe some are just selling tokens falling off the back of a truck?

LelouBil• 3 months ago

Totally speculating here, but maybe they provide some sort of LLM as a service, and they rotate stolen API keys in the background so they don't have to pay anything ?

Or they use the LLMs for criminal purposes (like automated social engineering) and so the API key can't be traced to their personal info (but they could also use a local model for this, so I don't know).

Aurornis• 3 months ago

Early Generative AI was popular with spammers before it became mainstream because it could be used to write infinite variations of spam messages. Making each message unique is more likely to bypass spam filters.

There are also a lot of AI use cases that require a lot of token spend to brute force a problem. Someone might want to search for security exploits in a codebase but they don’t want to spend the $50,000 in tokens from their own money. Finding someone’s key and using it as hard as possible until getting locked out could move these projects forward.

croes2• 3 months ago

Generate phishing mails, spam mails, disinformation pictures and videos.

Youtube has plenty of scam ads where well known people try to get you to sign up for the WhatApp group for financial tips

pqnet• 3 months ago

Generating distillation data of a competitor's model could also be a valid reason to do that. You need a huge amount of tokens to do that (that you don't want to pay yourself), and you would like to use as many different accounts that can't be traced back to a single source to make it harder to detect the attempt and lead it back to you.

benterix5• 3 months ago

We had a budget alert (€80) and a cost anomaly alert, both of which triggered with a delay of a few hours
By the time we reacted, costs were already around €28,000
The final amount settled at €54,000+ due to delayed cost reporting

So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "hard cap it's technically impossible" etc.)

villgax• 3 months ago

Shirky’s principle at work is all

varispeed2• 3 months ago

This is clearly setup for VC backed companies where shareholders don't care about spend as long as they can brag about investing in this cool start up at dinner parties. Normal and true business should stay away.

Maxious3• 3 months ago

The Gemini API supports monthly spend caps at both the billing account tier and project levels. These controls are designed to protect your account from unexpected overages, and the ecosystem to ensure service availability

https://ai.google.dev/gemini-api/docs/billing#project-spend-...

rtkwe• 3 months ago

The problem is it's specific to that API and defaults to uncapped so people who aren't using it and haven't heard about the issues with the Firebase API keys probably won't have set them.

whywhywhywhy• 3 months ago

Why is the default uncapped then other than the hopes of billing people who screw up or get exploited.

nurettin3• 3 months ago

I'd buy the technically impossible angle.

Even if you manage to get your microservices to synch every penny spent to your payment account at realtime (impossible) you still have to waiver the excess, losing some money every time someone goes past their quota.

bartread2• 3 months ago

Sure, but 80 -> 28,000 -> 54,000 is a hell of a lot of slippage.

Trading platforms can guarantee a maximum slippage on stops, and often even offer guaranteed stops (with an attached premium), so I don’t see why Google and Firebase can’t do similar.

The way it works at present is ridiculous.

walthamstow2• 3 months ago

I'm with you. And what do you even do when the quota is breached, nuke the resources? People will complain about that just as much as overspends.

I don't buy the 'evil corp screwing people' angle either. They are making farrr too much legit money to care about occasionally screwing people out of 20k and 50k.

benterix5• 3 months ago

I invite you to look at the various solutions implemented by those public cloud providers that actually implemented this feature.

andreareina• 3 months ago

"I can only do the job pretty damn well, not perfectly, so might as well not try."

janandonly• 3 months ago

Yet another good reason to use a pre-paid service.

There are many to choose from now, like Openrouter.com, PPQ.ai, and routstr.com.

adriand2• 3 months ago

You mean openrouter.ai. And yes, on reading this blog post, I immediately reviewed my API keys in OpenRouter to make sure that they were capped. My prod key was capped at $20/day (phew!) but my dev key had no cap, which I just updated. What a horrible story.

ch0wn• 3 months ago

This should be illegal. If a contractor your hired to swap out a tile on your bathroom floor billed you for remodelling your back garden, you would obviously have the legal right to refuse that.

jubilanti2• 3 months ago

Not if your contractor had you first sign a 15 page contract that commits you to whatever costs they dream up and requires forced arbitration by a corporate friendly firm when any dispute arises.

Because that's somehow normal in today's tech world.

layer8• 3 months ago

My guess is that at least in Europe they would have a good chance fighting this in court and getting their money back, but it’s a pain having to go through such a lawsuit.

sofixa3• 3 months ago

Your analogy is well off.

You hire a contractor and agree they'll bill you per tile, regardless of how many tiles there are. They bill you per tile. End of story.

For a more acurate comparison, consider a utility. You agree to pay for your electic bill. It's not the utility's fault you invited all your friends who decided to run a crypto mining LAN party, and they can't cut you off lightly because it might literally kill you (e.g. you live in a hot place and rely on AC to stay alive).

Rekindle80902• 3 months ago

"We can either charge per tile, per job or on demand. Or you can have us on call for a year and get any of the former at a discounted rate." "Per tile. Lay tiles until I say stop" >you fall asleep "Wtf why are you still laying tile" "You said per tile and lay until you say stop. That'll be 50k please"

How is this the contractors fault?

Leomuck5• 3 months ago

That's actually crazy. So I can build a project I love, that does good, but somehow get in a situation where I'm accidentally paying 30.000€ (or 50.000€) to a big tech company? How is that fair? I mean yes, as a software engineer, you ought to reflect on all possible weaknesses, but there was a time when overlooking something meant something completely different than being down 30/50k. That is actually life-altering.

sdevonoes3• 3 months ago

It’s not fair. Google, Amazon, Microsoft… they have never played fairly. They will never do.

benoau• 3 months ago

Your kid can do this in a smartphone game designated suitable for children, heavily optimized to exacerbate the possibility, and depending on where you live they can just choose not to refund you.

When the FTC went investigating a decade-ish ago they found Facebook saying the quiet parts out loud: it was all extremely deliberate.

ai_slop_hater• 3 months ago

You can try implementing rate limiting and not exposing your API keys to the public.

sofixa3• 3 months ago

If that happens, you create a support ticket and AWS/GCP/Azure wave it, especially the first time. They're aware that billing per usage can have surprise effects, but at the same time they don't want to kill their customers' workloads and delete their data, so it is what it is.

ItsClo688• 3 months ago

agree. the real problem isn't that hard caps are "technically impossible" — it's that the incentive to build them is backwards. a hard cap that stops a runaway process costs the cloud provider money. a "budget alert" that fires after the fact costs the customer money. the 10-minute delay in billing processing is doing a lot of work in that logankilpatrick comment. at $4k/minute burn rates, that's still a $40k exposure window

startages• 3 months ago

Yeah, that the main reason I never use services like Google Cloud if I don't have to, it's impossible to have a hard cap, and anyone pretending to be an expert, is just off. Google says that they can't provide a hard cap because that would mean shutting down all your services..bla bla, but at least give users the option.

logankilpatrick2• 3 months ago

We have spend caps at the billing account level and the project level (developer set) in the Gemini API now. There is up to a 10 minute delay in processing everything but this should significantly mitigate the risk here: https://ai.google.dev/gemini-api/docs/billing#tier-spend-cap...

By default, new Tier 1 paid accounts can only spend $250 in a given month.

giancarlostoro• 3 months ago

It shouldnt mean shutting down all your services, it should mean not letting you provision new ones and limiting the scope of what you can continue doing.

aisaasbuilder4• 3 months ago

The providers will not ship hard caps because a hard cap is a revenue ceiling. They will ship soft alerts that fire late enough to be useless. The only answer is an independent layer between your config and the provider that does not have that incentive. Building exactly that at Traeco. traeco.dev

reaperducer• 3 months ago

hard cap it's technically impossible

These companies can sell your personal information in a microsecond in an advertising auction, but somehow can't figure out how to give you timely alerts that stop their cash flow.

Big shock.

TrackerFF• 3 months ago

It's like a fire alarm system that goes off 30 mins after the it senses a fire. Good stuff.

QuercusMax• 3 months ago

I was selling a house in a state I no longer lived in, and was under contract to close the sale, when I got an email from the water company. It told me they suspected based on my water usage that there was a leak on the properly.

There had been a very cold February night (like -15F) and a pipe froze inside the walls, and it was just absolutely gushing out. They sent me the email after it had been leaking for a WEEK. I asked a friend to check it out and she said that the laminate floor went "squish" when she stepped in the front door.

Fortunately I was covered by homeowner's insurance since I could prove that my heat had been on, but that was a very unpleasant "warning" to receive!

pfortuny• 3 months ago

But sending an email, not blaring...

harrouet• 3 months ago

As a manager I avoid Google Cloud for this kind of customer-service disasters; but as someone who has dealt with large-scale billing systems in the telecom world, probably similar to that of Google Cloud, I am not surprised that it takes 10 minutes to consolidate all the usage logs of a customer for billing.

For telephony, it sometimes takes days when roaming is involved.

You have to imagine TB/sec of data, if not more, coming from thousand of potential sources, and queuing for aggregation to the proper company account, all having to be auditable. This is not a small engineering feat and it can't be real-time.

With that said, telcos usually include in their business model around 2-3% of bad debt (i.e. revenue that won't get paid), which accounts for frauds like this one. Given that the customer seems in good faith and has taken measures upon being notified, Google should manage this bill shock a bit more elegantly.

Moreover, the fact that this happened immediately after this key opened the AI gates means that pirates permanently scan for the permissions of all the keys they could gathers. Google could and should detect that and act upon it.

sofixa3• 3 months ago

So much for the folks defending these three companies that refused to provide hard spending cap ("but you can set the budget", "you are doing it wrong if you worry about billing", "hard cap it's technically impossible" etc.)

Yes, it's technically+business impossible. To implement a hard cap, a bill never to go over, they'd have to cut your service, but also delete all your data in databases, object storage, data lake, etc. This is simply not an option, so they take the different option of authorising support to wave surprise surcharges / billing DDoSes.

plorkyeran• 3 months ago

You can have a hard cap on compute spend while letting storage go over. Surprise huge bills are approximately never due to storage.

benterix5• 3 months ago

This argument simply doesn't hold water - their (smaller) competition solved this problem over a decade ago.

Glemllksdf• 3 months ago

Srsly?

The mighty cloud provider can't solve this issue?

Google has second precision billing on compute.

Its not hard to define a base layer of allowed billing increase and adding this type of context to resource allocation.

You are not just suddenly creating a mlllion terabytes of data or a million db requests without supervision.

It could even be as simple as basic level caps like 100 euro / month, 1000, 10.000 etc.

And there is a difference between stoping everything before the spike happens vs. also deleting stuff.

aleksiy123• 3 months ago

For everyone here, you should be able to use quotas in order to set actual limits, you can lower them yourself as a practical solution.

https://docs.cloud.google.com/docs/quotas/view-manage

Quotas are real time or near real time.

Real time spend limits are probably never going to happen. Actual $ amounts are calculated by a centralized billing system offline in batch.

It sounds easy but it’s bonkers complicated, because of things like discounts, free tiers, committed usage, currency conversions and having to support every payment and deal structure in GCP.

Individual eng teams rarely actually think in dollar amounts, they think in the abstraction which is quotas.

nhuser22212• 3 months ago

Happened to me to, luckily only was 40$, restricted the api the next day. They were using gemini 3 flash which I am not using.

Moosdijk2• 3 months ago

That’s users, for ya! They will always find ways to use your product that you didn’t intend to or even knew about!

Moosdijk2• 3 months ago

Yet my phone service provider is able to cut off my internet access from the Kb I go over the limit…

fireant2• 3 months ago

"hard cap it's technically impossible" is really funny because every other provider manages it just fine. Even wrappers like OpenRouter enable you to set a hard cap on proxied Google resources, but Google themselves are unable to manage that inside gcloud.

time0ut• 3 months ago

It is scary building on the public cloud as a solo dev or small team. No real safety net, possibly unbounded costs, etc. A large portion of each personal project I do is spent thinking about how to prevent unexpected costs, detect and limit them, and react to them. I used to just chuck everything onto a droplet or VPS, but a lot of the projects I am doing lately need services from Google or AWS. I tend to prefer GCP at this point because at least I can programmatically disconnect the billing account when they get around to tripping the alert.

Bridged77562• 3 months ago

I wonder what happens if you just decide not to pay. Surely that would have some legal implications in the US, but what about elsewhere?

spacebanana7• 3 months ago

There are very few countries where consumer rights apply to B2B transactions, especially if it’s multiple people operating as a “small team”.

A solo dev however might be able to present themselves as a retail consumer, and leverage some trading standards related rules for unclear pricing or something similar.

wonchoi• 3 months ago

good

ozlikethewizard• 3 months ago

The top comment on the post physically hurt me. We've moved past the era of keep env files in code bases and are now actually serving them lol.

chinathrow• 3 months ago

Take them to court.

_nhh• 3 months ago

With AI there is NO justification in NOT DOING IT BY YOURSELF. Why use firebase or <technology-x> if you can generate <the-thing> by yourself and deploy to hardware you own or rent.

sdevonoes3• 3 months ago

That’s replacing Google with OpenAI/aanthropic/whatever. Same shit

post-it• 3 months ago

and deploy to hardware you own or rent.

Because this part sucks. I grew up fiddling with Linux. I don't want to play devops anymore. I want to write code and run it.

naturalauction• 3 months ago

We had this exact same problem (the key initially wasn’t a secret but became a secret once we enabled Gemini API with no warnings).

We managed to catch it somewhat early through alerting, so the damage was only $26k.

We asked our Google cloud support rep for a refund - they initially came back with a no but now the case is under further consideration.

I’d escalate this up the chain as much as possible.

turtlebits• 3 months ago

Slightly off-topic, but Backblaze B2 has usage caps that actually work. I have $0 cap on API requests, and yesterday when litestream burned through the free tier (defaults to replicating every second), I got a notice and requests stopped working until I upped my cap.

Havoc• 3 months ago

Don’t use GCP (and other big clouds) until they sort out their safeguards.

All three of the big cloud subreddits have stories like this on a regular basis

juancn• 3 months ago

These are all poorly designed systems from a CX perspective (the billing systems).

Billing is usually event driven. Each spending instance (e.g. API call) generates an event.

Events go to queues/logs, aggregation is delayed.

You get alerts when aggregation happens, which if the aggregation service has a hiccup, can be many hours later (the service SLA and the billing aggregator SLA are different).

Even if you have hard limits, the limits trigger on the last known good aggregate, so a spike can make you overshoot the limit.

All of these protect the company, but not the customer.

If they really cared about customer experience, once a hard limit hits, that limit sets how much the customer pays until it is reset, period, regardless of any lags in billing event processing.

That pushes the incentive to build a good billing system. Any delays in aggregation potentially cost the provider money, so they will make it good (it's in their own best interest).

bux932• 3 months ago

It's not typically a problem that usage is event driven. At least not for prepaid phone plans. Or debit cards. Or mailboxes. Or any myriad of prepaid or quota'd services. It's not rocket science, just a bad business practice on the part of Google.

orf• 3 months ago

Can you not see any relevant difference between an entire cloud platforms worth of APIs and… a prepaid phone plan?

fhn• 3 months ago

on a more positive note, you saved a few bucks not running your own server or database.

noplace1ikegone• 3 months ago

Google responded to your post so that’s good news. We all know the nature of APIs, but a secure transaction system is non-negotiable from Google and its peers for LLM API use. Right now LLM APIs are like unencrypted credit card numbers floating around.

rmoriz• 3 months ago

Crude Oil Futures, Natural Gas Futures, Google Cloud API keys.

the widow-maker list increases.

RA_Fisher• 3 months ago

Anthropic and Claude are running circles around Google / Gemini for me these days. Anthropic was quite helpful for a while but strange limit issues started popping up. The final thread was a bug that essentially broke my ability to develop. I moved over to Claude Code full time and haven't looked back. Opus 4.6 is awesome for accelerating probabilistic programming!

smcl• 3 months ago

It's incredible that in 2026 your best bet for getting support from Google is still posting to HN and hoping a Product Owner at Google takes pity on you (or feels shamed...)

DaedalusII• 3 months ago

on the one hand if you play with petrol you cant complain about burning down your garage

on the other hand hetzner sell ipv4 instance with no security on by default, just raw ubuntu 24.x

within 3-4 days of deploying one, it will be hacked and have crypto miners installed unless additional special config is added. i do wonder what % of hetzner vps instances are compromised

perdomon• 3 months ago

Does the blog post explain how this happened exactly? Did he leak his API key in frontend code somehow, or was his project itself vulnerable to misuse? I'm curious how someone racked up 30k in a few hours.

sachinag• 3 months ago

Hey folks, I just wanted to drop a quick note here that there’s a way to stop billing in an emergency that’s officially documented on the Google Cloud documentation site: https://docs.cloud.google.com/billing/docs/how-to/disable-bi... . You can see the big red warning that this could destroy resources that you can’t get back even if you reconnect a billing account, but this is a way to stop things before they get out of control. This billing account disconnect goes all the way to implement a full on “emergency hand brake” that “unplugs the thing from the wall” (or whatever analogy you prefer) without you having to affirmatively do it yourself.

https://docs.cloud.google.com/billing/docs/how-to/modify-pro... and https://docs.cloud.google.com/billing/docs/how-to/budgets-pr... are other documented alternatives to receive billing alerts without the billing account disconnect.

The billing account disconnect obviously shouldn’t be used for any production apps or workloads you’re using to serve your own customers or users, since it could interrupt them without warning, but it’s a great option for internal workloads or test apps or proof of concept explorations.

Hope this helps!

dorgo• 3 months ago

There's a delay between incurring costs and receiving budget notifications, so you might incur additional costs for usage that hasn't arrived at the time that all services are stopped.

This delay may be hours or days. I managed to spend $400 in 5 minutes.

lokimedes• 3 months ago

Oh the days when these scenarios just lead to a slowdown of the database server, felt by everyone, not just accounting.

arjie• 3 months ago

Surprised they don’t have usage limits. E.g. you can’t get many IPs from AWS for your region until you request a limit increase. The UX for these kinds of things seems like it should default to low and allow easy increasing.

PufPufPuf• 3 months ago

For personal projects, is there a cloud service that has actual working spend caps? I would perhaps try using a cloud service if I wasn't exposing myself to a risk of losing my yearly income by a small mistake. Or is renting a VPS the only sensible option?

william0353• 3 months ago

Hi I am just curious the reason behind it as I have a firebase app with firebase ai logic service as well.

Is that the apiKey below which was used for web sdk init?

const firebaseConfig = { apiKey: XXXX, authDomain: XXX

Did Zanbezi enabled app check? This is kind worrying...

};

linkregister• 3 months ago

From the response from the Gemini product lead:

We are moving to disable the usage of unrestricted API keys in the Gemini API, should have more updates there soon.

It's unacceptable the contract for client-side keys was broken in this manner, and doubly bad that it's taken so long for Google to remediate this issue. The Gemini team needs to publish a postmortem to explain what broke down in the engineering process to allow this to happen.

context: https://news.ycombinator.com/item?id=47156925

bwpw• 3 months ago

The scarier version of this problem is coming. Imagine AI agents making API calls across multiple vendors. Each vendor tracks usage in isolation. But no one knows what the agent is spending across all vendors. Nobody building the cross-vendor spending cap today.

ButlerianJihad2• 3 months ago

Back in 2020–21, we were teaching our students how to stand up and configure cloud services, and I decided that a good extension of my homelab would be in AWS, so that I could learn basic cloud administration.

I was using the Free Tier for starters, of course. I managed to start up a working MediaWiki server on a Linux machine in EC2. I began to explore some of the more esoteric options and always checked out the extra-secure methods, and IAM and so forth.

My MediaWiki had a lot of spammers registering accounts. They weren't actually able to make edits, but I couldn't seem to stop them from creating user accounts. And I always felt rather... naked in terms of securing the Linux system itself. It seemed like the entire Internet had an Eye of Sauron focused on my open TCP ports and they were port-scanning it and running pentests 24/7. I honestly couldn't keep up!

Ultimately, I did realize that I could never constrain the budget to an affordable $20 or $30. Signs seemed to indicate that any malicious traffic could crank up my network egress costs alone! There were some rudimentary controls but they would never permit a full-scale shutdown of all services that could actually cost money.

So I shut down the cloud services and abandoned my Amazon AWS account. Migration to the cloud might seem like a good value proposition for any business that can't handle its own machine rooms or its own I.T. team to manage physical infrastructure. But it's an unconstrained cost nightmare waiting to happen for basically anyone of any scale. I would never recommend it, for personal or business use, until that aspect is somehow brought under control.

€54k spike in 13h from unrestricted Firebase browser key accessing Gemini APIs

Related Stories