AI coding agents can and do commit real credentials into repositories. The fix is not better prompting — it is a fail-closed secret scan at the moment code is committed and pushed. We learned this the hard way on our own AI development platform, and this post explains the gap we found and how we are closing it.
Why Do AI Coding Agents Leak Secrets?
AI coding agents leak secrets because they operate with real credentials in their environment and commit code autonomously, often faster than any human review can keep up. An agent that needs to call an API during development can read a key from an environment file, then helpfully hard-code that value into a config file, a test fixture, or a debugging script. Unlike a human developer, the agent doesn’t feel the flash of doubt before typing a live token into source code. The risk compounds in autonomous pipelines: when an agent generates code, commits it, and pushes it to a remote repository without a person in the loop, a single leaked credential travels from local mistake to public exposure in seconds. Secret scanning for AI-generated code therefore has to be structural — a mandatory gate in the pipeline itself — not a habit you hope the model has picked up from its training data.
Prompting helps. Every serious platform tells its models never to include secrets, and ours is no exception. But a rule in a prompt is a suggestion, not a control. The difference matters most on the day the model ignores it.
Our Wake-Up Call: The Key That Got Pushed
We run an AI development platform that plans, writes, commits, and ships code with minimal human intervention, and one of its automated commits once pushed a live internal API key to a repository. The key was rotated within the hour and nothing was compromised, but the post-mortem stung, because we already had a secret scanner. A good one — deterministic, blocking, and careful to redact whatever it found so the secret never echoed into logs. The scanner simply wasn’t standing where the incident happened. It ran inside an optional quality-analysis stage, and the code path that leaked the key never entered that stage. Every safeguard we thought we had was real. It just wasn’t in the way. That distinction — between having a control and having it at the chokepoint — became the lens for everything we changed afterwards.
Rotate first, investigate second. That part of our response we would repeat exactly. The part we wouldn’t repeat is assuming that “we scan for secrets” and “no secret can reach the remote” are the same claim.
Fail-Open vs. Fail-Closed: Where Security Checks Belong
A fail-open control runs when conditions are right and quietly steps aside when they aren’t; a fail-closed control blocks the action unless the check has run and passed. Our secret scanner was fail-open in three distinct ways. It only ran when the pipeline’s mode and the task’s complexity qualified for the optional analysis stage. It was skipped entirely on fast-path bug fixes that push directly. And even when it did run, it ran after the commit already existed, on the theory that rewinding a valid commit was riskier than flagging it. Each decision was locally reasonable. Together they meant an entire class of changes could be committed and pushed with zero secret scanning. The lesson generalizes to any AI pipeline: enumerate the paths code can take to your remote, and make the security check a precondition of the chokepoint they all share.
Here is our honest opinion: for autonomous pipelines, post-commit scanning is closer to security theater than to security. A human team can afford to scan after the fact because a human might pause before pushing. An agent won’t. By the time an after-the-fact scanner speaks up, the secret is in history — and git history is famously reluctant to forget.
What a 228,000-Star Repo Taught Us — and What It Didn’t
The push to fix this came from an unexpected direction: our routine review of trending open-source projects. We regularly evaluate popular AI-engineering repositories against our own platform, and a 228,000-star agent-harness project recently came through that queue carrying twelve ideas worth examining. We refuted eleven of them — not because they were bad, but because our platform already covered them, sometimes in richer form: learning decay, per-task isolated workspaces, dynamic model routing, multi-agent audits. One idea survived every counter-argument we threw at it: a fail-closed secret gate at the commit boundary, run unconditionally, no matter which path produced the code. That ratio — one adoption out of twelve — is the point. Chasing every trending technique churns your architecture into mush; refusing everything ossifies it. The discipline is adversarial review: try to refute each idea against what you already run, and adopt only what survives.
So that is what we’re doing now: moving our existing scanner from the optional stage to the commit chokepoint itself, as a blocking precondition. Same detector, new position. The work is in progress as I write this, which feels like the honest thing to say — a security post that claims everything is already perfect is usually describing the gap it hasn’t found yet.
How to Audit Your Own AI Pipeline for Secret Leaks
Auditing an AI pipeline for secret-leak exposure starts with one question: can any path commit or push code without a secret scan standing in the way? Not “do we have a scanner” — most mature teams have one — but whether every route to the remote passes through it unconditionally. In our experience the dangerous paths are the exceptions: the fast lane for urgent fixes, the low-complexity tier that skips heavyweight analysis, the retry path that resumes after a failure. Those exceptions exist for good reasons, usually speed. But an AI agent doesn’t distinguish between an ordinary change and an urgent one when it decides to hard-code a credential, so the gate cannot distinguish either.
- Map every code path that ends in a commit or push — including bug-fix fast lanes, retries, and resume-after-failure flows.
- Check whether the secret scan is a precondition of those operations or a step inside an optional stage. Optional means fail-open.
- Make the gate fail-closed: if the scanner errors out or times out, the commit fails. Inconvenient beats compromised.
- Scan before the commit exists. Pre-commit, a finding is a blocked write; post-push, it is a mandatory credential rotation.
- Redact findings in logs and reports — a scanner that prints the secret it caught has just created a second leak.
- Rehearse the failure: when a leak does land, rotate the credential first and reconstruct the timeline second.
Standard tools like gitleaks, trufflehog, or detect-secrets will do the detecting. The placement is on you.
FAQ
Can AI coding agents really commit secrets to a repository?
Yes. Agents run with real credentials in their environment and write code autonomously, and sooner or later one will inline a working key into configuration or test code. It happened in our own pipeline despite explicit rules against it. Treat it as a when, not an if, and put a blocking scan at the commit boundary.
What does “fail-closed” mean in secret scanning?
Fail-closed means the commit or push is blocked unless the secret scan has actually run and passed. If the scanner crashes, times out, or the stage hosting it is skipped, the operation fails instead of proceeding unscanned. Fail-open is the reverse: the check runs when convenient and steps aside when it can’t.
Is post-commit secret scanning good enough?
It beats nothing, but for autonomous pipelines it fires too late. Once a secret enters git history, removal means rewriting history; once the commit is pushed, you must assume compromise and rotate the credential. Scanning before the commit exists avoids both problems, which is why we’re repositioning our own scanner there.
Which secret scanning tools work for AI-generated code?
The same ones that work for human-written code: gitleaks, trufflehog, detect-secrets, and GitHub’s built-in secret scanning with push protection. The tooling is not the hard part. What matters in an AI pipeline is placement — wire the scan into the commit chokepoint your agent actually uses, so no generation path can route around it.
