The most dangerous part of a leaked credential is often the moment after everyone thinks the leak is handled.

Aikido Security published research on May 21 showing that standard Google API keys can keep authenticating after users delete them. The company ran ten trials over two days, deleting keys while continuing to send authenticated requests, and measured a median revocation window of about 16 minutes. The longest observed window was nearly 23 minutes. Aikido added on May 22 that Google had reopened the report and was treating it as a P0 bug after initially closing it as a won't-fix propagation-delay issue.

That is not a theoretical footnote in a distributed-systems textbook. It is a live operational gap. If an attacker already has the key, deletion may remove the credential from the owner's console before every authentication path has stopped accepting it.

Revocation is a window

API keys occupy a strange place in cloud security. Google documents that standard API keys associate requests with a project for billing and quota, but do not identify a principal the way IAM-based credentials do. They are still powerful enough to matter. If a project has APIs enabled and a key is unrestricted, the key can be the thing that turns a public leak into usage, data exposure, or a surprise bill.

Aikido's useful framing is the revocation window: the time between deleting a key and the last successful authentication with that key. In a clean mental model, that window is close to zero. In the observed Google API key tests, it stretched long enough for an attacker to keep probing globally distributed authentication infrastructure until a request landed on a server that had not caught up.

The research also found uneven behavior by region and request path. In one regional set of tests, immediately after deletion, requests from different GCP regions saw very different success rates. That matters because defenders do not get a single reliable cutoff. They get decay. Some requests fail, some still work, and the person responding to the incident has to assume the credential remains dangerous until the window closes.

The UI is part of the contract

There is a fair engineering explanation for why this can happen. Large cloud platforms cache state, route requests across regions, and use eventually consistent control planes. That design can be reasonable for many resource updates. It becomes much harder to defend for credential revocation, because the user action is not cosmetic. The user is trying to stop access.

The mismatch between the button and the behavior is the issue. When a console presents deletion as the moment a key can no longer be used, teams will write incident runbooks around that assumption. They will delete the key, rotate the secret in the app, and move on to post-incident cleanup. Aikido's tests say that is too early. For this credential type, deletion should be treated as the start of a 30-minute monitoring period, not the end of the breach path.

This is especially important in the current Google API key mess around AI services. Keys that once felt like ordinary developer plumbing can become access paths to Gemini workloads, uploaded files, cached context, Maps, BigQuery, or whatever else the project has enabled and the key is allowed to call. That combination of broad API reach, automatic billing exposure, and delayed revocation is exactly the kind of risk that turns a small secret leak into a very expensive race.

What teams should change

The first fix is cultural: stop treating delete as proof of death. After a suspected Google API key leak, assume the old key can still work for 30 minutes. Keep watching traffic by credential under Enabled APIs and services. Watch billing and quota. Look for valid requests that arrive after the deletion action, not just before it.

The second fix is architectural: do not rely on deletion as the main control. Google already recommends API key restrictions, and this incident makes that advice less optional. Restrict keys by API, application, referrer, package identity, or IP wherever the product allows it. Inventory unrestricted keys. Use service-account or workload-identity patterns where the workload actually needs authorization, not just project association. Keep API keys out of server-to-server trust paths when a better credential type exists.

The third fix belongs to providers. Authentication needs different consistency expectations than dashboards, labels, and metadata. Cloud customers can tolerate a stale UI field. They cannot safely tolerate a deleted credential that still works long enough for an attacker to exploit it while the console claims the access path is gone.

The lesson is not that Google Cloud is uniquely fragile or that distributed systems are easy. The lesson is that security controls have to be judged by their failure windows. A deleted key that still authenticates is not deleted in the way incident responders mean the word. Until revocation is immediate and observable, teams should handle Google API key deletion as an active containment window, not a completed containment step.

Sources