Leaked an API Key? What to Do in the Next 15 Minutes

You hit push, glance at the diff on GitHub, and there it is: your API key, in plain text, in a public repo. Or you scroll up in a ChatGPT conversation and realize the "config snippet" you pasted had a live token in it.

First: this happens to experienced engineers all the time. Second: the order of what you do next matters more than how fast you panic. Revoke first. Investigate second. Clean up last.

Step 1: Revoke or rotate the leaked API key — right now

Don't start by deleting the commit or the message. Automated scanners watch public GitHub commits continuously, so assume the key has already been copied. The only fix that works everywhere at once is making the key useless.

Every major provider lets you do that from its dashboard:

• OpenAI / Anthropic: delete the key on the API keys page of the platform dashboard or console, then create a new one.
• GitHub: Settings → Developer settings → Personal access tokens. Delete the token and generate a replacement with the narrowest scopes that work.
• AWS: in IAM, deactivate the access key, create a new one, update your apps, then delete the old key. If you suspect misuse, follow AWS's guidance for compromised credentials and open a support case.
• Google Cloud / Firebase: APIs & Services → Credentials. Regenerate or delete the key, and add API and app restrictions to the new one.
• Stripe: Developers → API keys → roll the key. Stripe lets you keep the old key alive for a short overlap so you can deploy without downtime.
• Slack, Discord, Telegram webhooks or bots: regenerate the token or delete and recreate the webhook.

Step 2: Check what the key was used for

Now that the door is locked, find out whether anyone walked through it while it was open. Look at the window between when the key leaked and when you revoked it.

• Usage and billing dashboards for AI providers — a spike in requests or spend you don't recognize is the classic sign.
• AWS CloudTrail for API calls made with that access key ID, especially new IAM users, new keys, or instances launched in regions you never use.
• GitHub's security log for token activity, new deploy keys, or changes to repositories and webhooks.
• Your own logs if the key protected an internal service.

Photo by Jakub Żerdzicki on Unsplash

If you find activity you didn't cause, treat it as an incident rather than a cleanup: tell your team, contact the provider's support, and ask about disputed charges. Report it as soon as you can — the earlier a provider hears about misuse, the more options it has to help.

While you're in the billing settings, set a hard spending limit or budget alert if the provider supports one. It turns the next leak from a surprise invoice into an email.

Step 3: Update everything that used the old key

Revoking a key breaks whatever was using it, which is exactly why people put this step off. List every place the old key lived: production environment variables, CI/CD secrets, staging servers, teammates' local .env files, scheduled jobs, and that one script on the old VM nobody remembers.

If that list is long, it's a sign the key should live in a secret manager (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) instead of being copied around by hand.

Step 4: Clean up where it leaked

Now — and only now — tidy up the original leak, so the dead key doesn't keep setting off scanners or confusing your team.

In a Git repository

A new commit that removes the key leaves it sitting in history, one git log away. To remove it from history, rewrite it with git filter-repo (or the older BFG Repo-Cleaner), then force-push:

# replacements.txt contains one line per secret:
# <the-leaked-value>==>[REDACTED]
git filter-repo --replace-text replacements.txt

# filter-repo removes the origin remote as a safety measure — re-add it
git remote add origin <your-repo-url>
git push --force --all
git push --force --tags

Rewriting history changes commit hashes, so coordinate with anyone who has a clone. Forks and existing clones keep the old history, and GitHub may still serve cached views of old commits — its "Removing sensitive data from a repository" docs explain how to ask support to purge them. This is exactly why Step 1 comes first.

In an AI chat, Slack or a ticket

Delete the message or conversation, and revoke any shared links to it. In ChatGPT, shared links are listed under Settings → Data controls → Shared links. If a vendor's support team received the key in a ticket, tell them it's been rotated.

Step 5: Make the next leak less likely

• Keep secrets out of files you commit. Add .env to .gitignore before the first commit, and commit a .env.example with placeholder values instead.
• Turn on push protection. GitHub has enabled secret-scanning push protection by default for public repositories since February 2024; it blocks pushes containing recognized secrets. Check it's on for your private repos too, where your plan supports it.
• Add a pre-commit hook. Tools like gitleaks can scan staged changes before a commit even exists.
• Scan before you paste. Logs, stack traces and config snippets are the usual culprits when keys end up in chats and tickets. Our API Key & Secret Scanner highlights them and gives you a redacted copy, entirely in your browser.
• Use narrower, shorter-lived keys. Fine-grained GitHub tokens with an expiry, restricted Stripe keys, and per-project AI keys all shrink the blast radius when one gets out.

Photo by Glenn Carstens-Peters on Unsplash

The short version

1. Revoke or rotate the key with the provider.
2. Check usage and billing for the exposure window.
3. Update every app and pipeline that used it.
4. Clean up the repo history, chat, or message.
5. Add guardrails so it doesn't happen again.

If the leak happened in an AI chat, our guide on whether it's safe to paste API keys into ChatGPT covers how to keep getting help with code without handing over credentials.