Home / Errors / Vibe coding (any tool) / secrets-committed-to-github

Accidentally committed an API key to GitHub

Vibe coding (any tool) Moderate 30-90 minutes security critical Last verified Jul 17, 2026
The fix  Rotate first, clean up second: the moment a secret hits a public commit, revoke and reissue it at the provider. Bots scrape fresh keys within minutes, and deleting the file later does not remove it from git history. After rotating, purge history with git filter-repo or BFG, move secrets to environment variables, and turn on GitHub push protection.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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

Related errors

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.