For over a decade, Google told developers something reassuring: API keys used for services like Maps, Firebase, and YouTube are not secrets. Embed them in your HTML. Put them in your JavaScript. Don’t worry about it.
That guidance is now dangerously outdated and thousands of organizations may not know it yet.
What Changed
Security researchers at Truffle Security discovered a quiet but significant privilege escalation affecting Google Cloud API keys. The issue stems from how Google designed its API key architecture: all keys share the same AIza... format, regardless of what they’re meant to do. For years, that was fine — a Maps key was just a billing identifier, not a sensitive credential.
Then Gemini arrived.
When the Gemini API (Generative Language API) is enabled on a Google Cloud project, existing API keys in that project, including ones sitting in public JavaScript, can silently gain access to sensitive Gemini endpoints. No warning. No confirmation dialog. No email notification.
That means a developer who embedded a Maps key in their website three years ago, following Google’s own instructions, may have unknowingly handed attackers a live Gemini credential the moment a teammate enabled the Gemini API for an internal prototype.
The Scope of the Problem
Truffle Security scanned the November 2025 Common Crawl dataset — a ~700 terabyte archive of public web pages — and found 2,863 live Google API keys exposed on the public internet that could authenticate to the Gemini API.
The affected organizations included major financial institutions, security companies, recruiting firms, and Google itself. Researchers confirmed that one of Google’s own publicly-deployed keys, originally used as a project identifier since 2023, successfully returned a 200 OK response from Gemini endpoints.
An attacker doesn’t need to breach any infrastructure to exploit this. They simply view a webpage’s source code, copy the AIza... key, and run a basic API call. From there, they can access private uploaded files and cached Gemini content, run up substantial AI usage bills (potentially thousands of dollars per day), and exhaust API quotas — effectively taking down legitimate services.
Current Status
Google has acknowledged the issue and taken meaningful steps. They’ve expanded their leaked-credential detection pipeline, begun restricting exposed keys from accessing Gemini, and committed to addressing the root cause. Their published roadmap includes scoped defaults for new AI Studio keys, automatic blocking of discovered leaked keys, and proactive notifications to affected users.
However, as of the 90-day disclosure window closing on February 19, 2026, the root-cause fix is still in progress. Many organizations with older, publicly-deployed API keys remain potentially exposed — and Google has not yet confirmed a plan to proactively notify all affected project owners.
What You Need to Do Right Now
If your organization uses any Google Cloud services — Maps, Firebase, YouTube Data API, or anything else — take these steps immediately:
1. Check for the Generative Language API. In the GCP Console, go to APIs & Services > Enabled APIs & Services and search for “Generative Language API” across every project in your organization. If it’s not enabled, you’re not affected by this specific issue.
2. Audit your API keys. If the Generative Language API is enabled, go to APIs & Services > Credentials and review every key. Any key that is “Unrestricted” or explicitly lists the Generative Language API as an allowed service can access Gemini.
3. Check whether those keys are public. This is the critical step. Search your client-side JavaScript, public GitHub repositories, and build artifacts for any AIza... key that has Gemini access. Prioritize your oldest keys — they’re most likely to have been deployed publicly under the old “API keys aren’t secrets” guidance.
4. Rotate any exposed keys immediately. There’s no patch to wait for here. If a key with Gemini access is publicly visible, rotate it now.
5. Scan your codebase. Tools like TruffleHog can scan codebases and CI/CD pipelines to identify live Google API keys with Gemini access, not just pattern-match for the key format.
The Bigger Implication
This incident is a preview of a recurring problem in the AI era. As organizations rapidly bolt AI capabilities onto existing platforms, the attack surface of legacy credentials expands in ways nobody planned for. A credential that was safe by design in 2022 may be a serious liability in 2026 — not because anyone made a mistake, but because the rules quietly changed.
The lesson isn’t just about Google API keys. It’s about the assumption that credentials are static risks. When platforms expand what a key can do, every organization needs a way to know that — and right now, most don’t have one. Periodic credential audits and least-privilege key scoping aren’t optional hygiene anymore; they’re essential security practice in a world where platform capabilities evolve faster than developer awareness.
References & Sources
| # | Source | URL |
|---|---|---|
| 1 | Truffle Security Co. — “Google API Keys Weren’t Secrets. But then Gemini Changed the Rules.” (Feb 25, 2026) | https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules |
| 2 | Google Firebase Security Checklist — “API keys are not secrets” | https://firebase.google.com/support/guides/security-checklist#api-keys-not-secret |
| 3 | Google Maps JavaScript API Documentation — Get API Key | https://developers.google.com/maps/documentation/javascript/get-api-key |
| 4 | Google Gemini API — Security Measures for Leaked Keys (Google’s remediation roadmap) | https://ai.google.dev/gemini-api/docs/troubleshooting#googles_security_measures_for_leaked_keys |
| 5 | Common Crawl — November 2025 Dataset (used in Truffle Security’s scan) | https://data.commoncrawl.org/crawl-data/CC-MAIN-2025-47/index.html |
| 6 | TruffleHog — Open-source secret scanning tool | https://github.com/trufflesecurity/trufflehog |