Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Google API key deletion delays: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15051
Topic starter  

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.

NHIMG editorial — based on content published by Aikido: Google API keys keep working after you delete them

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.

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

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

Google API key deletion delays: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14635
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Google API key deletion delays expose a revocation window risk



   
ReplyQuote
Share: