For over a decade, Google’s official documentation described Google Cloud API keys (the AIza... format) as non-secret identifiers. Developers embedded them in HTML or mobile apps to enable services such as Google Maps, Firebase, and YouTube, with the expectation they posed no security risk.
That guidance was accurate—but until Google enabled the Gemini (Generative Language) API on Cloud projects. With that single change, API keys that were never intended to be private credentials now grant read/write access to sensitive AI services and project data.
Understanding Google API Keys
What They Were
Google API keys historically:
- Identify a project for billing and quota tracking.
- Are safe to embed in front-end code.
- Are not an authentication mechanism—just a project scope indicator.
Example usage for Maps:
<script src="https://maps.googleapis.com/maps/api/js?key=AIza..."></script>
Google Maps docs explicitly placed these in HTML with no warnings about confidentiality.
What Changed with Gemini
When the Gemini API (a.k.a Generative Language API) is enabled on a Google Cloud project:
- All existing API keys (including those embedded publicly) get access to that API.
- This happens silently—no warnings, no notices, no prompts.
Two issues arise:
- Retroactive Privilege Expansion
A key created for Maps in 2019 suddenly becomes capable of sensitive AI actions. - Insecure Default Scopes
Newly generated keys are unrestricted by default—they automatically apply to all enabled services, including Gemini if activated.
The Security Impact
Truffle Security conducted a massive scan of the November 2025 Common Crawl dataset and found 2,863 Google API keys exposed publicly that now authenticate to Gemini endpoints.
Affected keys were embedded in:
- Client-side JavaScript
- Static HTML
- Public GitHub repositories
- Legacy project artifacts
The consequences are severe:
Elevated Access From Public Key
An exposed API key can now be used to:
- Access private uploaded files via Gemini endpoints.
- Retrieve cached content stored by the AI service.
- Charge billing for API usage, potentially running up large costs.
- Deplete project quotas, disrupting legitimate internal traffic.
Example PoC request with a leaked key:
curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"
Rather than returning 403 Forbidden, a valid response with sensitive data may be returned if the key has Gemini access.
It’s Not Just Theory
Truffle Security verified this against real keys—including some belonging to Google’s own infrastructure—that were publicly deployed since 2023, long before Gemini existed. These keys responded with legitimate AI model listings at /models.
Why This Happened: Two Design Decisions
No Key Separation
Google reuses the same API key format (AIza...) for both:
- Public identification (Maps, YouTube, etc.)
- Sensitive authentication (Gemini) if enabled on the project
There’s no clear architectural separation between public vs. private keys.
Insecure Default Permissions
When developers create new API keys:
- They default to unrestricted access to all enabled services.
- The console warns about unauthorized usage but does not explicitly flag the risk of public keys being treated as credentials.
Detection and Full Disclosure Timeline
- Nov 21, 2025: Truffle Security reported the issue to Google.
- Dec 2025: Google initially considered the behavior intended but later reclassified it as a bug after evidence was shared.
- Jan-Feb 2026: Google expanded leaked credential detection and began blocking API keys known to be exposed. A root-cause architectural fix was still in progress when the 90-day disclosure window ended.
These steps mitigated some exploitation but many older keys remain live and potentially dangerous.
Mitigation: What Developers Should Do
1. Audit Enabled APIs
Check every GCP project for the Generative Language API:
Console Path:IAM & admin → APIs & Services → Enabled APIs & Services
If it’s not enabled, the specific Gemini escalation risk does not apply.
2. Review API Key Permissions
Navigate to:
APIs & Services → Credentials
For every API key:
- Check if it’s Unrestricted.
- Check if it lists Gemini API in allowed services (if enabled).
Any unrestricted key with Gemini access is a credentials risk.
3. Find Exposed Keys in Your Codebase
Search public source code, build artifacts, and web assets for:
AIza…
Keys found here that also have Gemini access must be rotated immediately.
Tools like TruffleHog can help find and verify live keys with access:
trufflehog filesystem /path/to/your/code --only-verified
This goes beyond regex matching to test whether the key is actually active.
4. Follow Key Least-Privilege Practices
- Restrict API keys by service and platform:
- Allow only Maps, Firebase, etc. if relevant.
- Avoid unrestricted keys whenever possible.
- Use IAM/Service Accounts for any operation needing authentication.
- Rotate keys regularly and monitor usage metrics.
These are essential security hygiene practices in any modern cloud environment.
Broader Lessons
This incident highlights a key architectural pitfall in the age of AI:
Credentials and privilege assumptions that were safe in a pre-AI world can become critical vulnerabilities when the platform surface expands.
API keys that once merely identified a project now act as authentication vectors for powerful services. Static assumptions about credential sensitivity are no longer valid.
Developers and platform designers alike must:
- Treat all keys as potentially sensitive unless explicitly scoped otherwise.
- Ensure that services that require authenticated access use distinct, secret credentials.
- Avoid broad defaults that elevate privileges silently.
Final Takeaway
Google API keys were once safe to expose. With the advent of Gemini, that era is over—and neither developers nor documentation fully anticipated the consequences.
The safety of your cloud environment now depends on careful key management, proactive auditing, and embracing least-privilege credentials. As platforms evolve, so too must security practices.
