Topic starter
19/10/2026 5:09 pm
TL;DR: Truffle Security found that Google API keys long treated as public identifiers can now silently gain Gemini access, and that 2,863 live keys were exposed on public webpages through this privilege expansion. The real control failure is assumption collapse: a key once safe to publish can become a sensitive credential when another API is enabled.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “Google API Keys Weren't Secrets. But then Gemini Changed the Rules.”.
By the numbers:
- We identified 2,863 live Google API keys vulnerable to this privilege-escalation vector in the November 2025 Common Crawl dataset.
Key questions
Q: What breaks when an API key can gain new privileges after it is deployed?
A: The assumption that the key's risk is fixed at issuance breaks first.
Q: Why do public API keys become dangerous when a platform adds new sensitive services?
A: They become dangerous because exposure and authorisation merge.
Q: How can security teams tell whether a leaked API key is actually exploitable?
A: Check both exposure and current scope.
Practitioner guidance
- Audit enabled services before trusting existing keys Check every project for newly enabled AI or sensitive APIs, then compare each existing key's allowed services against the current project surface.
- Separate publishable and secret credentials Stop using the same key format for both public identification and sensitive authentication where the platform cannot enforce a hard boundary.
- Revalidate old keys after service changes Review older keys first, because they were often deployed under a safer assumption and may have inherited new rights later.
Bottom line: A Google API key can become a Gemini credential after deployment, which means the original issue is not only leakage but retroactive privilege expansion.
What's in the full article
Truffle Security's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact proof-of-concept requests used to verify Gemini access from legacy Google API keys
- The disclosure timeline with Google's triage, classification, and remediation steps
- The recommended workflow for checking enabled APIs, identifying unrestricted keys, and rotating exposed credentials
- The broader implications for organisations that have added AI services to older cloud projects
👉 Read Truffle Security's analysis of Google API keys gaining Gemini access →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:11 pm
Public API keys are no longer automatically non-sensitive when platform scope can expand after deployment: Truffle Security's finding shows that a key can move from publishable identifier to authenticating credential without being reissued, rotated, or visibly changed. That breaks a basic governance assumption: that the risk class of a credential is fixed at creation. Practitioners should treat service enablement as part of the credential lifecycle, not as a separate platform setting.
A few things that frame the scale:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do when a legacy key now reaches Gemini or another new API?
A: Treat it as a credential with expanded blast radius and remove the assumption that it is safe because it was originally public. Rotate or revoke exposed keys, narrow service allowlists, and review why the project allowed retroactive privilege expansion in the first place. The governance failure is the coupling, not just the leak.
👉 Read our full editorial: Google API keys now expand into Gemini access without warning