What to Do If an AI Coding Agent Leaks a Secret

An AI coding agent just committed an API key, a database password, or a token into your repository. Stop reading tips and do the first thing right now: rotate the credential. Not clean the git history. Not check who saw it. Rotate it first, because the moment a secret hits a commit, even a local one, treat it as compromised. History rewrites and access audits matter, but they come after the leaked key is already dead. Here's the order to work through, and why each step happens when it does.

The triage-priority checklist

Work down this list in order. Do not skip ahead to the git surgery before step 1 is done.

1. Rotate or revoke the credential. Generate a new key at the provider, invalidate the old one, and update every place that uses it: deploy configs, CI secrets, teammates' local env files.

2. Confirm the old credential is dead. Test that the revoked key no longer authenticates. Don't assume the dashboard click worked.

3. Check exposure blast radius. Was the repo pushed? Public or private? Who has clone access? Check provider-side access logs, if available, for use from an unfamiliar IP.

4. Contain the commit. If it hasn't been pushed, fix it locally before it leaves your machine. If it has, treat the remote copy and any forks or CI caches as exposed too.

5. Clean the git history. Remove the secret from every commit that contains it, not just the latest one, using a history-rewriting tool (see below).

6. Force-push and coordinate. Rewriting history changes commit hashes downstream. Anyone with a local clone needs to re-sync, and shared branches need a heads-up first.

7. Verify and lock the door. Confirm the secret is gone from history, move it into .gitignore or a secrets manager, and add a scanner so this doesn't happen again.

Why rotation comes before cleanup

Cleaning git history feels like the more thorough fix, so it's tempting to start there. But a leaked credential is dangerous because of what it can access, not where it sits in a commit log. Rewriting history takes time, and during that window the original secret is still valid everywhere it appears: cached forks, CI logs, local clones on other machines, search indexes if the repo is public. Rotating first shrinks the actual risk to zero almost immediately. Everything after that is cleanup, not damage control.

That's the core difference between a prevention question and a remediation one. If you're asking whether an AI coding agent can leak your API keys in the first place, that's about risk before the fact. This is a runbook for after the fact: the secret is already in a commit, and the priority is getting to a safe state fast.

Finding every commit that has the secret

Before you can clean history, know exactly which commits contain the credential. A single git blame on the file you noticed isn't enough, since an agent might have committed the same key more than once, in more than one file.

Search the full history for the literal string, not just the current working tree:

git log --all -p -S "the-leaked-key-fragment" -- .

# or search commit contents more broadly
git grep "the-leaked-key-fragment" $(git rev-list --all)

The -S flag (the "pickaxe") finds commits where a given string was added or removed, more reliable than a plain text search once the file has changed. Run it against a distinctive fragment of the key, in case it was partially redacted somewhere along the way.

Rewriting history to remove the secret

Once you know which commits are affected, you need a tool built for rewriting history at scale. Deleting the line in a new commit does nothing: the secret stays readable in every prior commit's diff. Two commonly used approaches:

• git filter-repo is the current recommended tool for rewriting git history, including stripping specific files or content from every commit. It's faster and safer than the older filter-branch command, which git's own documentation now advises against for this.

• BFG Repo-Cleaner is a purpose-built tool for this scenario: stripping secrets and large files from history with a simpler command surface, at the cost of a bit less flexibility.

Either tool rewrites commit hashes for every affected commit onward. That's expected and unavoidable when you're removing content from the past, not just the present.

The force-push problem on shared repos

Once history is rewritten, you push the new history over the old one, which requires a force push. On a solo project this is low-risk. On a shared repo, it's the step most likely to cause collateral damage if you skip the coordination:

• Everyone's local clone goes stale. Old commit hashes no longer exist on the remote. Teammates need to re-clone or hard-reset to the new history, not just pull.

• Open pull requests can break. A PR built on the old history may show unexpected diffs once the base branch is rewritten underneath it.

• CI and deploy hooks may need a manual re-trigger. Some systems cache commit references and won't pick up a forced rewrite cleanly.

• Protected branches often block force-push by default. Lift branch protection deliberately, push, then restore it, so it doesn't stay open by accident.

Tell everyone with repo access before you force-push, not after. A short message with the timing and "re-clone, don't pull" saves an afternoon of confused merge conflicts.

What to check downstream

History cleanup only covers the git repository itself. Check anywhere the commit might have been mirrored or cached: CI/CD build logs (many print environment output or diffs into logs that persist independently of git), any bot or integration that mirrors the repo, and search or code-indexing caches if the repo was ever public. If it was public even briefly, assume the secret was seen and treat rotation, not history cleanup, as the real fix.

Locking the door after

The fix that prevents a repeat isn't a smarter agent prompt, it's structural: environment variables loaded outside the repo, a secrets manager, and a .gitignore entry for any local config file that might hold one. Add a pre-commit hook or CI-side secret scanner (GitHub's own secret scanning is a common, free option) so a committed secret gets flagged before it reaches a shared branch.

If you're setting up an agent workflow from scratch, it's worth reading through how to use git safely with an AI coding agent so this becomes a guardrail rather than a recovery step. And if the same incident also involved an unwanted code change beyond just the secret, rolling back a bad AI coding agent change covers the broader revert process.

For the wider pattern of what to do when an AI tool exposes something it shouldn't, the AI safety and risk hub covers related incident types beyond just git and secrets.

FAQ

Do I still need to rotate the key if I catch it before pushing?

Yes, if there's any chance it left your machine, through a background sync, a snapshot backup, or another local tool that read the file. If you're certain it never left the local repo, rotation urgency drops, but cleaning the local commit before it goes anywhere is still the right move.

Does deleting the file in a new commit remove the secret?

No. A new commit that deletes a line only changes the latest snapshot. The secret is still readable in the diff of the earlier commit that added it, and anyone can check out that commit directly. You need history rewriting, not a follow-up commit.

Will git filter-repo or BFG break my repo?

They rewrite commit hashes for every commit after the change, which is expected and required. Keep a backup clone before you start, follow the tool's documented workflow, and test the rewritten repo before force-pushing to the shared remote.

What if the repo is private, does that lower the risk?

It lowers exposure but doesn't eliminate it. Former collaborators, CI systems, and integrations connected to the repo could have read or cached the secret. Rotate regardless of whether the repo was public or private.

How do I stop an AI coding agent from doing this again?

Keep credentials out of files the agent can see or write to: environment variables injected at runtime rather than files in the repo, plus a .gitignore entry for the relevant paths. Pair that with a pre-commit or CI secret scanner so a slip gets caught automatically.