You Just Deleted a Compromised API Key. Now What?

You found a Google API key in a public GitHub repo. You deleted it immediately. Your work is done, right?

Not for the next 23 minutes.

Aikido Security's research confirms that deleted Google API keys continue authenticating requests for a median window of 16 minutes, with some keys remaining active for up to 23 minutes. This isn't a bug—it's a consequence of Google's eventually consistent architecture. For security teams responding to a credential leak, those 16 minutes represent a critical gap where an attacker who already has the key can continue using it.

The decision you face isn't whether to delete the key—that's obvious. The question is: what do you do during that window?

The Core Decision: React or Rotate?

When you discover a compromised Google API key, you have two primary paths:

Path A: Monitor and contain the existing key
Keep the deleted key in place, watch for abuse, and block malicious traffic as it appears.

Path B: Rotate to a new key immediately
Generate a replacement key, update all legitimate callers, and treat the old key as hostile from the moment you delete it.

Path C: Full service isolation
Disable the entire service temporarily while you investigate and implement controls.

Your choice depends on three factors: how the key was exposed, what it can access, and whether you can update your legitimate callers faster than an attacker can exploit the window.

Key Factors That Drive Your Path

Exposure Scope

If the key appeared in a public repository, assume it's been scraped. GitHub's secret scanning may have flagged it, but automated credential harvesters run constantly. If the key was exposed in a private channel or internal system, you have slightly more breathing room—but not 23 minutes' worth.

Service Criticality

A key for the Gemini AI API has different blast radius than a key for Google Maps geocoding. Check what the key authorizes. Can it read customer data? Trigger billable operations? Access internal systems through a Google Workspace integration?

Caller Architecture

Can you push a new key to all legitimate callers in under five minutes? If your applications pull configuration from a central secrets manager, rotation is fast. If keys are hardcoded in deployed containers or mobile apps, rotation becomes a deployment event.

Detection Capability

Do you have logging that shows API usage by key? Can you distinguish legitimate traffic from malicious requests during the deletion window? Google Cloud Logging captures API calls, but only if you've configured it for the specific service.

Path A: Monitor and Contain

Choose this path when:

• You have comprehensive logging for the affected service
• You can identify legitimate caller patterns (source IPs, request signatures, usage volume)
• The key has limited scope and you've confirmed no suspicious activity yet
• Rotating would require a deployment that takes longer than 23 minutes

Implementation steps:

1. Delete the key in Google Cloud Console (minute 0)
2. Set a 30-minute timer (not 23—build in margin)
3. Query Cloud Logging immediately:

   resource.type="api"
   protoPayload.authenticationInfo.principalEmail="[key-identifier]"
   timestamp>="[deletion-timestamp]"
   

4. Establish your baseline: What does normal usage look like? Requests per minute, source regions, endpoint patterns.
5. Watch for anomalies: Requests from new geolocations, unusual endpoints, volume spikes, or error patterns that suggest enumeration.
6. Use IP allowlisting if available: Many Google APIs support restricting keys to specific IP ranges. If you can add this restriction before deletion, do it—the restriction applies faster than deletion.

When this path fails:

If you see suspicious activity during monitoring, you're already in reactive mode. The attacker is using the window. Switch immediately to Path B or C.

Path B: Rotate Immediately

Choose this path when:

• The key was definitely exposed to untrusted parties
• You can update all legitimate callers within 5-10 minutes
• The service handles sensitive data or high-value operations
• You use a secrets management system (AWS Secrets Manager, HashiCorp Vault, Google Secret Manager)

Implementation steps:

1. Generate the replacement key first (minute 0)
2. Update your secrets manager with the new key
3. Trigger a configuration reload for all services (if your architecture supports hot reload)
4. Verify legitimate traffic is using the new key (check logs for the new key's identifier)
5. Delete the compromised key (minute 5-10)
6. Monitor both keys for the next 30 minutes

The critical insight: you need to complete rotation before you delete the old key. If you delete first and then scramble to update callers, you've created an outage.

The Service Account alternative:

Google Service Account keys have a revocation window of approximately 5 seconds according to Aikido's research. If your architecture can use service accounts instead of API keys, you've reduced your exposure window by 95%. Service accounts authenticate using short-lived tokens, and the underlying credential revokes almost immediately.

Consider this your long-term fix: migrate from API keys to service account authentication wherever Google supports it.

Path C: Full Service Isolation

Choose this path when:

• The compromised key has broad permissions
• You've detected active exploitation
• The service isn't time-critical (can tolerate 30-60 minutes of downtime)
• You need time to audit what happened during the exposure

Implementation steps:

1. Disable the service entirely (use Google Cloud Console to disable the API)
2. Delete the compromised key
3. Review all activity logs for the past 24-48 hours
4. Generate a new key with minimal required permissions
5. Re-enable the service only after confirming no persistent access was established

This is the nuclear option. You're trading availability for certainty. Use it when the cost of continued exposure exceeds the cost of downtime.

Decision Matrix

Factor	Path A: Monitor	Path B: Rotate	Path C: Isolate
Exposure	Private/limited	Public/confirmed	Public + active exploitation
Logging	Comprehensive	Partial acceptable	Required for forensics
Rotation speed	>30 min	<10 min	Not time-sensitive
Service criticality	Low-medium	Medium-high	Variable
Permission scope	Narrow	Moderate	Broad/privileged
Downtime tolerance	None	Minimal	30-60 minutes acceptable

The Longer Fix

The 23-minute window exists because Google prioritizes global availability over immediate consistency. For most use cases, this trade-off makes sense. For security operations, it doesn't.

Your immediate response handles the tactical problem. Your strategic response should eliminate API keys entirely where possible:

• Migrate to service account authentication (5-second revocation window)
• Use Workload Identity for GKE clusters (no long-lived keys)
• Implement API key rotation on a schedule (30-day maximum lifetime)
• Add IP restrictions to all keys at creation time
• Enable Google's secret scanning for your repositories

The Gemini API's newer key format demonstrates that faster revocation is technically feasible—it revokes in approximately 1 minute. Google may extend this to other services over time, but don't wait for it.

When you delete a compromised key, those 23 minutes are yours to manage. Choose your path based on what you can execute, not what feels most decisive. A well-monitored containment beats a botched rotation that creates an outage while the old key is still active.