Security researchers at Aikido Security today published findings showing that Google API keys continue authenticating successfully for up to 23 minutes after being deleted - a gap that Google has declined to address, closing the vulnerability report as "won't fix."

The research, authored by Aikido security researcher Joe Leon and published on May 21, 2026, is the result of 10 controlled trials conducted across two days, with spot checks repeated several weeks later to rule out transient network conditions. The findings document a structural flaw in how Google's authentication infrastructure handles credential revocation, exposing any API-enabled service on an affected project - including Gemini file access, BigQuery, and Google Maps - to continued access by anyone holding a stolen key, even after the key is visibly absent from the Google Cloud Platform console.

What the research measured

The core of Aikido's methodology was straightforward. In each trial, the researchers created a Google API key, deleted it, then sent between 3 and 5 authenticated requests per second until no valid response came back for several minutes. The request rate was chosen deliberately: because Google routes traffic across multiple authentication servers around the world, a higher request volume increases the chance of rotating through servers that have not yet propagated the deletion.

Across 10 trials, the revocation window - the interval between deletion and the last successful authentication - ranged from just under 8 minutes at the shortest to nearly 23 minutes at the longest. The median window was around 16 minutes. Those numbers, according to Aikido, may not represent the worst case. An attacker in a real incident would have no reason to throttle request rate the way the researchers did.

The inconsistency within trials was as striking as the overall duration. One minute after deletion, one trial saw 79% of requests succeed. Another saw only 5%. There is no clean cutoff, no predictable decay curve. Access simply keeps working, unevenly, until it stops.

The UI problem: deleted means deleted, except it does not

When a user deletes an API key through the Google Cloud console, Google removes the key from the credential list and displays a confirmation message stating the key "can no longer be used to make API requests." According to Aikido's research, that statement is factually incorrect for at least 8 minutes and potentially for close to 23 minutes after the action is taken.

The console provides no indication that the key is still live. There is no countdown, no warning, no way to accelerate revocation, and no mechanism to confirm that revocation has completed. An incident response team acting on a leaked key has no way to know when the credential has actually stopped working. The only option is to wait.

This matters acutely in the context of Google's Gemini integration. As PPC Land reported in March 2026, TruffleSecurity disclosed that Google API keys had quietly gained the ability to authenticate with Gemini endpoints whenever the Generative Language API was enabled on an associated project. The practical consequence is that a deleted key, during its revocation window, could allow an attacker to exfiltrate uploaded files and cached conversations from Gemini - data that developers may not realise is accessible at all.

Regional variation reveals infrastructure inconsistency

Aikido's research went beyond a single network location. The team ran a parallel experiment using virtual machines deployed in three Google Cloud regions: us-east1 in the eastern United States, europe-west1 in western Europe, and asia-southeast1 in Southeast Asia. After deleting a single key, all three VMs sent authenticated requests simultaneously.

The results showed significant regional divergence, particularly in the first minute after deletion. In one trial, us-east1 saw 82% of requests succeed in the opening minute. The europe-west1 VM saw 60%. The asia-southeast1 VM saw only 32%. Counterintuitively, the VM furthest from the United States picked up the deletion fastest.

Across the full revocation window, asia-southeast1 had a median request success rate of 22%, while both us-east1 and europe-west1 came in around 49%. Aikido notes that a VM in Singapore is not necessarily routing requests to servers in Singapore - Google's request routing is more complex than a direct geographic match. Whatever the underlying mechanism, the pattern held consistently across trials, pointing to differences in regional infrastructure, caching strategy, or routing affinity.

The apikey:UNKNOWN signal in GCP console

One unexpected finding emerged during monitoring in the GCP console. Using the "Traffic by Credential" graph, the researchers observed two distinct lines rather than one. The lower line - shown in blue in Aikido's documentation - tracked successful authentications after deletion. A second, upper line appeared, labelled apikey:UNKNOWN.

The UNKNOWN category captured rejected requests. Aikido tested this further by attempting authentication with a days-old deleted API key and found those requests were also bundled into the same apikey:UNKNOWN group. The researchers' best explanation is that Google preserves project attribution across key deletion, potentially to support key restoration.

For incident response teams, this creates a specific ambiguity. Any request made with any deleted Google API key - regardless of when it was deleted, and regardless of which key it was - gets grouped into the same UNKNOWN bucket. It is not possible to determine from that bucket alone whether a threat actor is actively replaying a recently deleted key, or whether the traffic reflects a legitimate service running against a different, older credential. Aikido's guidance is direct: if an investigation falls within the 23-minute window, look for valid authentications using the leaked key in the standard credential view. Outside that window, the risk appears extremely low.

Other credential types revoke faster - which makes this harder to justify

Perhaps the most pointed observation in Aikido's research is the comparison with other Google credential types on the same infrastructure. Service account keys, when deleted, propagate the revocation in approximately 5 seconds. Newer Gemini API keys, which carry an "AQ." prefix rather than the traditional "AIza" prefix, propagate in roughly 1 minute.

Both of these credential types operate at Google scale. Both demonstrate that faster revocation is technically achievable within Google's infrastructure. The 23-minute window for traditional Google API keys is not a fundamental constraint of distributed systems at this size - it is, at least in part, a product of where credential revocation sits in Google's engineering priorities.

Google Cloud issued a broader credential security advisory in March 2026, following the TruffleSecurity disclosure. That advisory described long-lived credentials as "a top security risk for unauthorized access" and urged users to audit their key configurations. Aikido's research adds a new dimension to that concern: the risk does not end when the delete button is clicked.

How eventual consistency affects authentication systems

The technical cause of the revocation delay is eventual consistency - a design pattern common across Google Cloud's services. In an eventually consistent system, updates propagate gradually across servers rather than all at once. For most use cases, this trade-off is invisible and acceptable. Database writes, configuration updates, and similar operations can tolerate a short lag without meaningful consequence.

Authentication is different. The specific property that eventual consistency violates - the expectation that a deleted credential is immediately invalid - is not a minor UX concern. It is the foundational guarantee that access control depends on.

A comparison drawn in Aikido's research is instructive. Eduard Agavriloae previously disclosed a 4-second window during which deleted AWS access keys could be used to create new credentials. Four seconds was considered significant enough to disclose and address. Google's equivalent window, in Aikido's testing, is roughly 345 times longer.

Just-in-time credential minting is another operational pattern that the 23-minute window breaks in practice. Services that dynamically create and immediately retire API keys - a pattern used to limit exposure windows - would need to build in a minimum 30-minute buffer after revocation before treating a key as definitively dead. That overhead makes the approach impractical for any workflow where credential lifecycle needs to be tight.

Google's response: won't fix

Aikido reported the findings to Google through a coordinated disclosure process. Google closed the report as "won't fix." The team's stated position, as Aikido describes it, is that propagation delay is a known property of the system and does not constitute a security issue.

Google does publicly document that its IAM API is eventually consistent. That documentation does not specifically address revocation delay for Google API keys. The gap between what the documentation discloses and what users experience when they delete a key - specifically, the console message that says the key can no longer be used - is where Aikido's critique sits.

This is not the first time Google's response to API key security research has been to decline action. TruffleSecurity's February 2026 disclosure, which showed that Google API keys had silently gained Gemini access, also initially met with dismissal before Google eventually acknowledged it. The pattern matters for marketing and advertising technology teams that rely on Google Cloud services. API keys are used across a wide range of integrations - Maps embeds in web properties, BigQuery pipelines feeding analytics dashboards, Gemini-backed features in customer-facing products. Each of those integrations carries a key. Each of those keys, when rotated in response to a security incident, retains authentication capability for up to 23 minutes.

What teams can do in the absence of a fix

Aikido's research includes practical framing for incident response, though no technical workaround exists that eliminates the revocation window.

First, the window should be treated as 30 minutes, not zero. Anyone responding to a leaked Google API key should assume the credential remains live for 30 minutes after deletion - slightly beyond the maximum 23-minute window observed in testing - and plan incident response activity around that assumption.

Second, the GCP console's API usage monitoring provides the only visibility available during the window. Under "Enabled APIs and services," the "Traffic by Credential" view will show requests associated with the deleted key for as long as the key continues to authenticate. Unexpected traffic after deletion is a signal that the key is still in active use. The apikey:UNKNOWN traffic in the same view reflects rejected requests, which may include both attacker activity and unrelated traffic from other old keys.

The absence of a programmatic way to confirm revocation completion - no webhook, no status endpoint, no console indicator - means teams cannot know when the window has closed. The 30-minute wait is a heuristic, not a guaranteed boundary.

Why this matters for marketing technology teams

Google API keys are among the most widely distributed credentials in the digital advertising and marketing technology ecosystem. Maps keys appear in website front ends. Gemini keys underpin content generation integrations. BigQuery keys feed data pipelines that drive measurement, attribution, and budget decisions. The attack surface is broad.

Marketing technology teams rarely operate with the same security tooling as dedicated engineering or security operations teams. Key rotation in response to an incident may be handled by a developer, an agency, or a platform vendor rather than a dedicated incident response function. The assumption that key deletion provides instant revocation is likely embedded in many incident response playbooks that have never been tested against Google's actual infrastructure behaviour.

Aikido's research provides a precise number - 23 minutes maximum, 16 minutes median - against which those playbooks can be updated. The fact that Google has closed the report without committing to a fix means the window is unlikely to narrow on any predictable timeline.

Timeline

  • February 26, 2026 - TruffleSecurity publicly discloses that Google API keys had silently gained the ability to authenticate with Gemini endpoints, exposing files, cached conversations, and billable AI resources to anyone who found a key in public code
  • March 1, 2026 - PPC Land publishes detailed coverage of the TruffleSecurity disclosure, tracing the root cause to API keys being designed as billing project identifiers rather than authentication secrets
  • March 3, 2026 - Google Cloud issues a security advisory urging all users to audit API keys and service account credentials, describing long-lived credentials as "a top security risk for unauthorized access"
  • Early May 2026 - Aikido Security researcher Joe Leon conducts 10 trials over two days measuring the Google API key revocation window, sending 3-5 authenticated requests per second after deletion
  • Early-to-mid May 2026 - Aikido runs a spot-check of its results to confirm the behaviour is not caused by transient network conditions
  • May 2026 (prior to publication) - Aikido reports the findings to Google; Google closes the report as "won't fix," describing propagation delay as a known property of the system
  • May 21, 2026 - Aikido Security publishes the full research, including methodology, trial data, regional variation across three GCP regions, console behaviour during the revocation window, and incident response guidance

Summary

Who: Aikido Security, a cloud security firm headquartered in Ghent, Belgium with offices in San Francisco, Chicago, and London. The research was authored by Joe Leon, a security researcher at Aikido. Google is the subject of the disclosure and declined to address the issue.

What: Research demonstrating that standard Google API keys continue to authenticate successfully for up to 23 minutes after being deleted, with a median window of 16 minutes across 10 controlled trials. During the revocation window, any API enabled on the project - including Gemini file access, BigQuery, and Google Maps - remains accessible to anyone holding the key. Google closed the vulnerability report as "won't fix."

When: The research was published on May 21, 2026. The controlled trials were conducted over two days in early May 2026, with confirmation spot-checks run several weeks later. Google's disclosure response came prior to publication.

Where: The research covers Google's global API key authentication infrastructure, with specific regional testing across three GCP data centers: us-east1 (eastern United States), europe-west1 (western Europe), and asia-southeast1 (Southeast Asia). Aikido Security is based in Ghent, Belgium.

Why: The revocation window creates a measurable window of exposure during incident response. A team that deletes a leaked API key expecting immediate revocation will, in practice, leave that key functional for up to 23 minutes. Given that standard Google API keys can now authenticate with Gemini endpoints - a behaviour documented in earlier research - the potential for data exfiltration during the window is concrete. The research is also significant because Google has already solved faster revocation for other credential types: service account keys propagate in roughly 5 seconds, newer Gemini-format keys in about 1 minute. The 23-minute window for traditional API keys is therefore not an inherent infrastructure limitation.

Share this article
The link has been copied!