Gemini API Bills Keep Hitting Devs. Restrict Your Keys Before June 19.

Note: This post was written by Claude Opus 4.7. The following is a synthesis of Google’s published documentation on the Gemini API key deprecation timeline, TruffleSecurity’s original disclosure, contemporary reporting from The Register, BleepingComputer, Tom’s Hardware, CSO Online, and The Hacker News, and victim accounts on Reddit’s r/googlecloud and the Google AI Developer Forum.

These stories keep landing. A small dev team or a solo builder wakes up to a Google Cloud bill of thousands — sometimes tens of thousands — of dollars, charged in hours by an attacker who scraped a Google API key out of public code and used it to run Gemini calls until the charges cleared. The team had not been doing anything wrong; the key in question was usually a Maps or Firebase identifier — the kind Google has spent more than a decade calling not a secret. The team’s only “mistake” was enabling Gemini on the same Google Cloud project, at which point every existing key in that project silently gained the ability to make billable Gemini API calls.

The pattern has produced enough victims to identify by name and amount. A team of three in Mexico saw $82,314 burn over 48 hours in February. A Japanese company saw $44,000 climb to $128,000 even after pausing the API. Jesse Davies, an Australian solo developer with a $10 AUD budget cap, woke up to a $25,672.86 AUD bill — and discovered that nine Google Cloud safety features that should have prevented it were turned off by default. Rod Danan, CEO of Prentus, watched $10,138 hit his card before he could kill the API minutes later. Isuru Fonseka, a Sydney developer, took AUD $17,000 (~$12,000 USD). A Mexican developer posting to Google’s own developer forum on May 5 reported MXN $40,000 in unauthorized charges on May 2, likely sourced from an April Vercel security incident that exposed environment variables; two other developers replied in the same thread with similar Vercel-linked Gemini bills. On May 13, The Register published a follow-up story specifically on victims fighting Google for refunds — Google reimbursed the two developers quoted in that piece after the article ran, while continuing to refuse refunds elsewhere. Cybernews has logged single-incident losses of $67,000 in 19 hours and €54,000 in 13 hours.

A separate failure compounds the speed problem: spending caps that Google customers had set at $250 were, in several documented cases, automatically upgraded to $100,000 without user consent once an account hit roughly $1,000 of lifetime spend and 30+ days of age. Google’s own cost-anomaly detection flagged Tecnometria’s May 2 spike as a “~127× deviation” from baseline in real time — and the charges kept going anyway.

This is not an isolated February incident. It is an ongoing wave driven by an architectural defect TruffleSecurity disclosed in February and that Google has not yet fixed at the root: keys silently inherit new API scopes whenever the parent project enables a new service. Three months later, Google has published a different kind of remediation — a calendar — and any IT director with old Google API keys floating around an organization has a calendar to respect.

The two dates

May 7, 2026. The Gemini API began blocking unrestricted keys that have been dormant for an extended period. Affected keys carry a “Blocked” tag on aistudio.google.com/api-keys and must be replaced — there is no reactivation path. This deadline has already passed.

June 19, 2026. Google will discontinue support for all unrestricted Gemini traffic keys, dormant or active. From Google’s own documentation: “Starting June 19, 2026, to improve security, the Gemini API will discontinue support for unrestricted traffic keys. This means that your Gemini API requests will fail if you don’t take action.”

The May 7 change has limited blast radius; the dormant-key population is small. June 19 is the date that matters.

What “unrestricted” means here

A Google Cloud API key is unrestricted when it has no API restriction, no application-credential restriction (HTTP referrer, IP address, Android app, iOS bundle), and no scope binding. Created via the Cloud Console, every new key defaults to unrestricted. Once unrestricted, that key string authenticates to every API enabled in its parent project — Maps, Firebase, YouTube, Translate, Vision, and the Generative Language API (Gemini) all answer to the same string.

Restriction binds the key to a named subset of APIs. Restricting a key to “Generative Language API” means the key can still call Gemini but cannot, for example, hit Maps. Conversely, a key restricted to “Maps JavaScript API” cannot reach Gemini.

The June 19 cutoff applies only to Gemini. A key restricted to Maps will keep working on Maps; it just stops authenticating to Gemini — which is what an IT director who never wanted Gemini access on the Maps key actually wants.

What to do this week

The work falls into three parts: inventory, restrict, confirm.

Inventory. Visit aistudio.google.com/api-keys. The page shows a banner for any unrestricted keys in projects you own and lists each key’s service usage over the past 90 days. For organization-wide visibility, Google Cloud’s API Keys API exposes the same data via gcloud:

gcloud projects list --format="value(projectId)"

gcloud services list --enabled --project=PROJECT_ID \
    --filter="name:generativelanguage.googleapis.com"

gcloud services api-keys list --project=PROJECT_ID

gcloud services api-keys describe \
    projects/PROJECT_NUMBER/locations/global/keys/KEY_ID \
    --project=PROJECT_ID

The third command lists the keys in a project. The fourth shows the restrictions block on a specific key — empty means unrestricted. Run them across every project that has ever enabled the Generative Language API. gcloud services api-keys --help lists the rest of the verbs.

Restrict. For each unrestricted key, decide which APIs it actually needs.

If the key was created in AI Studio for Gemini work and is used only for Gemini calls, click Restrict to Gemini API on the AI Studio key page. This is the one-click fix Google recommends.
If the key powers Maps, Firebase, or YouTube and was never meant to reach Gemini, restrict it to those APIs in the Google Cloud Console under APIs & Services → Credentials. The June 19 change will then take the Gemini privilege away from it automatically.
Application-credential restrictions (HTTP referrer, IP range, Android app signing certificate, iOS bundle ID) are independent of API restrictions and worth adding alongside, but they do not by themselves satisfy Google’s June 19 requirement.

Confirm. After restricting, re-run gcloud services api-keys describe and check that the restrictions block lists the intended APIs. The AI Studio page also reflects the change within a few minutes.

What is and isn’t fixed

The June 19 cutoff moves the operational risk in one direction. An attacker who finds a restricted Maps key in your public JavaScript can no longer use it to run Gemini until your billing limit catches up. That is a real reduction in exposure.

The underlying architectural defect has not been changed. A Google Cloud project is still the unit of authorization scope, and adding a new service to a project still expands every old key’s reach by default. The June 19 change addresses this class of expansion by forcing existing Gemini-eligible keys to be restricted; it does not change the model for whatever high-cost API Google enables on the same project ID-as-authorization-scope plumbing in 2027. TruffleSecurity’s observation in February still holds: “the pattern we uncovered here (public identifiers quietly gaining sensitive privileges) isn’t unique to Google.”

Treat June 19 as the date Google’s long-standing guidance — that Maps and Firebase keys are “not secrets” — formally stops being load-bearing on any project that has ever opted into Gemini. After that, every Google API key in the environment needs to be evaluated for the scope it has now, not the scope it was originally issued for.

The two dates

What “unrestricted” means here

What to do this week

What is and isn’t fixed

Sources

Security Scorecard