A key in your code or git history is one of the most common leaks. Here is the plan, in the right order.
Rotate first, clean up second
The first step is always invalidating the key at the provider and creating a new one. As long as the old key is valid, it does not matter how thoroughly you clean your code.
Removing it from the current file is not enough: the old value is still in the git history and in every copy of the repository anyone ever made.
Pay particular attention to the service role key in Supabase, because it bypasses all policies.
Check what happened with the key
Many services show when and from where a key was used. Review those logs for traffic you do not recognise, and check whether data was read or changed.
Prevent the next one
- Never put secrets in code that ships to the browser; only in server-side environment variables.
- Use a secrets store instead of .env files that can be committed.
- Scan automatically for keys on every change before anything reaches the main branch.
- Give keys the smallest possible permissions and an expiry where you can.
Use the Supabase security checklist to check database permissions too.
Why AI-built projects hit this more often
An assistant getting something working fast will put a key straight in the code rather than set up an environment. It works immediately and it is invisible in the preview. It only surfaces when someone reviews the repository.
Before admitting your first users, review the launch checklist.
Frequently asked questions
Is a leaked Supabase anon key a problem?
Not by itself — it is meant to be public. It is a problem if your row level security is not in order, because then it opens everything.
Can I rewrite the git history?
You can, but it is laborious and others may already hold the old history. Rotating remains the only certain fix.
How do I find keys in my project?
Search for known patterns like 'service_role', 'sk_' and 'Bearer', and scan automatically as well — manual searching almost always misses something.