Topic starter
02/08/2026 11:34 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Google API keys keep working after you delete them”.
By the numbers:
- In the first minute after deletion, one region saw 82% success while another saw 32%.
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.
Q: Why do delayed API key revocations create security risk?
A: Because bearer credentials remain useful until every accepted path rejects them.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:48 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Google API key deletion delays expose a revocation window risk