Google API key deletion delays expose a revocation window risk

At a glance

What this is: Aikido found that deleted Google API keys can remain usable for minutes, with authentication persisting for up to 23 minutes after removal.

Why it matters: IAM and NHI teams need to treat key deletion as a delayed control because leaked credentials may stay active long enough to support real attacker misuse and complicate incident containment.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Aikido's analysis of Google API key deletion delays and revocation risk

Context

Google API key revocation shows a basic IAM assumption failing in practice: a deleted credential does not always stop working immediately. In Aikido's testing, that created a revocation window where access persisted after deletion, which matters directly for NHI governance, incident response, and secret lifecycle control.

For identity teams, the issue is not just that a secret exists. It is that revocation becomes an eventually consistent state transition, which leaves attackers a usable window after the control has supposedly been applied. That makes key deletion part of the security design, not a simple cleanup action.

This is a familiar problem in secret sprawl and workload identity governance. The practical question is whether your programme treats deletion as proof of invalidation or as the start of a delayed revocation process.

Key questions

Q: What breaks when deleted API keys can still authenticate after removal?

A: The control no longer matches the user expectation of immediate revocation, so incident response, containment, and offboarding all become time dependent. Attackers can continue using a leaked key after deletion, which means the organisation has not removed access yet. That is a governance failure in the credential lifecycle, not just a technical delay.

Q: Why do delayed revocation windows matter for NHI governance?

A: Because NHI security depends on knowing when a secret actually stops working, not when the console says it was deleted. If the revocation path is eventually consistent, the identity remains active across part of the infrastructure. That extends blast radius and makes deletion an unreliable control unless it is verified.

Q: How should security teams measure whether key deletion is really working?

A: They should test authentication after deletion from multiple regions and record the last successful request, not just whether the key disappears from the UI. The important metric is elapsed time to enforced rejection across the authentication plane. Without that, teams are measuring administrative state, not security state.

Q: Who is accountable when a deleted API key still works?

A: The accountable team is the one responsible for credential lifecycle governance and incident response, because they must prove invalidation rather than assume it. In regulated or audited environments, the control owner should document the revocation window, the monitoring evidence, and the containment action taken while the key remained usable.

Technical breakdown

Why API key revocation becomes eventually consistent

API key deletion is only as fast as the slowest authentication path that still recognises the credential. In a distributed cloud, revocation must propagate across caches, routing layers, and regional enforcement points before all servers reject the key. That is acceptable for low-risk configuration changes, but it is dangerous for authentication because the old state remains valid until every verification point converges. The result is a revocation window, not a clean cutoff. For NHI governance, that means the security control is asynchronous even when the user experience looks immediate.

Practical implication: treat deletion as a propagation process and base incident playbooks on the longest observed revocation delay, not the console state.

Why deleted keys still matter to Gemini and other enabled APIs

A Google API key is not just a login token. It is an identity capability tied to the project's enabled services, so a leaked key can keep calling APIs until revocation reaches the servers still accepting it. If Gemini is enabled, that extends the impact beyond basic API calls to cached conversations and uploaded files. This is a classic NHI problem: the credential is the identity, and the attached service permissions determine blast radius. Deletion without immediate invalidation leaves the privilege boundary intact for too long.

Practical implication: map every API key to the services it can reach so incident response can prioritise the highest-impact exposure paths first.

Why revocation windows break just-in-time access assumptions

Just-in-time access assumes an identity can be created for a task and then invalidated when the task ends. That model fails if revocation is delayed by minutes, because the old credential remains usable after the workflow says it is gone. In practice, the system now needs a safety buffer that stretches beyond the intended access period. That is not JIT in the strict sense. It is temporary access with a delayed off switch, which changes the governance model for service accounts, API keys, and agentic workflows that rely on ephemeral credentials.

Practical implication: do not design ephemeral access workflows around instant deletion unless you can verify real-time revocation behaviour end to end.

Threat narrative

Attacker objective: The attacker wants to preserve access long enough to exfiltrate data or continue abusing project APIs after defenders have deleted the key.

1. Entry occurs when an attacker obtains a valid Google API key through leakage, code exposure, or other secret compromise.
2. Escalation happens because deletion does not immediately revoke the key, so the attacker keeps authenticating through servers that have not converged.
3. Impact follows when the attacker continues to access enabled APIs, including Gemini-related data and other project resources, after defenders believe the key is dead.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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

NHI Mgmt Group analysis

Delayed revocation is a governance failure, not a UX quirk. A credential deletion control only works when the identity can no longer authenticate at every enforcement point. When that does not happen, the programme has not revoked access, it has merely hidden the credential from the console. Practitioners should treat delayed invalidation as an active security state, not a completed control outcome.

Revocation windows create identity blast radius after the control has supposedly fired. The dangerous part is not the key itself but the time gap in which the attacker can keep using it. That gap is enough to defeat incident assumptions about containment and to distort how teams model secrets exposure. The practical conclusion is that deletion, verification, and monitoring must be governed as one lifecycle event.

Just-in-time access collapses when the off switch is slow. JIT depends on access ending when the task ends, but eventual consistency makes the credential outlive the task. That breaks the assumption that ephemeral access is truly ephemeral. Identity teams should recognise this as a structural limitation of delayed revocation, not a tuning issue.

Secret lifecycle governance now has to account for multi-layer propagation, not just issuer intent. The issuer may mark a key deleted, but the authentication plane decides when it actually dies. That means access reviews, offboarding, and incident response need validation steps that test real revocation behaviour. Without that, policy and runtime reality diverge.

Google API key deletion shows why NHI controls must be measured at the enforcement layer. Console state, ticket closure, or approval status do not prove that access has stopped. The only meaningful control is whether the identity still authenticates. Practitioners should design for observed invalidation, not assumed invalidation.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader control view, see Guide to the Secret Sprawl Challenge for how exposure and revocation fail across the secret lifecycle.

What this signals

Revocation latency is becoming an operational risk metric, not a theoretical nuisance. If your team cannot measure when a deleted credential actually stops authenticating, you do not have reliable containment. The control boundary is the authentication plane, not the admin console, and that is where incident response should be validated.

Secret lifecycle programmes need proof of invalidation, not just proof of deletion. A key that disappears from inventory can still be live in distributed infrastructure for minutes, so the monitoring model has to follow the identity, not the ticket. That shifts the programme from administrative hygiene to enforcement verification, which is a much stricter standard.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026, teams should expect more leaked credentials to be found after exposure than before it. That makes delayed revocation more damaging, because discovery and removal can now happen inside the same attacker window.

For practitioners

• Treat key deletion as a timed containment process Assume a deleted Google API key may remain live for up to 30 minutes and structure incident response around the longest observed revocation delay rather than the console state.
• Monitor credential usage during the revocation window Check Enabled APIs and services for requests made by the deleted key and investigate any continued activity as possible active exploitation.
• Separate visible deletion from verified invalidation Require a second control that confirms the key no longer authenticates before closing the incident or returning the service to normal trust assumptions.
• Rework JIT patterns for delayed revocation realities Do not rely on immediate deletion for ephemeral access workflows if the credential can still succeed for minutes after removal.

Key takeaways

• Deleted Google API keys can remain usable long enough to create a real containment gap, which makes revocation a lifecycle control rather than an instant event.
• The practical risk is not only credential exposure, but continued access after deletion across enabled APIs and data paths such as Gemini.
• Security teams should validate actual invalidation, monitor usage during the propagation window, and redesign JIT assumptions around delayed revocation.

Key terms

• Revocation Window: A revocation window is the period after access removal has been decided but before the target systems actually stop honoring the entitlement. It is the most security-sensitive part of authorization timing because the user no longer should have access, yet the system may still allow it. Shortening this window reduces exposure.
• Eventual Consistency: A system property where a change is accepted before every part of the platform reflects it. In cloud identity, that matters because a revoked permission may still be usable for a short period, creating a window in which an attacker or automated tool can act before enforcement converges.
• Credential Invalidation: Credential invalidation is the act of making a leaked password, token, API key, or certificate unusable after exposure or compromise. For identity programmes, it is the point where detection becomes containment, and it must be tied to ownership, approval, and evidence of success.

What's in the full report

Aikido's full blog covers the operational detail this post intentionally leaves for the source:

• The trial methodology used to measure Google API key revocation across multiple regions and repeated requests
• The console evidence showing how deleted credentials still appeared in traffic graphs and attribution buckets
• The comparison with other Google credential types, including service account keys and newer Gemini API keys
• The incident-response workflow considerations for treating deletion as a delayed control rather than immediate invalidation

👉 Aikido's full post covers the 23-minute window, regional differences, and IR implications 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.