TL;DR: Exposed Google API keys that were once treated as low risk can now be abused for Gemini AI usage and data access, with scanned code repositories and webpages revealing thousands of visible keys and potential surprise bills in the thousands within a day, according to Swarmnetics. The control failure is not the key itself but the lack of inventory, review, and rotation after its authorisation scope changed.
At a glance
What this is: Swarmnetics says older Google API keys can now be abused for Gemini AI access, data exposure, and fast-moving billing abuse when exposed in code or web source.
Why it matters: IAM and NHI teams need to treat legacy API keys as changing identities, not static artefacts, because scope changes can turn old secrets into current attack paths.
Context
Google API keys are often treated as low-sensitivity integration credentials, but that assumption breaks when the same key later gains access to higher-value services. In this case, older keys that were created before Gemini AI became part of the platform now carry a much larger authorisation surface than their original owners expected.
The governance problem is not simply that keys are exposed in code or web source. It is that secret inventory, scope review, and rotation did not keep pace with authorisation drift, so a stale credential became a current control issue for both NHI governance and AI access oversight.
Key questions
Q: What breaks when AI agents rely on long-lived API keys?
A: Long-lived keys turn a single leaked secret into persistent authority, and agents create more places for that secret to leak through prompts, logs, cache layers, and tool outputs. Once the key is reused across tasks, revocation becomes slow and unreliable. Short-lived credentials are safer because they reduce the window in which exposure can be exploited.
Q: Why do exposed API keys and signing secrets create different levels of risk?
A: An exposed API key may mainly allow quota abuse or limited third-party access, while a signing secret can let an attacker forge identities and generate new valid requests. The second case is more serious because it compromises trust itself, not just one captured token or one service account instance.
Q: How should teams respond when a long-lived API key predates a platform capability change?
A: Treat the key as newly risky until proven otherwise. Recheck its effective scope, locate every place it appears in code or web assets, rotate it if the service still needs access, and remove any Gemini-enabled entitlement that is not operationally required.
Q: What is the difference between exposed secrets and exposed permissions?
A: An exposed secret is the credential itself, while exposed permissions are the services that credential can now reach. A key can be visible for years without incident, then become dangerous when its authorisation changes, which is why visibility and scope review must be governed together.
Technical breakdown
Why old API keys become new Gemini access paths
A Google API key is a bearer credential, so anyone who finds it can use whatever scope is attached to it. The risk changed here because older keys were later granted Generative Language API access or equivalent Gemini permissions without the original teams re-evaluating exposure. That creates an authorisation mismatch: the secret may be old, but the privileges are current. Once the key is visible in source code, repositories, or page content, the attacker does not need to break authentication in the usual sense. They simply reuse the exposed credential exactly as issued.
Practical implication: Treat every legacy API key as a live identity and revalidate its current scope before assuming old exposure is harmless.
How billing abuse and data exposure happen with exposed keys
When a key can call Gemini APIs, abuse does not require account takeover. A threat actor can generate queries at scale, drive token usage, and shift cost onto the organisation that owns the key. If the key also has access to stored content such as files or cached outputs, the same credential can be used to request information the legitimate owner expected to remain private. This is why the incident is both financial and data-related: the attack surface is the API entitlement itself, not just the presence of the secret in public code.
Practical implication: Separate cost monitoring from access monitoring, because abuse can surface first as billing anomaly before it appears as a security alert.
What visibility gaps let exposed keys persist
The failure mode is weak inventory and slow remediation, not a single misconfigured setting. If teams do not know where their API keys are embedded, which services they can reach, and whether they are still needed, they cannot rotate with confidence. Google may block some leaked keys and notify owners, but that is not the same as enterprise-grade lifecycle governance. The practical control gap is the absence of continuous discovery across repositories, page source, and application code, followed by a review of whether the key still needs Gemini scope at all.
Practical implication: Build continuous discovery and rotation workflows for API keys across code and web assets, with explicit review of Gemini-enabled scopes.
Threat narrative
Attacker objective: The attacker wants to extract value from the exposed key by generating unauthorised Gemini spend and, where permitted, retrieving stored private data.
- Entry occurs when exposed Google API keys are discovered in public webpage source, GitHub repositories, or application code.
- Credential use follows when the attacker copies the key and reuses its current Gemini AI authorisation without needing to compromise a user account.
- Impact comes from high-volume Gemini usage charges and possible access to private files or cached content tied to the same key.
Breaches seen in the wild
- 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.
- 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 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
Authorisation drift is the real failure mode: the key was created in a lower-risk era, but its scope later expanded into a Gemini access path. That assumption failed because teams treated the secret as static while the platform context changed around it. The implication is that API key governance must follow current privilege, not historical intent.
Legacy API keys need lifecycle governance, not just leak detection: public exposure matters, but the deeper problem is that the key remained valid after its role changed. Secret inventory, usage review, and revocation are lifecycle controls, not optional hygiene. Practitioners should read this as evidence that stale credentials become active attack surfaces when scope changes are not re-baselined.
Billing abuse is an identity control issue: when a bearer credential can trigger paid AI consumption, access control and cost control become the same problem. This is especially important for teams adopting agentic AI, where previously benign integration keys can suddenly reach expensive or sensitive services. The practitioner conclusion is that entitlement review must include financial blast radius, not only technical reach.
Ephemeral AI scope is a named governance gap: organisations are discovering that credentials issued for one platform era can silently inherit new AI capabilities later. That creates a trust gap between issuance-time assumptions and runtime authorisation reality. Teams should treat this as a signal to redesign how they classify, inventory, and retire long-lived API credentials across AI-adjacent services.
Visibility failures delay containment: if exposed keys are hidden in code, cached content, or repo history, responders cannot rely on manual checks alone. The article shows why discovery must be continuous and tied to revocation, not just alerting. Practitioners should assume that any unmanaged key can outlive the control process meant to govern it.
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
Legacy API keys are becoming AI entitlements: the practical control boundary has shifted from whether a key was ever exposed to whether it still has live reach into expensive AI services. Teams that only hunt for secrets without reclassifying current scope will miss the real risk.
Authorisation drift is now a governance problem, not a cleanup task: old integration keys can inherit new value when platforms add AI features later. That means inventory, review, and revocation need to operate as a lifecycle process across both NHI and AI-adjacent services.
Billing monitoring must sit alongside access monitoring because Gemini abuse can surface as cost growth before it surfaces as a classic security alert.
For practitioners
- Audit all Google API keys for Gemini scope Check whether any key has Generative Language API enabled or an unrestricted warning icon, then remove Gemini access where it is not explicitly required.
- Search code and web assets for exposed keys Inspect webpage source, GitHub repositories, application code, and cached content for keys that are publicly visible or can be copied without authentication.
- Rotate keys that no longer need current scope Revoke or replace long-lived API keys that predate Gemini AI and confirm that the replacement has only the minimum required authorisation.
- Add billing anomaly monitoring for AI API use Set alerts for unexpected Gemini query spikes, because abuse may first appear as rapid cost growth before it is flagged as a security event.
- Inventory all AI-adjacent API entitlements Map which secrets can reach files, cached outputs, or other sensitive endpoints so teams can distinguish harmless integration keys from exposed AI-capable credentials.
Key takeaways
- Older Google API keys can become dangerous when new service permissions are attached after issuance.
- The exposure problem is amplified when secrets are visible in repositories, page source, or application code.
- Teams need continuous discovery, current-scope review, and rapid rotation before AI-enabled credentials are abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Exposed API keys in public code are the central attack path in this article. |
| NHI-07 — Long-Lived Secrets | Old keys became risky because they remained valid after their scope changed. | |
| Recommendation — Scan repositories and web assets for leaked API keys and revoke any exposed credential immediately. Rotate long-lived API keys and retire any credential that predates its current authorisation scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue is credential lifecycle governance for API keys and rotation. |
| Recommendation — Apply IA-5 to enforce rotation, revocation, and lifecycle control for exposed API keys. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Gemini exposure came from changed entitlements, not just a leaked secret. |
| Recommendation — Review and limit entitlements so exposed keys cannot reach services they no longer need. | ||
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | Attackers use the leaked key for credential reuse and financial impact through AI billing abuse. |
| Recommendation — Map exposed API key abuse to credential access and impact so detection focuses on misuse and spend anomalies. | ||
Key terms
- Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
- Authorisation Evidence Drift: Authorisation evidence drift is the gap between the access behaviour policy owners expect and the behaviour runtime logs actually show. It grows when teams review entitlements without continuously observing policy decisions, policy changes, and the context used to make each access judgment.
- Long-lived API key: A long-lived API key is a credential intended to remain usable beyond a short session window. In identity governance, that persistence increases the chance of stale access, hidden exposure, and inconsistent enforcement unless the key is tracked, tested, and revoked with discipline.
- AI-Adjacent Secret: An AI-adjacent secret is any credential that can reach model endpoints, prompt stores, cached outputs, or other AI-connected services. For governance, these secrets need tighter review than ordinary integration keys because their blast radius can include both cost and data exposure.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 10, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org