AI commits leak secrets at twice the rate, says the report. The baseline it is twice is not what you think
GitGuardian measured a 3.2 per cent secret leak rate in Claude Code assisted commits against a 1.5 per cent baseline. The baseline is all public GitHub commits, which includes the AI assisted ones.
By Parminder Kumar Sharma · · 7 min read
Two point one three, and what it is two point one three of
The line travelling around this week is that AI written code leaks credentials at twice the rate of human written code. The source is GitGuardian's State of Secrets Sprawl 2026, and the sentence it comes from is precise: "Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits."
Three point two divided by one point five is 2.13, so the arithmetic is right. The comparison is not the one being reported.
The baseline is not human written commits. It is all public GitHub commits, which includes every AI assisted commit in the dataset, including the ones being measured. Comparing a subgroup against a population that contains it does not tell you what the subgroup differs from. It tells you that the subgroup sits above the average, which is a weaker and much less interesting claim.
What the figure does not establish. It does not establish that AI writes worse code, because a commit's leak rate is a property of what got committed, not of who wrote which line. It does not establish causation in either direction. It does not establish anything about AI assisted commits that do not identify themselves, because the measurable population is commits that carry a Claude Code co-author trailer, which requires a tool that adds one and a developer who leaves it in. And it does not establish anything about private repositories, because the dataset is public GitHub.
What it does establish is a real and unsurprising correlation: commits produced with an agent in the loop, by the developers who currently work that way, carry secrets more often than the public average. That is worth knowing. It is not the headline it has become.
Who is in the sample
Think about what it takes for a commit to enter the 3.2 per cent group. Somebody used an agentic coding tool, that tool attributed itself in the commit metadata, and the developer pushed it to a public repository without stripping the attribution.
That is a self selecting group in at least three ways. They are early adopters of agentic tooling. They are working in public. And they are not editing their commit metadata, which correlates with moving fast.
The honest version of the finding is therefore something like: commits that announce they were produced with an agent, by developers currently using agents in public repositories, leak secrets at about twice the rate of the public average. Every clause in that sentence is doing work, and the version in circulation has removed all of them.
None of which makes the underlying concern wrong. An agent that can write files and run commands will happily write a configuration file containing the key it was just given, because that is the shape of the task. The mechanism is plausible. It is just not what this number measures.
The number in the same report that should worry you more
Buried under the AI headline is a finding that needs no caveats at all.
GitGuardian took credentials it had confirmed valid in 2022 and retested them. In January 2025, nearly 70 per cent were still valid. When the same dataset was retested in January 2026, the validity rate was still above 64 per cent.
Those are credentials that were publicly exposed, detected, and in many cases reported, and roughly two thirds of them still worked three and four years later. The report's own summary of this is the sentence that ought to have been the headline: the problem is not detection, it is remediation.
Run that against the leak rate argument and the priority inverts. Whether your leak rate is 1.5 per cent or 3.2 per cent changes how many credentials reach a public repository. Whether you revoke them changes whether that matters.
Figures from the State of Secrets Sprawl 2026 that carry no comparison problem
| Measure | Figure |
|---|---|
| New hardcoded secrets added to public GitHub in 2025 | 28.65 million |
| Year on year change | Up 34 per cent |
| AI service secrets exposed in 2025 | 1,275,105 |
| Year on year change in AI service secrets | Up 81 per cent |
| Leaked DeepSeek API keys cited as an example | 113,000 |
| Credentials valid in 2022 that were still valid in January 2025 | Nearly 70 per cent |
| The same dataset retested in January 2026 | Still above 64 per cent |
What to do about it
The useful response to this report is not a policy about AI tools. It is the same secret management work that was already overdue, aimed at the places where agents make it more likely.
Take this with you
In the order worth doing
- Measure your own rate before you argue about anybody else's. Run secret detection across your repositories and split the results by whether the commit carries agent attribution. Your ratio is the only one that matters.
- Make revocation the metric you report, not detection. Count how many exposed credentials were rotated and how long it took, because on the published evidence that is where the failure is.
- Inventory AI provider keys specifically: who holds them, what they can spend, and whether any are shared. They are the fastest growing category in the report.
- Put secret scanning in the pre-commit path as well as the server side, because an agent writing a configuration file is a local event before it is a push.
- Give agents scoped, short lived credentials from a secret store rather than long lived keys in environment files, so that what leaks expires.
- Treat the developer's own machine as part of the problem: agent tooling reads configuration files and writes new ones, and both are where keys sit.
- When quoting any research, including this briefing, check what the baseline is before repeating a multiple.
The question this leaves
GitGuardian has done the work and published the numbers with the wording intact, which is more than most vendor research manages. The sentence about the baseline is right there. What happened afterwards is what usually happens: a precise comparison became an imprecise one in the retelling, and the imprecise one is more quotable.
It matters because the imprecise version invites the wrong control. If AI tools leak secrets at twice the human rate, the obvious response is a policy about AI tools. If the real finding is that agentic commits from early adopters sit above the public average while two thirds of credentials leaked four years ago still work, the obvious response is rotation, scoping and inventory, none of which have anything to do with which tool wrote the line.
So the question, for the next piece of vendor research that lands on your desk with a multiple in the headline: what is the denominator, and does the thing being measured appear inside it?
Sources
- PrimaryThe State of Secrets Sprawl 2026, used for every figure and for the wording of the comparisonGitGuardianaccessed 2026-09-25
- PrimaryGitHub's own description of secret scanning, used for what platform side detection does and does not coverGitHubaccessed 2026-09-25
