Accidentally committed an API key to GitHub
Symptoms
- A GitHub secret-scanning email or GitGuardian alert names a credential in your repo
- A database URL, AWS key, Stripe secret, or JWT signing key is sitting in a committed file
- Mystery activity follows fast: crypto-mining on AWS keys, drained LLM quotas, unexpected charges
- You deleted the file in a later commit, but scanners keep flagging it because the secret is still in git history
Why it happens
AI assistants write keys inline because their training data does
Quick-start examples hardcode credentials, so assistants reproduce the pattern, and vibe coders commit whatever the agent produced.
AI-assisted commits leak at roughly double the human rate
GitGuardian's State of Secrets Sprawl reports put AI-assisted commits at about a 3.2% secret-leak rate versus about 1.5% for human-only commits, and repositories using Copilot showed a 6.4% leak incidence.
The volume is enormous
28.65 million new hardcoded secrets hit public GitHub in 2025 alone, up 34% year over year.
Removal without rotation is the real crisis
About 70% of secrets confirmed valid in 2022 were still valid years later. People remove the file but never rotate the key, so the leaked key keeps working.
How to fix it
- Rotate first, clean up secondThe moment a secret touches a public commit, treat it as compromised: revoke and reissue it at the provider dashboard right now. Bots that scrape public GitHub exploit fresh keys within minutes, and rewriting history does not un-leak anything already scraped.
- Purge the secret from git historyAfter rotating, optionally clean history with git filter-repo or BFG and force-push. This mainly stops future scanners from re-flagging the dead key; the actual security work was the rotation.
- Move secrets out of the codePut all secrets in environment variables or a secret manager. Commit only a .env.example with placeholder values, and confirm .env is listed in .gitignore.
- Turn on push protection and pre-commit scanningEnable GitHub push protection and add a pre-commit scanner such as gitleaks or GitGuardian's ggshield so the next AI-written key literal is blocked before it leaves your machine.
- Scan AI diffs before committingBefore committing AI-generated changes, scan them for high-entropy string literals. That is exactly where assistants tuck keys.
How to prevent it
- Keep GitHub push protection on for every repo, personal projects included
- Run gitleaks or ggshield as a pre-commit hook so leaks die on your machine
- Store secrets only in environment variables or a secret manager, never inline
- Review AI-generated diffs specifically for high-entropy string literals
- When a leak happens anyway, rotate immediately; never settle for deleting the file
Tools that actually fix this
Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.
A purpose-built secret scanner covering 450+ key types. Its ggshield pre-commit hook blocks a key from ever being pushed, and history scanning finds the ones you already leaked. Free for individuals.
Try GitGuardian →All-in-one appsec (code scanning, dependencies, secret detection, containers) with low-noise output, built for small teams that cannot run five separate tools. One dashboard covers several failure modes.
Try Aikido Security →Frequently asked questions
I accidentally committed an API key to GitHub. What do I do first?
Rotate the key first, before any cleanup. Once a secret touches a public commit it is compromised: bots scrape public GitHub and exploit fresh keys within minutes. Revoke and reissue the credential at the provider, then worry about purging git history with git filter-repo or BFG.
Does deleting the file remove the secret from git history?
No. Deleting a file in a later commit leaves the secret fully readable in the repository's git history, and secret scanners will keep flagging it. Actually removing it takes a history rewrite with git filter-repo or BFG plus a force-push, and even that does not un-leak a key that was already scraped, which is why rotation comes first.
Do AI coding assistants really leak secrets more often?
Yes, measurably. GitGuardian's State of Secrets Sprawl data shows AI-assisted commits leak secrets at roughly twice the rate of human-only commits, about 3.2% versus 1.5%, and repositories using Copilot showed a 6.4% leak incidence. Assistants write keys inline in code because their training data does.
How do I stop secrets from getting committed again?
Turn on GitHub push protection and add a pre-commit scanner such as gitleaks or GitGuardian's ggshield, which block a key literal before it leaves your machine. Keep real secrets in environment variables or a secret manager, commit only a .env.example with placeholders, and confirm .env is in .gitignore.
Sources
- GitGuardian: The State of Secrets Sprawl 2026
- GitGuardian: State of Secrets Sprawl Report 2025
- GitGuardian: Yes, GitHub Copilot can leak secrets
- Help Net Security: GitGuardian ggshield AI hook
Related errors
The AI put your API key in the frontend: OpenAI, Stripe, or Supabase keys visible in the JS bundle
Lovable API key exposed: secrets visible in your client-side code
Replit API key exposed: secrets leaking from a public Repl
Why is my OpenAI API bill so high? No rate limiting on your AI endpoints
The Vibe Oops briefing
One email when something ships to production that should not have. New incidents, new error guides, no filler.