AI hardcoded an API key into your repo. Catch it before it ships.

Your AI assistant just pasted a live API key straight into your source code. Catch it with an automated secret scanner wired into a pre-commit hook, block the commit before it lands, and rotate anything that already leaked. That's the whole fix. Everything below is why it matters and how to wire it up.

What breaks when a live key hits your repo?

A key in source control is a breach with a countdown. The second it's committed, it's copied. Cloned, forked, cached, mirrored. You can delete the line, delete the commit, even make the repo private. The key is still sitting in your git history, and history is forever.

That's not a scare story. GitGuardian scanned 1.4 billion commits and found 23.8 million secrets leaked on public GitHub in 2024, up 25% from the year before. The problem isn't shrinking. It's compounding. Right now, 4.6% of all public repositories have a secret sitting in them.

Here's the part that should keep you up. 70% of secrets leaked in 2022 were still valid at the time of GitGuardian's 2025 report. People “deleted” them years ago. They still open the door. In its 2024 report, GitGuardian called the deleted-but-still-live ones zombie leaks, and found over 90% of exposed secrets stay active five days after they leak, even after the author gets told. Deleting the commit does nothing. The credential still works.

Want to know what one key costs? In 2024, attackers walked into the U.S. Treasury Department through a leaked API key for a third-party support platform. One credential, past every dollar of security they'd bought. That's the blast radius of a hardcoded secret.

Why does AI keep hardcoding your secrets?

Because it's fast, it's confident, and it does exactly what the pattern says. Ask an AI assistant to wire up an API call and it'll happily drop the key right into the function. It isn't thinking about your secrets manager. It's completing code.

The data backs it up. Apiiro tracked more than 7,000 developers across 62,000 repositories and found AI-assisted developers ship three to four times more commits. Copilot users generated ten times more security findings, and leaked higher volumes of cloud credentials than the devs writing by hand. More code, more speed, more keys in the open.

Meanwhile everyone's plugging AI into everything, so the keys themselves are multiplying. GitGuardian's 2024 report clocked a 1,212x surge in leaked OpenAI API keys in a single year. Every new integration is one more secret somebody can paste into the wrong file.

Then there's the boring stuff that's been breaking repos since before AI showed up. The .env file that never made it into .gitignore. The config committed “just to test.” No scanner on the way in. AI didn't invent this problem. It just floored the gas.

How do you catch it before it ships?

You put a gate between the keyboard and the repo. Three layers, all cheap, all fast.

Layer one: scan every commit before it lands. Wire a secret scanner into a pre-commit hook so a bad commit dies on the developer's machine, not in production. Gitleaks is built for exactly this. It reads your git repo for passwords, API keys, and tokens, and it drops straight into a pre-commit hook. TruffleHog and GitGuardian's own tooling do the same job. Pick one and turn it on today.

Layer two: scan the whole pipeline. Local hooks get skipped, so back them with a CI check that scans every push and pull request. Turn on GitHub push protection while you're at it. It detects hardcoded secrets and blocks the push before the commit ever hits the codebase. Belt and suspenders. You want both.

Layer three: stop hardcoding secrets, period. GitHub's own guidance is blunt about it. Don't put secrets in code. Use environment variables, or a secret manager like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, and inject them at runtime. Put .env in .gitignore on day one, then commit that .gitignore so the whole team is covered.

Frank doesn't trust a commit. He scans it.

It already shipped. Now what?

Move fast, and do it in the right order, because most people do it backwards.

Rotate first. GitHub's docs say it plain: the very first step is to revoke or rotate the exposed secret. Once the old key is dead, it doesn't matter who has a copy. That's the fix that actually closes the door. Assume the key is burned the moment it touched the repo, especially in a private one. GitGuardian found 35% of private repos hold plaintext secrets, and “private” is not a control. Treat every leaked key as compromised.

Then scrub the history, if the exposure warrants it. Rotating usually solves the real problem, but if the raw secret still needs to come out, GitHub points you at git-filter-repo to rewrite history and purge the file. Fair warning: it's messy. It rewrites commit hashes, breaks everyone's clones, and the key can still live in forks and cached views until you clean those too. That's the whole reason you'd rather catch it at the commit. Cleanup is a bad day. Prevention is a hook.

The operator's takeaway

You don't need a security team to fix this. You need a gate. A scanner in a pre-commit hook, a scanner in CI, push protection on, .env in .gitignore, and real secrets in a vault. That's an afternoon of work that keeps you off the next leaked-key headline.

AI is going to keep writing code faster than any human can read it. That's the deal now. So the review can't be a person squinting at a diff. It has to be automatic, and it has to run before the commit lands. Speed without a gate isn't speed. It's exposure with good marketing.

Scan the commit. Rotate the key. Sleep at night.

Ready to put real guardrails around your AI-built code? Start the brief.