GitGuardian: leaked secrets in public GitHub commits up 34%, AI-assisted commits leak at twice the rate

Leaked secrets in public GitHub commits rose 34% in 2025

GitGuardian's State of Secrets Sprawl 2026 report identified 28,649,024 new secrets in public GitHub commits over the course of 2025, a 34% year-over-year increase. The figures, surfaced in a dev.to write-up, describe a hygiene problem that is scaling alongside the volume of code being committed — by humans and, increasingly, by agents.

AI-assisted commits leak at more than twice the average

The report's sharpest finding, broken down in SC Media's coverage and referenced by dev.to, concerns who wrote the commit. Commits co-authored by Claude Code leaked secrets in 3.2% of cases, against 1.5% for public commits overall — more than double the baseline rate.

The mechanism is not mysterious. An agent asked to write or update a config file will inline whatever real token it can see in the developer's environment, shell history or conversation. What is convenient for automation is equally convenient for anyone scanning public repositories for live credentials.

MCP configs are a leak vector of their own

GitGuardian also scanned MCP configuration files — the server definitions used by coding assistants and other agent tooling — and found 24,008 unique secrets in them across public GitHub. Of those, 2,117 were verified as still valid: live keys sitting in files few people think of as secret-bearing.

Leaked secrets rarely die

The report adds a sobering persistence figure: of the valid secrets GitGuardian first detected in 2022, 64% were still active four years later. Pushing a credential to a public repository behaves less like a reversible mistake and more like publication.

Catch secrets before the commit exists

The dev.to post's remedy is a gitleaks pre-commit hook, which the author estimates takes about ten minutes to set up. There are three installation routes: a repo entry in .pre-commit-config.yaml for teams using the pre-commit framework, a line in .husky/pre-commit for husky users, or a plain .git/hooks/pre-commit script for repos with no tooling — the last being per-developer and uncommitted, which is why dev.to prefers the first two.

The scanning command is the same in each case: gitleaks git --pre-commit --redact --staged --verbose. The --staged flag limits the scan to the diff you are about to commit, keeping it fast on large repositories, while --redact keeps matched secrets out of terminal scrollback. Older guides reference gitleaks protect --staged; that subcommand was deprecated in v8.19.0 and is now hidden from help.

dev.to recommends verifying the hook with a fake AWS-style key before trusting it, and handling false positives either with a gitleaks:allow comment on the offending line or by fingerprinting the finding into a .gitleaksignore file.

Keep secret-bearing files out of git entirely

Hooks scan content; .gitignore keeps whole files out. dev.to suggests ignoring .env and its variants while committing an .env.example with variable names and dummy values, and treating agent configuration the same way: .mcp.json and the directories where editors and assistants store server definitions frequently embed API keys inline, and those files are precisely the source of GitGuardian's 24,008 MCP findings. Where a config has to be shared, reference environment variables rather than literal tokens — after confirming the tool actually supports that.

Run the same scan in CI

Local hooks have two weaknesses: a fresh clone ships without one, and git commit --no-verify skips whatever is installed. dev.to therefore runs gitleaks again on every push and pull request via gitleaks-action@v3 with a full-history checkout, using fetch-depth: 0. Organisation-owned repositories need a free gitleaks license key; personal repositories do not. Staying on v3 matters — v2 runs on Node 20, which GitHub-hosted runners dropped in September 2026.

When a secret slips through anyway

dev.to's guidance is to rotate first: revoke the credential at its provider, issue a replacement and deploy it before touching git history, since forks, clones and caches preserve public commits regardless of rewriting. Only then investigate what the exposed key actually did, using the provider's audit log — and, for keys that call your own API, per-request logging that records the caller's identity.

Why it matters

The 34% jump would be worrying on its own, but the authorship split is the real signal: the fastest-growing source of commits — AI-assisted ones — also leaks at more than twice the average rate, and the MCP files those assistants generate have become a credential store in their own right, with thousands of still-valid keys exposed. The countermeasures are cheap and well understood: staged scanning before commit, gitignore discipline, enforcement in CI, and rotation the moment something escapes. The report's persistence figure — nearly two-thirds of the secrets detected in 2022 still live four years on — shows the cost of treating those steps as optional.