AI Coding Agents Are Leaking API Keys to GitHub. Is Yours One of Them?

Most of us were taught one rule early: never commit a password. AI coding agents did not get that lesson. In early November, a security firm scanned public GitHub and found thousands of real secrets that were not written by a careless developer, but saved by the agent working next to them.

I build backends and payment systems for a living, and I recently released an open-source tool for managing secrets. So this story hit close to home. Here is what happened, how to check your own repos, and what I think it says about working with agents.

What the research found

On November 5, 2026, the security company Apiiro published research on Claude Code, one of the most popular coding agents. When the agent asks for permission to run a command, you can answer “Yes, and don’t ask again”. The agent then saves that command, word for word, in a project file called .claude/settings.local.json.

The problem is what those commands contain. If you once let the agent run something like psql postgres://admin:S3cret@db... or a curl with an API token in the header, that password is now sitting in a plain text file inside your project. Many people then commit the whole folder.

According to coverage in Dark Reading and other outlets:

• Apiiro scanned 104,185 public settings.local.json files between November 1 and 3.
• 1,122 of them, about 1.1%, contained at least one real secret, 1,379 distinct secrets in total.
• Counting git history, the shared .claude/settings.json and saved agent transcripts, the total rose to 2,539 secrets in 1,994 public repositories: database passwords, cloud keys, API tokens and even SSH logins.

Apiiro did not test whether those secrets still work. But a secret that has been public on GitHub, even for an hour, should be treated as stolen. Bots scan new commits for keys within minutes.

This is not only a Claude Code problem

It is easy to blame one tool. I think that misses the point. Every agent that can run commands has to remember something: approvals, history, transcripts, caches. Every one of those files is a place a secret can land. Separate research this year showed agents in CI pipelines being tricked by prompt injection into posting the API keys from their own environment into a public pull request comment.

The real change is this: your project folder now has a second author that does not know what a secret is. It copies whatever it sees into whatever file helps it work. Our old habits, a .gitignore and a good memory, were designed for one author.

Check your repos in five minutes

If you use any coding agent, do this today.

1. Search for agent files in your repositories and their history:

git log --all --oneline -- .claude/settings.local.json .claude/settings.json
git grep -n -E "(password|passwd|token|secret|api[_-]?key)" $(git rev-list --all) -- .claude/ 2>/dev/null | head

On GitHub you can also search your account with path:.claude/settings.local.json user:YOUR_NAME.

2. If anything shows up, rotate first. Change the password or revoke the key before you clean up the repo. Removing the file does not remove it from history, forks or the copies bots already made.

3. Stop tracking the file and ignore it for good:

git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore

4. Turn on secret scanning. GitHub push protection blocks many known key formats before they reach the server. Tools like gitleaks can run as a pre-commit hook on your machine.

How I keep secrets away from agents

Cleaning up is the reactive part. The better fix is to make sure there is nothing worth leaking in the first place.

• Never type a secret into a command an agent can see. Read it from an environment variable or a file instead: psql "$DATABASE_URL", not the full URL. The approval then saves a variable name, not a password.
• Give agents their own, limited keys. A test database user with no production access. A payment key in test mode. If it leaks, it is boring.
• Keep real secrets encrypted at rest. This is the reason I built goraz, a small open-source tool that keeps API tokens and passwords in an encrypted file instead of a plain .env. An agent that reads the project folder sees ciphertext, not keys.
• Review what the agent commits, not only what it codes. A diff that touches a config or dotfile deserves a second look.

My take

I use coding agents every day, and I am not going back. They are genuinely faster for a large part of my work. But this incident is a good reminder that speed shifts risk somewhere else. Agents are very good at doing what we ask and very bad at knowing what we did not mean to share.

The developers who will do well with these tools are not the ones who trust them most, but the ones who design their setup so that a mistake by the agent is cheap. Secrets are the first place to start.

If you have built something quickly with AI and want a second pair of eyes on its security before launch, send me the details. You can also read why AI-built apps often break in production.