Google API Keys Don't Die When You Kill Them

Google API Keys Don't Die When You Kill Them

A 23-minute authentication ghost window turns routine key rotation into a live security liability.

Written by OutOfToken AI

June 3, 2026 · 4 min read · Synthesized from reporting by Dark Reading · How this works

AI Likely Accurate · 7/10

When a developer deletes a Google API key — whether responding to a leak, rotating credentials, or locking down a compromised service — they expect immediate revocation. According to research published by cybersecurity firm Aikido Security, that expectation is wrong by nearly half an hour. Deleted Google API keys continue authenticating successfully for up to 23 minutes post-deletion, a window wide enough for a motivated attacker to extract data, hammer AI endpoints, or pivot deeper into connected infrastructure.

What the Research Actually Found

Aikido Security's researchers conducted controlled testing against Google Cloud Platform, repeatedly deleting API keys and attempting to use them against live GCP services — including the Gemini AI API — after the console confirmed deletion. The GCP dashboard displayed the key as removed immediately. Authentication calls kept succeeding. Their testing established a consistent upper boundary of approximately 23 minutes before the key finally stopped working. Crucially, there is no confirmation mechanism, no event log entry, and no way for a developer to verify exactly when — or whether — a deleted key has fully expired across Google's infrastructure.

The Architecture Behind the Delay

The root cause is not a bug in the conventional sense — it is a structural consequence of how large-scale distributed systems handle state changes. Google's authentication layer relies on eventual consistency, a design pattern in which updates propagate across geographically distributed nodes over time rather than synchronously. When a key is deleted, the change registers in the control plane immediately, but authentication edge nodes continue serving cached credential states until those caches expire or receive propagation updates. This is a known trade-off in distributed systems engineering, one that prioritises low-latency authentication reads over instant revocation writes. The problem is that Google's documentation and console UI present deletion as instantaneous, creating a dangerous gap between user expectation and system reality.

""When you delete an API key, you expect access to end immediately. Our testing says otherwise — ~23 minutes of continued access, with no way to revoke it faster or confirm when it stops working." — Aikido Security"

Why This Window Is Exploitable — and Why Google's Silence Makes It Worse

Twenty-three minutes is not an edge case. In a breach scenario, an attacker who has already exfiltrated a key and is monitoring for its deletion — a trivially detectable event if they retain any access to a target's environment — can continue operating through that window with full authentication rights. Affected services include not just storage and compute APIs but Gemini, Google's flagship generative AI platform, which could be abused to exfiltrate context, execute prompt injection, or rack up significant API costs at the victim's expense. Aikido shared its findings with Google ahead of publication. Google's response characterised the propagation delay as an expected property of the system rather than a vulnerability requiring remediation. No fix, timeline, or mitigation guidance was offered. That posture — acknowledging the behaviour while declining to address it — leaves enterprise customers holding a risk they cannot fully manage.

The Aikido findings force a harder conversation about honesty in cloud security guarantees. Eventual consistency is a legitimate architectural choice, but shipping a UI that says 'deleted' when the accurate status is 'scheduled for deletion in approximately 23 minutes' is a transparency failure with real security consequences. Until Google either accelerates key invalidation propagation or updates its documentation to reflect actual revocation timelines, security teams should treat key deletion as the beginning of a revocation process — not the end of one. Incident response playbooks need updating, and the broader cloud industry should treat this as a prompt to audit every 'immediate' revocation claim in their own platforms.

Editorial Note

Google API key deletion does involve propagation delays across distributed systems, though the specific 23-minute window would need independent verification. Dark Reading is a reputable cybersecurity publication with established track record for reporting security vulnerabilities. This type of eventual consistency issue in cloud systems is technically plausible and has been documented in similar services.

Claim Tracker

AI-assessed

UnverifiedDeleted Google API keys continue authenticating successfully for up to 23 minutes post-deletion

Based on Aikido Security research but independent verification by Google or third parties not mentioned; upper boundary claim not substantiated with methodology details

UnverifiedThe GCP dashboard displayed the key as removed immediately while authentication calls kept succeeding

Describes Aikido's test results but lacks independent confirmation or Google's official response

UnverifiedThere is no confirmation mechanism, no event log entry, and no way for a developer to verify when a deleted key expires

Absolute claim about feature absence not confirmed by Google documentation review or official statement

UnverifiedTesting was conducted against Google Cloud Platform services including the Gemini AI API

Aikido claims controlled testing but full methodology and scope not provided in excerpt

Ask AI about this story

// discussion

sign in to join the discussion