What your AI coding assistant left in your git history

A developer warns that AI coding assistants can leave secrets in git history, as they may commit API keys or other credentials to make code run. The developer recommends scanning full git history before pushing to production and suggests tools like git filter-repo or RepoFortify to remove exposed secrets.

You are building fast. You shipped a real app in a weekend. The AI wrote most of it, you connected it to GitHub, and you pushed. Here is the part that does not show up in the UI: your git history is a permanent timeline. It remembers every version of every file you have ever committed. When the AI wrote your config file on day one, it may have put a real API key in there to make the code run. You moved it to an environment variable later. The current version of your file is clean. The commit from day one is still there, and so is the key. When you push a commit, that commit becomes part of your repository's permanent history. If you later delete the file or rotate the key and push a new commit, the old commit is still there. Anyone who clones the repo gets the full history, including the old commits. Automated scanners comb public GitHub repositories for exactly this pattern. A leaked key from six months ago is still a working key if you did not rotate it. Private repositories are not immune. A compromised account, an accidental visibility change, or a contractor you no longer trust all turn a private history into an exposure. Coding assistants write code that works. They fill in values so the code runs during your session. Those values sometimes land in commits. The AI is not making a security mistake. It is doing what you asked: making things work. The security decision belongs to you, and it has to happen before you push to shared infrastructure. The gap is not a problem with AI tools. It is the gap between "it runs" and "it is safe to ship." That gap has always existed. AI just makes the first part faster, which makes the gap more important to close deliberately. Four patterns come up most often in AI-built repos: .env files committed before being added to .gitignore A rough manual check: git log -p | grep -iE "api key|secret|password|token|sk-|AKIA" . This will catch obvious patterns but misses anything outside those strings. Before you connect an AI-built repo to real infrastructure or make it public: git filter-repo the modern replacement for git filter-branch can rewrite commits to remove the secret at the source.If you want to skip the manual work, RepoFortify https://repofortify.com/get-started?utm source=devto&utm medium=content&utm campaign=git-history-ai scans your full git history for secrets and flags them at the commit level. Free to try. No install required: paste your repo URL and it runs in the browser. The question is not whether AI coding tools introduce security risk. Every tool that speeds up development moves faster than the developer's mental security review. The question is whether you have a check that runs before it matters. A full git history scan takes a few minutes. It belongs before you push to prod, not after your first incident report.