Leaked an API key? What to do in the first hour

Updated 22 October 2026

If an API key ended up somewhere it shouldn’t (a public repository, a chat, a ticket, a screenshot, a forum post) treat it as compromised. Automated scanners watch public sites for keys around the clock, and leaked cloud and AI keys are often used within minutes.

The order matters: stop the key working first, investigate second. Investigating while the key still works gives an attacker more time.

1. Revoke or rotate the key now

Go to the provider’s dashboard and disable the key. Most providers let you create a replacement first and then delete the old one, but if the leak was public, delete it straight away and accept a few minutes of downtime.

Cloud providers (AWS, Google Cloud, Azure): deactivate the access key, then delete it.
Payment providers (Stripe and similar): roll the key and set the old one to expire immediately.
AI providers (OpenAI, Anthropic and others): revoke the key in the API keys page.
Code hosts (GitHub, GitLab): delete the token in your developer settings.

Our secret type pages list the exact steps for the most common keys.

Deleting the message, commit or post where the key appeared is not enough. Copies may already exist in caches, notifications, search indexes and other people’s screens.

2. Replace it everywhere it was used

Create a new key and update every place that used the old one: servers, CI/CD secrets, serverless functions, local .env files and teammates’ machines. Search your infrastructure for the old key’s prefix or ID to find stragglers.

Give the new key only the permissions it needs. A leak is a good moment to replace a broad admin key with several narrow ones.

3. Check whether it was used

Look for activity between the moment the key leaked and the moment you revoked it:

Audit logs: AWS CloudTrail, Google Cloud audit logs, GitHub’s security log, Stripe’s request logs.
Billing and usage: sudden spikes in compute, AI tokens or API calls are the most common sign of abuse.
New resources: unfamiliar servers, users, access keys, webhooks or OAuth apps, in every region.
Data access: downloads, exports or reads of customer data.

If you find unauthorised activity, contact the provider’s support. Many will review fraudulent usage charges, and they can help you find what the attacker created.

4. Remove it from where it leaked

Now clean up: delete the message, edit the post, close the ticket, or rewrite the Git history (see secret committed to Git). This limits further exposure but doesn’t undo the leak, which is why it comes after rotation.

5. Tell the people who need to know

If the key belongs to your employer or a client, tell their security team now, even if you have already rotated it. They may need to check other systems, and many companies are required to log security incidents. If customer data may have been accessed, privacy law may require notifying a regulator within a short deadline (72 hours under the GDPR, for example), so involve your privacy or legal team early.

6. Make the next leak less likely

Keep keys in a secrets manager or environment variables, never in code.
Add .env files to .gitignore and run a secret scanner such as gitleaks as a pre-commit hook.
Turn on push protection in GitHub or GitLab so commits containing keys are blocked.
Use short-lived credentials where you can (cloud roles, OIDC in CI) instead of long-lived keys.
Redact logs before you paste them into an AI assistant, an issue or a support ticket.