Someone Found My API Key. What Do I Do Right Now?

You got the email. GitHub secret scanning, a note from a stranger, an OpenAI usage alert at 3 a.m., or a Stripe charge you did not make. Somewhere in a public repo, a browser bundle, or a screenshot in your Discord, a key that was supposed to be private is now not private.

The instinct is to delete the commit and hope. Do not do that. Deleting the commit does nothing to the key, and it destroys the evidence you need to figure out what happened.

Work the list below in order. The whole thing takes about an hour for a small app, and the order matters more than the speed.

The first fifteen minutes: rotate, do not delete

A leaked key stays valid until you invalidate it at the provider. Nothing you do in your repo changes that. So the very first action is to go to the provider's dashboard and revoke or roll the key — Stripe, OpenAI, Supabase, AWS, SendGrid, whoever issued it.

Two rules that people get wrong under pressure:

• Revoke before you replace. If your provider supports creating a second key before killing the first, create the new one, deploy it, then revoke the old one. If it does not, take the thirty seconds of downtime. Downtime is cheaper than a live key in someone else's hands.
• Assume the whole file leaked, not one line. If a .env file made it into a commit or a client bundle, every value in it is burned. Rotate all of them, including the ones that look harmless.

Then set the new value in your host's environment settings — not in the code — and redeploy. If your variables have a habit of not surviving that trip, our walkthrough on environment variables that work locally and not in production covers the usual traps.

Triage by key type — the blast radius is not the same

Not every leaked credential deserves the same panic level. Use this to decide what to do next after rotation.

That last row is the one worth internalizing. Public keys are meant to be public. If your app breaks when someone sees the anon key, the key was never the problem — the missing authorization was. That is a different fix, and Supabase RLS policies that are not actually working is the place to start.

Find out what the key actually did

Rotation stops the bleeding. Now find out whether anyone used it. Every serious provider keeps a log, and most founders never open it.

Look for the three signals that separate "scanned by a bot" from "actively abused":

1. Requests from IPs or regions you have never deployed to. A key used from three continents in one hour is being resold.
2. Call patterns that are not your product. Model names you do not use, endpoints your app never hits, bulk reads at a rate no human triggers.
3. New resources. New IAM users, new webhooks, new API keys created using the leaked key. This is how a one-time leak becomes persistent access, and it survives rotating the original key.

Bots scrape public commits within minutes, so assume automated discovery even if the repo was public for an afternoon. Sustained abuse is different — treat it as an incident, write down the timeline, and check whether customer data was in scope. That decision is a legal one as much as a technical one.

Purge the key from history, properly

Now, and only now, deal with the repo. A key committed in March and removed in April is still sitting in the object history of every clone. Removing the line in a new commit changes nothing.

For a small project, the fastest safe path is a history rewrite with git-filter-repo or the BFG Repo-Cleaner, followed by a force push and a note telling collaborators to re-clone. Anyone still holding the old history holds the old key.

If the repo is public and the leak is old, be realistic: rewriting history is hygiene, not remediation. The rotation you did in step one is the remediation.

Do not forget the places secrets hide outside git: build logs, CI environment dumps, error-monitoring payloads, browser bundles, and the AI chat where you pasted your config file to ask why something was broken.

Why this keeps happening to AI-built apps

There is a pattern behind these incidents. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% year over year, and AI-assisted commits leaked at roughly 3.2% versus a 1.5% baseline. Assistants write working code, and the shortest path to working code is often the key inline.

The specific failure we see most often in vibe-coded apps is a server-side key called from the browser — the model needs a fetch to succeed, so it puts the secret where the fetch can reach it. That single pattern is covered in depth in API keys exposed in the frontend, and it is worth checking your bundle for it today rather than after the next alert.

Make the next leak impossible to miss

• Turn on push protection and secret scanning in your git host. It is free and it blocks the commit before it exists.
• Add a pre-commit secret scanner locally so the block happens on your machine.
• Move every secret to your host's environment settings, and give the deployed app the only copy.
• Set hard spend caps on every metered API. A cap turns a catastrophic leak into an annoying one.
• Run a one-time sweep of your existing history — the leak you have not found yet is more dangerous than the one you just fixed. A structured secret scan of an AI-generated codebase usually finds two or three.

Frequently asked questions

Do I have to tell my customers? Only if their data was in scope and accessed — a leaked OpenAI key that burned credits is a billing problem, while a leaked database credential with evidence of reads is a disclosure question. Write the timeline down first, then decide with someone who knows your jurisdiction.

The repo was private. Am I fine? Better, not fine. Private repos leak through forks, contractors, integrations with third-party tools, and any laptop that ever cloned them. Rotate anyway; it costs you ten minutes.

How do I know if there are more keys I have not found? Scan the full history rather than the working tree, and include CI configs, notebooks, mobile builds, and old branches. Most founders who scan properly find at least one credential they forgot existed.

---

If you found one key in the open, there are almost certainly others, and the fix is a pattern change rather than a one-off rotation. SprintX audits AI-generated codebases for exposed secrets, missing authorization, and the frontend calls that cause both — with a fixed scope and a report you can act on. Send us your repo and we will scan it.