Google API keys now expand into Gemini access without warning

At a glance

What this is: Truffle Security shows that Google API keys can retroactively become Gemini credentials, turning public identifiers into sensitive access tokens without a clear warning path.

Why it matters: IAM and NHI teams need to treat key purpose, scope, and downstream API enablement as one governance problem, because a formerly benign credential can become a live access path after platform changes.

By the numbers:

• We identified 2,863 live Google API keys vulnerable to this privilege-escalation vector in the November 2025 Common Crawl dataset.

👉 Read Truffle Security's analysis of Google API keys gaining Gemini access

Context

The security problem here is not simply secret leakage. It is a change in the meaning of an existing credential after the platform adds a new capability, which breaks the assumption that a published API key remains limited to its original use case.

In NHI terms, this is a credential governance failure that spans inventory, scope control, and lifecycle management. API key management usually assumes the key's privilege envelope is stable, but that assumption fails when the platform can expand access retroactively.

For practitioners, the important question is not whether the key was technically exposed, but whether enabled services can reclassify an already deployed identifier into an authentication credential without operational notice.

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. When a later service enablement can expand that key's rights, inventory, approval, and recertification workflows no longer describe the real threat surface. Teams must evaluate the live entitlement set, not just the original purpose of the credential.

Q: Why do public API keys become dangerous when a platform adds new sensitive services?

A: They become dangerous because exposure and authorisation merge. A key that was safe to publish for a low-risk service can suddenly authenticate to a higher-risk API without changing format, so anyone who can scrape the key can also use the new service. The danger is the hidden privilege shift, not the string itself.

Q: How can security teams tell whether a leaked API key is actually exploitable?

A: Check both exposure and current scope. A leaked key is exploitable when it is still active and the project now allows that key to call sensitive endpoints. The practical test is to confirm whether the key reaches protected APIs in the current configuration, not whether it once looked harmless in source code.

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.

Technical breakdown

How privilege expansion turns a public API key into a sensitive credential

The core mechanism is privilege reassignment. A key that once acted as a project identifier for low-risk services can later authenticate to higher-risk endpoints when a new API is enabled in the same project. That means the security meaning of the key is not fixed at creation time. The architectural defect is the absence of a hard boundary between publishable identifiers and secret credentials, so the same token can move from client-side disclosure tolerance to confidential access enforcement without changing form. Practical implication: separate credentials by trust tier and treat service enablement as a governance event. Read the Ultimate Guide to NHIs: What are Non-Human Identities.

Practical implication: Separate publishable identifiers from secret credentials and bind each to a fixed access tier.

Why unrestricted defaults create silent cross-service access

A permissive default makes the first moment of issuance already dangerous. If a newly created key is valid for every enabled service in a project, then the control model depends on administrators remembering to narrow scope later. That is backwards from secure-by-default design. In this pattern, the key itself is not the only risk. The project's enabled services become part of the credential's effective privilege set, which means one team action can widen access for another team’s older key. Practical implication: default-deny key issuance and require explicit per-service allowlisting.

Practical implication: Require explicit per-service allowlists for every API key issued into shared projects.

Why leaked-key detection must be paired with privilege revalidation

Detection alone is incomplete because a key's exposure status and its authorisation status are now different questions. A scraper might recover a key from public code, but the real impact appears only after the platform grants that key access to a sensitive API. That creates a dual check requirement: find exposed keys and then test what they can actually do across the current service set. This is why stale guidance about public keys being harmless no longer holds. Practical implication: validate exposure and current privilege together, not as separate workflows. Read Guide to the Secret Sprawl Challenge.

Practical implication: Revalidate exposed keys against live service entitlements before deciding whether they are safe to leave in circulation.

Threat narrative

Attacker objective: The attacker wants to turn a publicly exposed identifier into usable Gemini access that reveals private data and consumes the victim's quota and budget.

1. Entry via a publicly accessible webpage or codebase where an old Google API key can be scraped without touching internal systems.
2. Credential access occurs when the attacker reuses that key against Gemini endpoints that the project now allows, even though the key was originally issued for a different service.
3. Impact follows through access to uploaded files, cached content, API quota consumption, and bill inflation on the victim's account.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Retroactive privilege expansion is a distinct failure mode, not just a misconfiguration: The problem is not merely that a key was left exposed. The deeper issue is that a legitimate public key inherited sensitive rights after Gemini was enabled on the project, which means scope changed underneath the owner. This is a governance blind spot for inventories, approvals, and recertifications that assume privileges can be judged from issuance state alone.

Identity blast radius now depends on downstream platform coupling: When one credential format spans both public and sensitive use cases, the effective blast radius is determined by what other APIs are enabled in the same tenant. That makes environment design and service enablement part of identity control, not only application engineering. The implication is that teams need to govern coupled privileges as one risk surface, not as isolated service settings.

Secret scanning without entitlement validation leaves a false sense of safety: Finding an exposed key is no longer enough to classify the risk. A key may be public, but whether it can reach sensitive endpoints depends on project-level service state at the moment of abuse. This is the kind of control gap that makes credential discovery necessary but insufficient; practitioners need to understand what every discovered key can currently do.

Key separation is becoming a structural requirement for modern identity hygiene: A single token type that can serve both low-risk and high-risk functions creates ambiguity that human operators cannot reliably resolve at scale. The article illustrates why publishable identifiers and secret credentials should not share the same trust model. For practitioners, the lesson is to stop assuming a one-size-fits-all API key architecture can safely survive new service introductions.

From our research library:

• 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.
• Read next: API Key Management Guide

What this signals

Credential meaning now depends on service state: Teams that govern API keys as static identifiers will miss the moment a later platform change turns them into authenticators. That means entitlement review must move closer to service enablement, because the trust boundary can change without reissuing the credential.

The pattern here is a useful warning for any organisation layering AI services onto an older platform estate. Existing keys, tokens, and project-level defaults can acquire new power faster than governance workflows can recertify them, so the control point shifts from issuance to ongoing scope validation.

If your IAM programme still treats key exposure and key authorisation as separate problems, this article shows why that separation is no longer defensible. The operational question is whether your governance model can detect when a harmless identifier stops being harmless.

For practitioners

• 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. Read the Ultimate Guide to NHIs: What are Non-Human Identities.
• 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.
• Scan code and pipelines for live exposure Use secret scanning across repositories, CI/CD pipelines, and web assets, then confirm whether discovered keys are live against current APIs.
• Rotate any exposed key that now reaches Gemini Treat a public key with current Gemini access as an active credential, not a harmless identifier, and remove it from circulation quickly.

Key takeaways

• A Google API key can become a Gemini credential after deployment, which means the original issue is not only leakage but retroactive privilege expansion.
• Truffle Security identified 2,863 live exposed Google API keys in public web data, showing that the pattern is already present at meaningful scale.
• The limiting control is no longer just secret scanning. Teams need service-aware entitlement review, key separation, and fast revocation for exposed keys.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: What are Non-Human Identities · Guide to the Secret Sprawl Challenge · API Key Management Guide

Key terms

• Retroactive Privilege Expansion: A situation where a previously harmless credential becomes sensitive after platform settings or enabled services change. The risk is operational surprise, because the key owner may not receive a warning when access changes underneath them, yet the exposed credential can suddenly reach protected data or billable resources.
• Publishable Identifier: A value designed to be embedded in public code or client-side configurations for identification, billing, or routing rather than for high-trust authentication. The risk appears when the same value is later accepted as an authenticator, because public exposure then becomes an access problem.
• Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
• Service Enablement Coupling: A governance condition where turning on a new service changes the access rights attached to an existing credential. In practice, this means identity risk is no longer determined only at issuance, because later platform configuration can silently widen what the same token can do.

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

👉 Truffle Security's full post covers the proof-of-concept, disclosure timeline, and remediation context in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.