Your AI API Key Is Already Being Scraped

A developer in the EU just got a €54,000 Gemini bill in 13 hours. Google called it valid usage and would not refund a cent. This is not a horror story. This is a warning about architecture decisions that the industry has been making wrong for years, and that most developers do not even know they are making.

The €54K Is Not The Problem. The Architecture Is.

Google's anomaly alerts fired at €28,000. The monthly budget was €80. The alert came hours too late to matter. Google reviewed the logs, decided the API calls were made with a valid key, and classified the charges as legitimate. No refund.

The thread on HN has multiple similar incidents. A developer in the US lost $26,000 this way. Another lost $6,900. These are not edge cases. They are the first wave of a problem that is baked into how Firebase AI Logic works.

Google Will Not Save You

I keep seeing people say the lesson is to set budget alerts. That is not the lesson. Budget alerts are software notifications. They fire after the fact. The €54K bill was accumulating in real time while the owner had no idea. Google knows this because they have the data. They chose not to intervene automatically.

When the bill came in, Google looked at the API logs, saw valid calls from a valid key, and said there is nothing we can do. That is their position. They are not wrong. From their perspective, an API key is an API key. If someone uses yours to call their API, the usage is yours to pay.

Anomaly detection is not protection. It is documentation after the fact. The only real protection is a hard spend cap that actually stops the service before the bill crosses a threshold you cannot afford.

What Small Businesses And Agencies Need To Do Right Now

If you are building anything with Firebase and AI APIs, assume your browser key is already being scraped. Not might be. Is. It takes minutes to write a script that pulls keys out of browser-based Firebase configs, and there are entire services built around doing exactly that at scale.

Go to Google Cloud Console today. Restrict your browser keys to specific APIs, specific HTTP referrers, and specific IP ranges if you can. Set a project spend cap. Set an account-level billing cap. These are not paranoia settings. They are basic hygiene that most developers skip because the defaults are permissive and the documentation does not make the risk clear.

If you are building client projects with AI APIs, you need to have a conversation with every client about this risk. The billing model is broken for unpredictable usage. If a client's end users can hit an AI endpoint through a browser, the cost surface is exposed. You either need to proxy everything server-side, use prepaid credits that cannot exceed a set amount, or build systems that fail safely and loudly when costs spike above a threshold.

One Action To Take This Week

Go to Google Cloud Console right now. Find every browser-based Firebase project that has AI API access. Set a project spend cap. Even if you think you know what your usage looks like, set it lower than you think you need. The €54K bill came from a project that had a budget of €80. The difference between €80 and €54,000 was a key that was not restricted.

This is not a Firebase problem. It is an industry-wide pattern. The same risk exists anywhere you have client-side API keys calling AI services. Check your other providers. Set hard caps on all of them. Assume that if a key can be found, it will be found.

The billing surprise era is here. Google is not going to warn you before the bill arrives.

Sources: - Google discussion forum: https://discuss.ai.google.dev/t/unexpected-54k-billing-spike-in-13-hours-firebase-browser-key-without-api-restrictions-used-for-gemini-requests/140262 - Hacker News discussion: https://news.ycombinator.com/item?id=47791871