I Leaked an API Key. What Now? A Step-by-Step Response

It happens to experienced developers too: a .env file committed to a public repository, a key in a screenshot, an AI-built app with a secret sitting in its front-end code. Automated bots scan GitHub and the web for exposed keys constantly, and a leaked key can be found and abused within minutes.

Don't panic, and don't delay. Here's what to do.

The first ten minutes: revoke and replace

1. Revoke the key at the provider

Go to the service's dashboard — your AI provider, Stripe, AWS, your database host, whatever it was — and delete or disable the leaked key. Then create a new one.

This is the step that actually protects you. Everything else is secondary.

Do this first, even before removing it from your code. Deleting the file or making the repository private does not un-leak the key: it's in Git history, in forks, in caches, and possibly already in someone's hands.

2. Update your app with the new key

Put the new key where it belongs — in your server's environment variables, not in code — and redeploy. (What Is an Environment Variable?.) Check the app works.

If it was a database password, change the password and update the connection string.

The next hour: check for damage

3. Look for abuse

Check the service's usage, billing, and logs for activity you don't recognise, from around the time the key was exposed:

AI providers — unusual token usage or spend.
Cloud providers (AWS, Google Cloud, Azure) — new servers you didn't create, often in unfamiliar regions. Leaked cloud keys are frequently used to run cryptocurrency miners.
Payment providers — refunds, transfers, or changes you didn't make.
Databases — unexpected connections, exports, deleted or changed data.
Email services — spam sent from your account.

4. Contain anything you find

Shut down resources you didn't create. Set or lower spending limits and alerts. If there's significant unauthorised usage, contact the provider's support — explain what happened and what you've done. Providers are often understanding about genuine leaks, especially when you act quickly.

5. Think about data exposure

If the key gave access to user data, you may have legal obligations — in the EU and UK, for example, some breaches must be reported to the regulator within 72 hours. (GDPR Basics for App Builders.)

The next day: clean up

6. Remove the secret from the code

If it was in front-end code: move the call that uses it to your server, so the key never reaches the browser. This is a design fix, not just a cleanup. (How to Keep API Keys Out of an AI-Built App.)
If it was in a committed file: stop tracking the file and add it to .gitignore. (What Is .gitignore?.)

git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Stop tracking .env"

7. Optionally, rewrite Git history

Tools like git filter-repo can remove a file from every commit in history. It's worth doing for public repositories, but understand the limits: it rewrites commits (everyone must re-clone), it doesn't reach forks or copies already made, and it doesn't make the old key safe. Only rotation does that.

8. Check for other secrets

Where there's one, there are often more. Search your code for other keys, or use a scanner such as gitleaks or trufflehog on the repository and its history. Ask your AI tool to do a sweep too:

Search the entire repository, including frontend code and config files, for anything that looks like an API key, token, password, or connection string. List each with its file and line.

How to stop it happening again

.gitignore your .env files from the very first commit.
Commit a .env.example with placeholder values instead.
Keep secrets on the server only. Front-end variables — NEXT_PUBLIC_, VITE_, REACT_APP_ — are public by design.
Turn on secret scanning. GitHub's secret scanning and push protection can block pushes containing known key formats, and is on by default for public repositories. Check your repository's security settings.
Use a pre-commit scanner like gitleaks to catch secrets before they're committed.
Use the narrowest keys possible — read-only where you can, restricted to specific services, with spending limits — so a leak does less damage.
Review AI changes before committing. AI tools occasionally paste a real key into code "to make it work." (How to Read a Diff.)
Blur screenshots and redact logs before sharing them.

The checklist

Revoked the leaked key and created a new one
App updated and redeployed with the new key, stored server-side
Checked usage and billing for abuse; contained anything found
Spending limits and alerts set
Considered whether user data was exposed
Secret removed from code and history (if public)
Repository scanned for other secrets
Secret scanning / push protection turned on

EasySpawn keeps each project's secrets in server-side environment variables inside an isolated workspace, so keys never need to live in your code, your commits, or your users' browsers. See how it works or join the waitlist.