One of seven checks in the Full Scan

Find leaked API keys and passwords in your GitHub repo

AI builders write code fast, and sometimes they write a secret straight into it. Once a key is committed, deleting the line does not remove it: it stays in the history for anyone who can read the repo. This check finds those keys before someone else does.

What this check looks for

LeakScan clones your repository read-only and scans every file plus the last 300 commits for the patterns real keys follow.

  • Supabase service role keys and secret keys
  • Stripe and Paddle secret keys
  • OpenAI, Anthropic and other AI provider keys
  • Database connection strings with a password in them
  • Private keys, tokens and passwords in config files such as .env

Why old commits matter

Removing a key from the latest version of a file only hides it from the current view. Git keeps every earlier version, so a key that sat in the repo for one commit is still readable by anyone with access, and by anyone who cloned it while it was there.

That is why the only safe fix for a leaked key is to rotate it: create a new key, switch the app to it, and revoke the old one. The report tells you which key leaked, in which file and commit, and gives you the prompt to move it into an environment variable.

What you get in the report

Each finding names the kind of key, where it was found and how bad it is. A service key that bypasses your database rules ranks as critical; a test key ranks lower. Every finding comes with a fix prompt you paste into your builder.

Common questions

Does LeakScan keep a copy of my code?

No. The repository is cloned read-only into a temporary folder that is deleted when the scan ends. Stored credentials are deleted 14 days after you connect them, or earlier with one click.

My repo is private. Is a leaked key still a problem?

Yes, but a smaller one. Anyone you have ever given access to, any tool connected to the repo and anyone who gains access later can read the history. Rotate keys that were ever committed.