# Google API Keys Remain Active After Deletion for Up to 23 Minutes—A Critical Revocation Delay


Security researcher Joe Leon at Belgian cybersecurity startup Aikido Security has uncovered a significant vulnerability in Google Cloud Platform's API key revocation process: deleted keys continue to function for up to 23 minutes after deletion, with a median window of approximately 16 minutes. The discovery reveals a dangerous gap between user expectations and actual behavior, potentially exposing organizations to data exfiltration and unauthorized API abuse.


## The Threat: A Window of Continued Access


When a Google Cloud user deletes an API key, they expect that access to stop immediately. The Google Cloud Console provides no indication that keys remain functional after deletion. However, Leon's research demonstrates that this expectation is fundamentally incorrect.


The real-world impact is severe:


  • Attackers in possession of a deleted API key can continue sending authenticated requests for up to 23 minutes
  • These requests succeed because not all servers in Google's distributed infrastructure have synchronized the deletion across their caches
  • If Gemini (Google's AI platform) is enabled on the compromised project, attackers can exfiltrate uploaded files and cached conversations without raising any alerts
  • The GCP console provides zero visibility into continued key activity post-deletion
  • Organizations have no way to know if their "deleted" keys are still actively being exploited

    • Leon emphasized the severity in his public disclosure: "An attacker holding your deleted key can keep sending requests until one reaches a server that has not caught up. You are trusting Google's infrastructure to eventually catch up."


    ## Background and Context: Expectations vs. Reality


    ### How API Keys Should Work


    API keys serve as authentication credentials in cloud platforms, allowing applications and services to access specific resources and APIs. When an organization identifies a compromised or unnecessary key, deletion should be instantaneous—a security best practice across the industry. Users rightfully assume that removing a key from the console eliminates all access granted by that credential.


    ### The AWS Precedent


    Leon's investigation was inspired by earlier research from Eduard Agavriloae, co-founder of Offensai, who documented similar revocation delays in AWS credentials in late 2025. However, AWS's window was significantly smaller: approximately four seconds. When AWS became aware of the issue, the company responded with fixes and acknowledgment.


    Google's 16-23 minute window is exponentially longer than AWS's four seconds—making it not just a minor architectural quirk but a material security risk.


    ### The Distributed Systems Problem


    The revocation delay stems from a fundamental challenge in distributed systems: cache consistency. Google Cloud operates globally across multiple regions and thousands of servers. When a user deletes an API key through the GCP console, that deletion command must propagate across this entire infrastructure.


    In theory, this should happen quickly. In practice, some servers may have the deletion instruction cached, while others still hold a valid copy of the deleted key. Until every server in the chain receives and applies the deletion, the key remains usable.


    ## Technical Details: The Research Methodology


    Aikido Security conducted rigorous testing to quantify the revocation window:


    ### Experimental Setup

  • Created virtual machines (VMs) across different GCP regions
  • Generated fresh API keys for each test
  • Deleted keys and immediately began sending authenticated requests
  • Measured the time until requests failed
  • Repeated tests over multiple days and regions to establish consistent patterns

    • ### Key Findings


    | Metric | Value |

    |--------|-------|

    | Median revocation window | ~16 minutes |

    | Maximum observed window | 23 minutes |

    | Minimum observed window | Minutes (varies) |

    | Test iterations | 10+ tests across multiple regions |

    | Consistency | Highly consistent across regions |


    ### Why the Delay Occurs


    The delay reflects Google's infrastructure design:


    1. API key metadata is distributed across multiple geographic regions for redundancy

    2. Cache invalidation relies on eventual consistency rather than immediate global synchronization

    3. Load balancers and edge servers may hold cached versions of the key that don't immediately update

    4. Gemini integration adds complexity—AI services may maintain separate caches of credentials


    The longer the revocation window, the higher the probability that an attacker can find a server that still recognizes the deleted key.


    ## Implications: Who's At Risk


    ### Organizations Most Vulnerable


  • Tech companies that store API keys in version control (even briefly) before catching the mistake
  • SaaS providers that use GCP for backend infrastructure and store customer data
  • Organizations using Gemini for AI workloads who have confidential documents uploaded to the platform
  • DevOps teams that rotate keys regularly and expect immediate revocation
  • Enterprise customers managing hundreds or thousands of service accounts

    • ### Detection Blind Spots


    The most insidious aspect of this vulnerability is that it's invisible:


  • The GCP console shows the key as deleted immediately, creating a false sense of security
  • Cloud Audit Logs don't flag continued usage of deleted keys as anomalous
  • Organizations have no automated alerts when a deleted key is used after deletion
  • Security teams assume keys are revoked instantly, making them less likely to investigate

    • ### Cascading Risks with Gemini


    If Gemini is enabled on a GCP project, the risks escalate significantly. Attackers can:

  • Dump files uploaded to Gemini's document-processing features
  • Exfiltrate cached AI conversations containing sensitive prompts or outputs
  • Access training data or fine-tuned models
  • Exploit the key during the revocation window to harvest data before the window closes

    • ## Recommendations: Immediate and Long-Term Actions


    ### Immediate Steps for GCP Users


    1. Audit all deleted API keys in the past 30 days

    - Review Cloud Audit Logs for any activity from deleted credentials

    - Check for unexpected API calls in the 23-minute window after key deletion


    2. Enable API restrictions on critical keys

    - Limit which APIs each key can access

    - Restrict keys to specific resources rather than blanket access


    3. Disable Gemini if not essential, or apply strict file access controls


    4. Implement key rotation workflows

    - Treat key deletion as a security incident, not a routine operation

    - Wait 30+ minutes after deletion before considering a key truly revoked

    - Audit subsequent API usage before re-enabling services


    ### Long-Term Defensive Measures


  • Monitor for anomalous API activity post-deletion using Cloud Monitoring and custom alert policies
  • Use short-lived credentials (OAuth tokens with 1-hour expiration) instead of permanent API keys where possible
  • Separate keys by privilege level—never use admin keys for applications; use minimal-privilege service accounts
  • Implement keyless authentication using Workload Identity Federation where feasible
  • Conduct quarterly API key audits to identify and eliminate unnecessary credentials

    • ### What Google Should Do


  • Reduce the revocation window to seconds (AWS-level performance) through improved cache invalidation
  • Add explicit warnings in the GCP console when a key is deleted: "Key deletion is not immediate and may take up to 23 minutes to complete globally"
  • Implement revocation timestamps visible to users so they know the actual deletion time
  • Alert on suspicious activity from recently-deleted keys automatically
  • Publish this behavior transparently in documentation

    • ---


    ## HackWire Analysis


    This vulnerability exposes a critical blind spot in cloud security: the assumption that deletion means deleted.


    For defenders, the timing is particularly dangerous. A compromised API key discovered on a Friday afternoon gets deleted immediately—but if that key ends up in an attacker's hands (via a supply chain compromise, insider threat, or prior data breach), the window between deletion and revocation becomes an exploitation opportunity. An attacker with knowledge of that 23-minute window can extract high-value data from Gemini-enabled projects, exfiltrate application secrets, or pivot to other cloud resources.


    This also exposes a pattern in cloud provider security posture: they optimize for eventual consistency over immediate safety. Google's distributed architecture is designed for resilience and availability, not for security control speed. AWS experienced the same trade-off but on a smaller scale. The lesson is clear—cloud users cannot assume that their security controls behave the way the UI suggests. Enterprise organizations must implement monitoring and alerting at the application level rather than trusting platform-level guarantees alone.


    The Aikido Security research is methodical and reproducible. If you operate on GCP and handle sensitive data, treat this not as a theoretical issue but as a documented risk that requires operational response. Immediately audit your API key deletion practices and implement monitoring for post-deletion activity. Don't wait for Google to fix this—they may not, and it may not matter. You must be your own backup security control.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Cloud Security](https://www.hackwire.news/category/cloud-security) and [API Security](https://www.hackwire.news/category/application-security)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)