For a decade, Google's documentation said the same thing. The AIza... key format — the one powering your Google Maps embed, your Firebase auth, your Places autocomplete — is a public identifier. Embed it in client-side JavaScript. Ship it in your Android APK. It's not a secret.

That guidance was correct. Until it wasn't.

On February 25, 2026, Truffle Security published a finding that broke that contract: 2,863 Google API keys, deployed in the wild for public-facing services, now silently authenticate to Gemini endpoints. The keys hadn't been stolen or misused in any novel way. Their scope had been expanded without notification.

The billing followed fast.

How the scope expanded

The mechanism isn't complicated. When you enable the Generative Language API — the backend behind Gemini — in a Google Cloud project, every existing API key in that project automatically inherits Gemini access. No email. No audit log entry flagging the change. No required opt-in.

Google Cloud uses one key format, the AIza... token, across many different APIs, treating it simultaneously as a public identifier in some contexts and as an authentication credential in others. For a decade, the "public identifier" interpretation was safe because all Google Cloud APIs had roughly comparable blast radius. Then Gemini arrived, with Veo 3 video generation at non-trivial per-second rates, and the rules of the room changed — without the room being told.

CloudSEK's analysis of top Android apps found hardcoded AIza... keys throughout — baked into APKs following Google's own guidance for Maps and Places. Every one of those keys now potentially authenticates to Gemini.

There's also a compounding issue with revocation. Per TechCrunch (May 24): Google's revocation propagates gradually across infrastructure, leaving deleted keys valid for up to 23 minutes. During that window, success rates reportedly exceeded 90% in some minutes, giving attackers time to exfiltrate cached conversation data and Gemini-generated outputs.

The disclosure timeline

Truffle Security submitted their report to Google's Vulnerability Disclosure Program on November 21, 2025. Google triaged on November 25 and classified it "Intended Behavior." Only after Truffle provided examples from Google's own infrastructure — keys on Google product websites — did the classification change. On December 2, 2025, Google reclassified it as a bug, upgraded severity, and requested Truffle's full list of 2,863 exposed keys.

The fix took another six months. The June 19, 2026 patch is what came out of that window — and in the gap, developers kept receiving five-figure bills.

The bills

The Register reported in March 2026 that one developer was charged $82,314 overnight — up from a typical $180 monthly spend. Per TechCrunch (May 24): Rod Danan, CEO of interview-prep platform Prentus, was billed $10,138 in roughly 30 minutes. Mostly Veo 3 video generation and Gemini image output — services he had never turned on. A Sydney developer woke up to charges of roughly AUD $17,000 despite believing he had a $250 spending cap. Google's developer forum accumulated cases in the tens of thousands of rupees. More to come, probably — the disclosure was public in February and the June 19 fix hasn't shipped yet.

Multiple developers report that Google denied their refund requests, citing "no evidence of fraud." The framing is worth pausing on. Fraud implies an actor operating outside the system. What happened in most of these cases was an actor operating exactly inside the system Google built — using a key that Google's documentation said was safe to publish, calling an API Google silently attached to it. Whether that satisfies Google's "fraud" test is a legal question. Whether it breaks a reasonable developer expectation is not.

Source spread

• Truffle Security — "Google API Keys Weren't Secrets. But then Gemini Changed the Rules." — skeptic. Primary technical disclosure. Reported November 2025, published February 25, 2026. Full disclosure timeline and 2,863 key count sourced here.
• The Register — $82K Gemini API bill, March 3, 2026 — skeptic. First major financial-impact report.
• The Register — users fight for refunds, May 13, 2026 — skeptic. Documents pattern of refund denials.
• TechCrunch — "Everyone is navigating AI security in real time — even Google," May 24, 2026 — builder. Most recent; adds Danan/Prentus case, revocation window details.
• Zuplo — API key security lessons — builder. Independent scope analysis confirming ~3,000 key exposure.
• CloudSEK — hardcoded keys in Android apps — skeptic. Documents the embedded-key problem in shipped mobile apps.

Pros & cons

What's improving:

• Google reclassified this from "intended behavior" to a bug in December 2025. That took six weeks and examples from Google's own infrastructure, but the reclassification is real.
• The June 19, 2026 patch prevents new keys from accessing both Gemini and Maps simultaneously. The architecture that created this problem gets corrected for future keys.
• Google says it has implemented proactive measures to detect and block leaked keys attempting Gemini access. Some developers have confirmed this detection exists in practice.

What's still broken:

• June 19 patches new key creation only. Existing deployed keys with Gemini access are not automatically updated. If you don't act, the fix doesn't help you.
• Developers following Google's documented guidance are being denied refunds. The financial fallout is sitting with the people who did what they were told.
• The 23-minute revocation propagation window is architectural. It doesn't close with the June 19 patch.
• AIza... keys hardcoded in shipped Android APKs cannot be remotely recalled without a forced app update. If your key is baked into a shipped binary, you need to rotate it and push an app update.

What builders need to know

• Audit every API key in your projects at console.cloud.google.com. Check the "API restrictions" setting on each key. Any key showing "Don't restrict key" is at risk if your project has the Generative Language API enabled.
• The June 19 fix does not retroactively protect existing keys. It prevents new keys from being unrestricted. Your deployed keys need manual remediation — add explicit API restrictions to each one.
• If your app has a hardcoded AIza... key in a shipped APK, assume it's exposed. Rotate to a new key with explicit restrictions, then push an app update. The old key remains vulnerable until all users are on the new version.
• Set a Gemini API spending cap if you're using Gemini intentionally. One that cannot be exceeded in 30 minutes is a reasonable floor given the Veo 3 billing rates.
• If you've received unauthorized charges, document everything and escalate to Google Cloud support with the Truffle Security disclosure as context. Per The Register's reporting, refund denials have been the initial response — they are not necessarily the final one.

Further reading

• Truffle Security — "Google API Keys Weren't Secrets. But then Gemini Changed the Rules." — primary disclosure with full timeline
• The Register — $82K Gemini API key bill, March 3, 2026 — first major financial-impact report
• The Register — users fight for refunds, May 13, 2026 — pattern of refund denials documented
• TechCrunch — "Everyone is navigating AI security in real time — even Google," May 24, 2026 — most recent comprehensive coverage
• Zuplo — API key security lessons — practical developer guidance
• CloudSEK — hardcoded keys in Android apps expose Gemini — mobile app exposure analysis