The Core Issue
For over a decade, Google told developers that API keys (like those for Maps) were not secrets and could be safely embedded in public websites. However, with the launch of Gemini, those same keys now silently grant access to sensitive AI data and billing if the Gemini API is enabled on the project.
What Changed?
- Retroactive Privilege: A key deployed publicly for a harmless service (e.g., Maps) automatically becomes a credential for the Gemini API if that service is enabled later—with no warning to the developer.
- Insecure Defaults: New API keys default to “Unrestricted,” working for every enabled API, including Gemini.
The Risk
An attacker can simply grab a key from a website’s source code and use it to:
- Access private data stored in Gemini (uploaded files, cached content).
- Incur huge charges by running up the victim’s Gemini API bill.
- Exhaust quotas, shutting down legitimate services.
Scale of the Problem
A scan of public web data found 2,863 live Google API keys vulnerable to this issue, including keys on websites belonging to major financial institutions and even Google itself.
Disclosure & Google’s Response
Reported in Nov 2025, it was initially dismissed but later accepted as a bug. Google’s planned fixes include: new keys defaulting to Gemini-only, blocking leaked keys, and proactive notifications to affected owners.
What You Should Do
- Check if the “Generative Language API” is enabled in your GCP projects.
- If it is, audit your API keys for unrestricted access or those that specifically allow Gemini.
- Verify those keys aren’t public (in code, websites, repos). If they are, rotate them immediately.
The fundamental problem is that legacy, non-secret identifiers were retroactively turned into sensitive credentials, creating a massive, silent security risk.
To see more about the issue check: https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules