When an organization detects a compromised Google API key and deletes it, the standard incident response assumption is that the key is immediately dead. Aikido Security researcher Joe Leon disclosed on May 22, 2026 that this assumption is wrong for legacy Google API keys, which remain fully functional for up to 23 minutes after deletion — a window during which an attacker who has already extracted the key can continue accessing sensitive services while the organization believes the threat has been contained.
The 23-Minute Revocation Window for Legacy Google API Keys
The delay stems from eventual consistency in Google’s distributed infrastructure. When a key is deleted, the revocation must propagate across Google’s globally distributed systems, and that propagation is not instantaneous. For legacy Google API keys — the general-purpose credential type used to authenticate to Google services including Google Gemini AI interactions and BigQuery datasets — the propagation delay can run up to 23 minutes.
The timelines differ across key types. Legacy Google API keys take up to 23 minutes to fully revoke. Newer Gemini API keys, identified by an AQ prefix, revoke in approximately one minute. Service account keys are fastest, revoking in roughly five seconds.
The 23-minute window for legacy keys is the most significant because this key type is widely used and because the services accessible via those keys — including BigQuery datasets and Google Gemini AI interactions — may contain sensitive organizational data. An attacker who has exfiltrated a legacy API key and is monitoring its status can continue extracting data or establishing persistence in connected services for nearly half an hour after the key owner has deleted it and moved on to other incident response steps, confident the access has been cut.
Google’s “Won’t Fix” Position and the Eventual Consistency Argument
Joe Leon reported the issue to Google, which classified it as a “won’t fix” and declined to assign a CVE. Google’s position is that eventual consistency is a known architectural characteristic of its distributed infrastructure, not a security vulnerability requiring remediation. In Google’s framing, the propagation delay is an accepted tradeoff between consistency and the performance and availability that distributed systems require.
Aikido disputes this characterization. The core issue is that the 23-minute delay is meaningful specifically during incident response, precisely when the organization believes it has taken an immediate containment step. For non-security operations — routine key rotation, access management cleanup, project teardowns — a 23-minute propagation window is operationally inconsequential. For the moment when a security team has just discovered a compromised key and deleted it as an emergency measure, the gap between deletion and actual revocation is a window where real damage can continue.
Implications for Incident Response Procedures Involving Google API Keys
The practical impact on incident response procedures is significant. Standard playbooks for cloud credential compromise treat key revocation as an immediate-effect containment action. For Google legacy API keys, that assumption needs to be revised: revocation is an eventually-consistent operation with a worst-case lag of 23 minutes, not an instantaneous one.
Incident responders dealing with a confirmed Google API key compromise should plan for the possibility that the attacker has continued access for up to 23 minutes after deletion. That means conducting concurrent steps — auditing BigQuery access logs, reviewing Gemini API usage, checking for new persistent credentials (service accounts, OAuth clients) that the attacker may have established using the key’s access during the revocation window — rather than treating the deletion step as an effective endpoint to attacker access.
IP Address Restrictions as a Compensating Control
Google’s recommended compensating control is IP address restrictions on API keys. By binding a key to specific allowed IP addresses, organizations limit the range of locations from which the key can be used even if it has been exfiltrated. An attacker operating from infrastructure outside the allowed IP range would receive a rejection even during the revocation delay window.
However, IP restrictions are not applied to all API key types by default and must be manually configured. Organizations using Google Cloud services should audit their current API key inventory and apply IP restrictions to all keys as a baseline configuration. Keys with no IP restrictions that are also not subject to fast-revocation (i.e., legacy keys rather than AQ-prefixed Gemini keys or service account keys) present the greatest exposure during a compromised-credential scenario.
The disclosure by Aikido Security is particularly relevant for security teams that manage environments with Google Cloud integrations and have not yet revisited their incident response runbooks in light of the revocation delay. Credential revocation is a foundational incident response step, and the gap between deletion and actual access termination — even when it is an architectural tradeoff rather than an exploitable bug — changes the risk calculus for what a motivated attacker can accomplish in the window between discovery and containment.
