Google API keys revocation delay creates a significant security blind spot: deleted keys can remain usable for more than 20 minutes, according to testing by Aikido Security researchers. When you delete a key from Google Cloud, you expect it to stop working immediately. The reality is far messier. Revocation propagates gradually across Google’s infrastructure, leaving a window where attackers holding a deleted key can still abuse it.
Key Takeaways
- Deleted Google API keys remain functional for up to 23 minutes in testing, with a median revocation time of 16 minutes.
- Aikido Security researchers tested 10 trials over two days and found shortest revocation at 8 minutes, longest at 23 minutes.
- Google does not consider the propagation delay a security issue and has no plans to fix it.
- Different key types revoke at different speeds: Service Account keys in 5 seconds, new Gemini API keys in 1 minute, standard keys in up to 23 minutes.
- Users cannot confirm exactly when a deleted key stops working, eliminating any ability to verify successful revocation.
The Revocation Gap: What Aikido Security Found
Aikido Security researchers discovered that Google API keys exhibit a dangerous revocation lag. After deleting a key, the deletion does not propagate instantly across Google’s servers. Some servers reject the deleted key within seconds. Others continue accepting it for much longer. In the research described, the longest observed revocation window reached 23 minutes. The median revocation time across trials was around 16 minutes. The shortest observed window was nearly 8 minutes. This means an attacker who obtains a leaked or exposed Google API key can continue sending requests after a user believes they have disabled it, as long as those requests hit a server that has not yet received the revocation update.
The inconsistency stems from how Google‘s infrastructure handles credential propagation. When you delete a key, the deletion must propagate across multiple servers and data centers. This is not instantaneous. Aikido Security’s testing showed that some servers caught up quickly while others lagged significantly. The researchers noted that an attacker holding a deleted key can keep sending requests until one reaches a server that has not caught up. This window of vulnerability is especially dangerous if Gemini is enabled on the project. In that scenario, an attacker could dump files you have uploaded and exfiltrate cached conversations.
Google’s Response: A Known Property, Not a Fix
Google’s stance on the issue is troubling. The company describes the propagation delay as a known property of the system, not a security issue. This means Google does not plan to fix it. Google Cloud’s documentation states that once deleted, a key can no longer be used to make API requests. The research contradicts that claim in practice. Users who delete a key believing they have immediately revoked access are operating under a false assumption. The company offers no way to revoke a key faster or to confirm exactly when a deleted key stops working. This lack of transparency leaves users blind to the actual security state of their credentials.
The researchers emphasized that long consistency windows are fundamentally incompatible with authentication. The expectation when you delete a credential is that the credential is dead. Google’s approach violates that expectation. Users cannot treat deletion as an emergency response to a leaked key because deletion does not actually stop the key from working right away. This gap between user expectation and actual behavior creates a false sense of security.
Different Key Types, Different Revocation Speeds
Not all Google API keys behave the same way during revocation. The research revealed stark differences depending on key type. New Gemini API keys with AQ. prefixes were revoked in around one minute. Google Service Account keys were revoked in around five seconds. Standard Google API keys, however, showed the longest delays—up to 23 minutes in testing. This inconsistency means the security posture of your credentials depends on which key type you are using. If you are relying on a standard API key for sensitive operations, you are exposed to a much longer revocation window than users of Service Account keys.
The variation suggests that Google’s infrastructure handles different credential types differently. Some systems prioritize fast revocation for certain key categories. Others do not. This patchwork approach leaves standard API key users at a disadvantage. An attacker who knows the key type can estimate roughly how long they have to exploit a deleted credential before it stops working across all servers.
What This Means for Google Cloud Users
The practical impact of the Google API keys revocation delay depends on your threat model. If you suspect a key has been exposed, deleting it does not immediately stop an attacker from using it. You should assume the key remains active for at least 20 to 30 minutes after deletion. The researchers recommend treating key deletion as a 30-minute procedure rather than an instant one. During that window, an attacker with the deleted key can continue making API calls, accessing files, and if Gemini is enabled, exfiltrating conversations and uploaded content.
For organizations handling sensitive data or running security-critical applications, this is a significant problem. You cannot rely on key deletion as an emergency mitigation. You must assume continued exposure for half an hour. If a key is compromised, the damage may already be done before revocation fully propagates. The lack of a faster revocation mechanism or a way to confirm when revocation is complete leaves you guessing about your actual security state.
Why Google’s Approach Falls Short
Google’s decision to treat this as a known property rather than a security issue reflects a broader infrastructure trade-off. Distributed systems often prioritize eventual consistency over immediate consistency. Google’s approach accepts that credential revocation will take time to propagate. However, this trade-off is inappropriate for authentication. Credentials are not like database records. When you revoke a credential, you need it to be revoked everywhere, immediately. Accepting a 20-minute lag fundamentally undermines the security model users expect.
The lack of transparency compounds the problem. Users cannot see how long revocation is taking. They cannot query a status endpoint to confirm when a key has stopped working everywhere. They must simply wait and hope. This opacity makes it impossible to respond intelligently to a key compromise. You cannot verify that your emergency response actually worked.
How This Compares to Other Cloud Providers
The article references a prior issue with AWS access keys, where a four-second delay in credential revocation enabled attackers to exploit deleted credentials and create new ones. While AWS’s delay was shorter, the principle is the same: revocation is not instant. Google’s 20-minute window is significantly longer than what users would tolerate from other providers. The fact that Google Service Account keys revoke in five seconds proves that Google’s infrastructure can handle faster revocation. The company has chosen not to apply that speed to standard API keys.
Protecting Yourself Until Google Fixes This
Until Google addresses the Google API keys revocation delay, you should adopt defensive practices. If you suspect a key is compromised, rotate it immediately and assume the old key remains active for 30 minutes. Monitor API activity during that window for any unusual requests. If Gemini is enabled on your project, assume an attacker could access uploaded files and cached conversations. Consider using Service Account keys instead of standard API keys for sensitive operations, since they revoke much faster. Implement rate limiting and IP whitelisting to reduce the window of opportunity for attackers using deleted keys. Use API key restrictions to limit what each key can access, reducing the blast radius of a compromise.
FAQ
How long does it take for a deleted Google API key to stop working?
According to Aikido Security research, deleted Google API keys can remain usable for up to 23 minutes, with a median revocation time around 16 minutes. The exact time varies depending on which servers process your API requests.
Can I check if my deleted Google API key has been fully revoked?
No. Google provides no way to confirm when a deleted key stops working. You cannot query a status or receive a notification. You must simply wait and assume the key remains active for 30 minutes after deletion.
Which Google key types revoke the fastest?
Google Service Account keys revoke in around five seconds, and new Gemini API keys with AQ. prefixes revoke in around one minute. Standard API keys take much longer, up to 23 minutes in testing.
What should I do if I think my Google API key was leaked?
Delete the key immediately and rotate to a new one. Assume the deleted key remains active for 30 minutes. Monitor your API activity for suspicious requests during that window. If Gemini is enabled on your project, review your uploaded files and conversation history for unauthorized access.
The Google API keys revocation delay is a real security gap that Google refuses to address. Users must adapt their security practices to account for a 20-to-30-minute window where deleted keys still work. Until Google implements faster revocation or adds transparency to the process, treating key deletion as an emergency response is unreliable. Rotate your keys regularly, use Service Account keys for sensitive operations, and never assume a deleted key is immediately dead.
Edited by the All Things Geek team.
Source: TechRadar
