Google fixes Gemini API key privilege escalation through auth keys

At a glance

What this is: Truffle Security says nearly 3,000 Google API keys could silently gain Gemini access, showing how legacy credentials can inherit AI permissions after they were issued.

Why it matters: IAM teams need to treat API key scope as a live governance problem, because adding AI capabilities to existing platforms can turn benign credentials into unexpected authentication paths.

👉 Read Truffle Security's analysis of Google's Gemini API key privilege escalation fix

Context

Google's Gemini key change exposes a familiar identity problem in a new AI setting: a credential issued for one purpose can later acquire a second, more sensitive purpose without a fresh governance decision. In this case, standard API keys used for services such as Maps or Firebase could become Gemini credentials.

That pattern matters for NHI governance because API keys are non-human identities, even when they are treated as simple application configuration. Once an existing key can inherit access to a new service, the control question is no longer just whether the secret is exposed, but whether its authority can drift after creation.

Key questions

Q: What breaks when a public API key can also reach Gemini endpoints?

A: The main failure is that a credential once treated as a low-risk application identifier can suddenly authorize expensive AI requests. That expands the attack surface from simple misuse to token burn, service abuse, and potential privacy exposure. If the key is unrestricted, exposure becomes immediate exploitability rather than a theoretical secret-leak issue.

Q: Why do reused API keys create billing and data risk even without a CVE?

A: Because the risk comes from credential scope, not software exploitation. If a single key can authenticate to multiple services or inherit new ones, anyone holding that key can consume quotas, access data, or generate charges without needing to bypass a vulnerability in the usual sense.

Q: How do teams know whether an exposed key is actually dangerous?

A: By testing whether it can still authenticate to sensitive services and whether its permissions have expanded since issuance. An exposed key that is inactive or tightly scoped is not the same as one that can reach Gemini, billing-sensitive APIs, or other high-value services.

Q: What should security teams do when AI features are added to an existing platform?

A: Reassess the trust boundary before enabling the feature. Existing secrets should not be assumed safe simply because they were created for a different purpose, and teams should map which credentials can inherit the new capability, then decide whether those credentials need replacement or tighter scoping.

Technical breakdown

How legacy API keys became Gemini credentials

The problem was architectural, not just operational. Google used one credential type for two different functions: project identification for public-facing services and authentication for access to Gemini. That design allowed a standard API key to gain additional API access later if the project enabled the relevant service, which meant the credential's effective scope could change after issuance without a new secret being created. In identity terms, the key was stable while the authorisation model was not.

Practical implication: inventory where API keys are reused across products and treat post-issuance scope expansion as a governance defect.

Why public API keys are not just exposed secrets

A leaked API key is often discussed as a secret hygiene problem, but this case shows a privilege problem as well. If a public key can authenticate to multiple services or inherit new ones, exposure creates more than data access risk. It creates quota exhaustion, service abuse, and billing impact because the key may operate as a valid credential long after the original service owner assumed it was harmless. That makes exposure analysis inseparable from entitlement analysis.

Practical implication: assess every exposed key for both visibility and reachable API scope before deciding whether it is safe to leave in place.

Why auth keys change the control model

Service-account-backed auth keys move the control boundary from a generic project key to a credential purpose-built for Gemini. That reduces accidental privilege inheritance because the new key type is restricted by design, and Google can enforce rejection of unrestricted standard keys at the API boundary. The important mechanism is not the branding of the new credential, but the removal of ambiguity about what the credential can do at the moment it is created.

Practical implication: prefer service-account-backed credentials when a workload needs a narrowly defined AI access path rather than broad reusable API keys.

Threat narrative

Attacker objective: The objective was to turn an apparently low-risk exposed API key into usable Gemini access that could consume services and generate cost or data exposure.

1. Entry occurred when attackers or unintended users obtained a public Google API key from a webpage, repository, or other exposed location.
2. Credential access followed because the same key could be used against Gemini once the Generative Language API was enabled in the project.
3. Impact came through data leakage, quota abuse, and unauthorized billing when the inherited access was exercised at scale.

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.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy API keys cannot be governed as static identifiers once they can inherit new service permissions. The control assumption behind ordinary API key management is that scope is fixed at issuance unless the key is rotated or explicitly reconfigured. This case shows that assumption failing in place, because enabling Gemini changed what an existing key could do without issuing a new secret. Practitioners need to treat post-issuance privilege drift as part of the identity model, not as an edge case.

Privilege escalation can happen without CVE-style exploitation when product architecture reuses credentials across trust domains. The issue here was not a vulnerability in the traditional exploit sense, but a governance collapse between public identification and authenticated service access. That boundary failure belongs in NHI policy, not only in application security review, because the same credential carried two meanings. The practical consequence is that entitlement review must include how a key might be reinterpreted by downstream services.

Service-account-backed auth keys are a narrower trust primitive than unrestricted API keys. The important shift is that the credential now maps to one intended service path instead of inheriting permission from a broader project context. That reduces accidental expansion, but it also raises the bar for key lifecycle discipline because the organisation must know which workloads truly need Gemini access. The practitioner takeaway is to align secret type with intended authority, not convenience.

Credential governance for AI features now sits inside NHI governance, not beside it. When an AI capability is layered onto an existing platform, the identity question is whether old secrets can cross into the new trust boundary without a fresh approval decision. This is a classic example of identity blast radius: a benign key gains more power because the platform changed around it. Teams should assume the blast radius of a stored secret can widen as vendors add AI services.

From our research library:

• 83% of privilege escalation incidents involved no CVE exploitation, according to Verizon's 2026 Data Breach Investigations Report.

What this signals

Credential inheritance is the new secret-sprawl problem: the risk is no longer only where a secret appears, but whether the platform can reinterpret that secret for a different service later. Teams that still rely on static key inventories will miss the control failure because the danger emerges after issuance, not only at creation.

Google's change is a reminder that AI adoption can widen identity blast radius without adding a single new user account. For security programmes, the control question shifts from 'is the key exposed?' to 'can this key become something more powerful tomorrow?'

For practitioners

• Audit API keys for hidden AI scope Check each Google Cloud project for the Generative Language API and identify unrestricted keys or keys that explicitly allow Gemini access.
• Rotate keys that could inherit new permissions Replace exposed or overly broad keys immediately, because a key that was acceptable for Maps or Firebase may now carry different effective authority.
• Migrate integrations to auth keys Create service-account-backed auth keys through Google AI Studio or the Google Cloud Console and update workloads to use the narrower credential type.
• Scan code paths that leak credentials Search repositories, frontend code, and CI/CD pipelines for embedded API keys so the same credential cannot be reused after discovery.

Key takeaways

• This case shows that API keys can become privilege-bearing identity objects when a platform reuses them across trust boundaries.
• The evidence includes nearly 3,000 Google API keys that could silently gain Gemini access, with real-world fallout in data leakage, quota abuse, and billing.
• The limiting control is narrower credential design plus rapid rotation of any key whose effective scope may have expanded.

Key terms

• API Key Privilege Drift: API key privilege drift is the gap between the purpose a key was issued for and the access it can actually obtain later. It happens when platform changes, added APIs, or shared project design let the same secret perform higher-risk actions than the owner intended.
• Credential scope drift: Credential scope drift occurs when the access a key effectively receives at runtime is broader than the permissions intended at creation. It often shows up through weak endpoint checks, overly permissive roles, or poor revocation handling, and it turns a narrow credential into an uncontrolled access path.
• Service-Account-Backed Auth Key: A service-account-backed auth key is a credential used by software to prove its identity when calling systems or APIs. It is tied to a service account rather than a person, and may be a secret, token, or key pair. Security depends on tight scoping, rotation, storage protection, and revocation controls.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Truffle Security's full article covers the operational detail this post intentionally leaves for the source:

• Google's rollout timeline for rejecting unrestricted API keys and removing standard key support by September 2026
• Step-by-step checks for identifying whether a Google Cloud project is affected by the Generative Language API change
• Practical migration guidance for creating and using auth keys in Google AI Studio or Cloud Console
• Examples of exposed-key discovery in codebases, frontend code, and CI/CD pipelines

👉 The full Truffle Security article covers the disclosure timeline, key migration details, and mitigation steps for exposed Google API keys.

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.