TL;DR: Google API keys can continue authenticating for up to 23 minutes after deletion, with revocation arriving inconsistently across regions and services, according to Aikido's testing. That gap turns key deletion into a delayed control, not an immediate cutoff, and undermines incident response, JIT access, and secret revocation assumptions.
At a glance
What this is: Aikido tested Google API key deletion and found a revocation window in which deleted keys could still authenticate for minutes after removal.
Why it matters: That matters because IAM and NHI teams cannot treat key deletion as instantaneous containment when leaked API keys may remain usable during incident response.
By the numbers:
- Across ten trials, the longest window was nearly 23 minutes.
- The shortest window was nearly 8 minutes, and the median was around 16 minutes.
- One minute after deletion, one trial saw 79% of requests succeed while another saw only 5%.
- In the first minute after deletion, one region saw 82% success while another saw 32%.
Context
Google API key deletion is not an immediate revocation event. Aikido's testing shows that after a key is removed from view, some Google authentication servers may continue accepting it for minutes, which turns deletion into a propagation problem rather than a hard cutoff.
For identity teams, the issue is not only exposure but expectation. When a credential can still authenticate after deletion, incident response, just-in-time access, and revocation workflows all inherit a delay that users and operators may not realise exists.
The result is a revocation window risk for machine credentials: the key looks dead in the console while still being operational in parts of the service layer. That gap is especially consequential for API keys protecting cloud workloads and AI-enabled services.
Key questions
Q: What breaks when deleting an API key does not end access immediately?
A: Deletion stops being a containment action and becomes a request for the platform to converge on revocation. During that window, a stolen key can keep authenticating, which means incident response, JIT access, and emergency offboarding all have a residual exposure period that operators must plan for.
Q: Why do delayed API key revocations create security risk?
A: Because bearer credentials remain useful until every accepted path rejects them. Even a short delay lets an attacker continue calling enabled APIs, and a longer delay makes the control depend on routing and propagation rather than the operator's revocation decision.
Q: How can teams tell whether a deleted API key is still being used?
A: They should compare post-deletion request logs, credential attribution, and region patterns. If successful authentications continue after deletion, the key may still be live on part of the infrastructure, but UNKNOWN attribution can make the evidence harder to interpret.
Q: Should organisations build just-in-time access around API key deletion?
A: Only if the platform can guarantee immediate revocation, which this article shows Google API keys do not. For ephemeral access models, teams need a revocation behaviour they can verify, otherwise the temporary credential outlives the task it was created for.
Technical breakdown
Why API key deletion becomes eventually consistent
Google's API key revocation behaves like a distributed state change rather than a synchronous kill switch. In eventually consistent systems, different servers converge on the new state at different times, so one request can be rejected while another still succeeds. That is usually acceptable for non-security metadata, but authentication is different because continued acceptance preserves attacker access. A deleted key therefore remains valid wherever the revocation message has not yet propagated, which makes the effective security boundary dependent on routing, cache state, and backend locality rather than the delete action itself.
Practical implication: Treat deletion as a propagation event and design containment around the last accepted authentication, not the console status.
How regional routing changes the revocation window
Aikido's trials show that revocation lag was not uniform across regions. Requests from different regions saw very different success rates immediately after deletion, which suggests the authentication path is shaped by regional infrastructure, caching, or routing affinity. That matters because an attacker does not need a stable cutoff, only repeated attempts against a still-synced path. The console can also bundle deleted keys into an apikey:UNKNOWN bucket, which complicates triage because operators lose clear attribution once the key disappears from normal inventory views.
Practical implication: Correlate authentication logs with region and credential state so you can separate active abuse from delayed propagation artifacts.
Why this breaks just-in-time credential assumptions
Just-in-time access assumes that privilege can be created and removed in a bounded, predictable way. If deletion can lag by many minutes, the credential outlives the intended task window and the control no longer matches the workflow. That undermines ephemeral access models because the system cannot guarantee that a key is dead at the moment operators believe they have revoked it. The same issue affects incident response, where the team expects revocation to close the exposure before the attacker can continue using the credential.
Practical implication: Do not base JIT or emergency response design on immediate API key death when the platform only offers eventual revocation.
Threat narrative
Attacker objective: Keep using a deleted API key long enough to access project data and enabled services before revocation fully takes effect.
- Entry occurs when a leaked Google API key is used after deletion but before revocation has propagated to every accepting server.
- Credential access persists through the revocation window because the key remains valid on some authentication paths despite being removed from the console.
- Impact occurs when the attacker continues calling enabled APIs, including data access paths exposed through Gemini or other project services.
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
Revocation window risk is the real control failure here: key deletion is only meaningful if the credential stops authenticating at the point operators think it does. Aikido's testing shows that Google API keys violate that expectation by continuing to work during propagation. The practical consequence is that incident teams must think in terms of residual credential life, not deletion events.
Eventual consistency is a design choice that collides with authentication: it works for many cloud state changes, but it is a weak fit for bearer-style credentials. Authentication depends on immediate trust withdrawal, because every additional minute preserves attacker utility. Practitioners should interpret delayed revocation as an access control property, not a UI defect.
Deleted-key triage needs better attribution than a console bucket: the apikey:UNKNOWN grouping hides whether a request reflects active abuse or stale propagation. That ambiguity slows response and weakens evidence collection. Identity operations teams need logging and detection logic that preserve credential lineage after deletion.
Just-in-time access cannot rely on deletion as the terminal step: if a deleted key can keep authenticating, the access window is longer than the workflow that created it. That means JIT governance must account for the tail of authentication acceptance, not only the issuance moment. Otherwise the control promises ephemerality while the platform still permits reuse.
Google API key lifecycle needs stricter operational ownership: the article shows that different credential types already revoke on different timelines, which means teams cannot treat all Google credentials as governed the same way. The implication for IAM and NHI programmes is to inventory credential classes by revocation behaviour, then set response procedures to the slowest effective cutoff.
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.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Revocation latency changes the meaning of a deleted credential: teams that treat delete as a hard stop will undercount exposure, because the platform can continue honouring the key after the operator has already moved on. That makes revocation timing part of the control design, not a back-end detail.
Residual authentication windows should be measured, not assumed away: once a platform exposes different deletion latencies by service or region, the governance question becomes which credential classes deserve special handling. IAM teams should classify API keys by their effective shutdown behaviour and build response playbooks around the slowest path.
For practitioners
- Model deletion as a delayed revocation event Assume a deleted Google API key may remain valid for minutes and structure incident response around the longest observed acceptance window, not the delete action itself.
- Monitor post-deletion authentication activity Review request logs and API usage by credential after deletion so you can detect continued authentication and confirm whether the revoked key is still being accepted.
- Separate console state from trust state Do not treat a missing key in the GCP console as proof of revocation, because the platform may still accept the credential elsewhere in the service path.
- Adjust JIT workflows for residual access Build a buffer into just-in-time access processes so temporary API keys are not assumed dead at the moment they are deleted.
- Preserve deleted-credential lineage in investigations Keep the deleted credential identifier and region data available during triage so UNKNOWN attribution does not erase the investigative trail.
Key takeaways
- Google API key deletion can leave a live authentication window that lasts long enough to matter operationally, even though the key disappears from the console.
- Aikido's testing showed that the delay varies by region and by credential type, which makes revocation behaviour harder to predict during an incident.
- Security teams should treat key deletion as a delayed containment step and validate post-deletion usage before assuming access has ended.
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 | Deleted API keys remain exploitable during the propagation window after exposure or theft. |
| NHI-07 — Long-Lived Secrets | The article shows a deleted key can stay usable long after operators assume it is dead. | |
| Recommendation — Scan for leaked API keys and revoke them, but verify that revocation has actually propagated. Shorten the effective life of API keys and avoid workflows that depend on instant deletion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator management covers credential lifecycle and revocation behaviour for API keys. |
| Recommendation — Apply IA-5 to validate revocation timing and credential retirement procedures for API keys. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat hinges on continued use of a stolen credential after apparent deletion. |
| Recommendation — Map delayed revocation to TA0006 and monitor for continued credential use after deletion. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether authorization ends when the operator thinks it does. |
| Recommendation — Verify that access removal actually takes effect before declaring a credential retired. | ||
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.
- 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.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
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 August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org