Leaked an API Key? What to Do in the First Hour

Automated scanners watch public GitHub pushes continuously. A cloud credential pushed to a public repository can be found and used within minutes, and paid API keys — AI providers in particular — are abused for their quota almost as quickly. Assume the key is already in someone else's hands.

The order of the steps below matters. The instinct is to delete the commit first; that is the least important step, and doing it first wastes the minutes that count.

1. Identify exactly what leaked

Before you can revoke a key, you need to know which provider and which account it belongs to, and whether it is live or test. Paste it into the API key detector — it recognises the format of keys from dozens of providers, shows whether the key is a live or test credential, and links to the revocation page. Detection runs in your browser, so you are not leaking the key a second time.

Then ask: what can this key do? A read-only analytics token and an AWS root access key are different emergencies. The blast radius analyzer walks through what a credential can reach.

2. Revoke or rotate — immediately

Revocation is the only step that actually stops an attacker. Deleting the commit, making the repository private or force-pushing does nothing about a copy someone has already taken.

• If nothing depends on the key, revoke it outright.
• If production depends on it, rotate: create a new key, deploy it, then revoke the old one. Do this in minutes, not after the next release cycle. A short outage is cheaper than an abused key.

The revocation command generator produces the exact API call or dashboard path for common providers. For AWS, deactivating the key is a single CLI call:

aws iam update-access-key --access-key-id AKIA… --status Inactive --user-name deploy-bot

Deactivate first, then delete once you are certain nothing legitimate still uses it.

3. Check whether it was used

Revocation stops future use; it does not tell you about the past. Look for activity between the moment of exposure and the moment of revocation:

• AWS: CloudTrail events for the access key ID — look especially for RunInstances in regions you do not use, new IAM users or access keys, and billing spikes.
• Stripe and payment providers: unexpected refunds, payouts or changes to payout bank accounts.
• AI and SaaS APIs: usage dashboards and invoices for unusual volume.
• GitHub tokens: the security log, and new deploy keys, webhooks or collaborators on repositories the token could reach.

If an attacker created new credentials while they had access, revoking the original key does not remove theirs. Look for persistence before you close the incident.

4. Remove it from history

Now — and only now — clean up the repository. Deleting the file in a new commit leaves the secret in every earlier commit. Rewrite history with git filter-repo:

# Replace every occurrence of the secret across all history
echo 'sk_live_51Hq…==>REDACTED' > replacements.txt
git filter-repo --replace-text replacements.txt
git push --force --all
git push --force --tags

Then deal with the copies you do not control: forks, open pull requests, CI logs, and caches of the repository. On GitHub, ask support to purge cached views of the affected commits. This is hygiene, not remediation — the key is already revoked.

5. Find anything else that leaked with it

Secrets rarely leak alone. A committed .env file usually contains five of them. Scan the commit, the rest of the repository and any logs with the secret leak scanner and the hardcoded secret linter, and rotate everything they find.

6. Make the next one impossible

• Ignore secret files by default. Generate a .gitignore covering .env, key files and credential exports with the gitignore generator, and commit a .env.example with placeholder values instead.
• Turn on push protection. GitHub secret scanning push protection blocks pushes containing recognised credentials. Pre-commit hooks such as gitleaks or trufflehog catch the rest locally.
• Never ship secrets to the browser. Anything in a frontend bundle — including variables with NEXT_PUBLIC_ or VITE_ prefixes — is public. See where to store API keys.
• Use short-lived credentials. Cloud roles, OIDC federation from CI and expiring tokens turn a leak into a short window rather than a standing risk.
• Use recognisable formats. If you issue keys yourself, a distinctive prefix lets scanners catch your customers' leaks for you.

The checklist

1. Identify the provider, account and environment of the key.
2. Revoke it, or rotate and then revoke within minutes.
3. Audit usage between exposure and revocation; look for persistence.
4. Rewrite git history and purge caches.
5. Scan for and rotate every other secret exposed alongside it.
6. Add ignore rules, push protection and pre-commit scanning.
7. Write down what happened and what you changed.