GitGuardian's State of Secrets Sprawl 2026, its fifth edition, covers 2025. The report counts 28,649,024 new secrets detected in public GitHub commits, and The Hacker News summary of it (30 March 2026) puts the year-over-year rise at 34%. Three details bear directly on teams that use AI coding assistants: secrets for AI services grew 81% year over year, commits co-authored by Claude Code leak secrets at about twice the baseline rate across all public commits, and 24,008 unique secrets were found in MCP configuration files.
Treat the numbers as signals and not as a ranking of tools. The co-authored figure counts commits that carry the assistant's co-author mark, so it describes a workflow, not proof that any one product is careless. It does tell you where to look.
What's affected
- AI provider keys. GitGuardian lists 1,275,105 exposed secrets for AI-related services in 2025, up 81%. These keys spend money and can read prompts and files.
- MCP configuration files. 24,008 unique secrets were found in MCP-related config files on public GitHub, and 2,117 of them were verified as valid.
- Assistant-written commits. Commits co-authored by Claude Code leak at roughly 2x the baseline. Any assistant that edits files and commits on your behalf shares the risk pattern.
- Internal repositories. 32.2% of internal repositories contain at least one hardcoded secret, against 5.6% of public ones. Private does not mean clean.
- Slow cleanup. Of secrets confirmed valid in 2022, 64% were still exploitable when retested four years later.
How to check if you're exposed
Start with three searches in your own repositories.
1. MCP and assistant config files committed with tokens.
git ls-files | grep -E '(^|/)(\.mcp\.json|mcp\.json|\.cursor/mcp\.json|\.vscode/mcp\.json|\.claude/settings.*\.json)$'
Open each file and look for literal tokens in env or headers blocks.
2. Commits an assistant helped write.
git log --all -i --grep="co-authored-by: claude" --format=%H > ai-commits.txt
while read c; do
git show "$c" | grep -nE 'AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|sk-[A-Za-z0-9_-]{20,}' && echo "^ in $c"
done < ai-commits.txt
Adjust the grep for your co-author trailer and the key formats you use.
3. Secrets already sitting in files an assistant can read.
git ls-files | grep -E '(^|/)\.env($|\.)|\.pem$|id_rsa|credentials'
Anything that shows up here can be read into an assistant's context and from there into a prompt, a log or a commit.
Then run a proper secret scanner over history, not just the working tree. A key deleted in a later commit is still in history.
What to do now
- Rotate anything you find. Deleting a leaked key from the repository does not revoke it. The 64% retest figure is the reason rotation comes first.
- Move MCP tokens out of config files. Reference environment variables, and keep real values in a secrets manager or a shell profile outside the repo. For example, in a project
.mcp.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}" }
}
}
}
Claude Code expands environment variables in this file. Check your own client's documentation for its syntax.
- Deny the assistant access to secret files. Use your tool's ignore or deny mechanism, for example a permissions deny rule for
.envfiles in Claude Code settings, a.cursorignorefile in Cursor, or content exclusion in GitHub Copilot. - Scan before the commit lands. Run a secrets scan as a pre-commit hook and again in CI, so assistant-written commits are checked the same way as human ones.
- Issue narrow, short-lived credentials for MCP servers and agent runs, each separate from developers' personal tokens.
- Set spend limits and alerts on every AI provider key. A leaked key with no limit is a billing incident as well as a data one.
- Review assistant commits for new files and config changes, not only code.
How this could have been avoided
- Environment references instead of literals in configs. The 24,008 MCP secrets were found in config files on public GitHub. A rule that rejects literal tokens in those files would have stopped them at commit time.
- Pre-commit scanning on every contributor, human or assistant. The elevated leak rate in co-authored commits is the kind of difference a hook removes.
- Least-privilege tokens. A read-only, repo-scoped token turns a leak into a smaller incident.
- Automatic expiry. Short-lived credentials make the 64% statistic irrelevant for your keys.
- Ignore rules for secret files. If the assistant cannot read
.env, it cannot copy it into a commit or a prompt.
Why it matters
AI assistants change who touches secrets. Before, a secret reached a repository through a developer's mistake. Now it can arrive through a file the assistant read, a config example copied from a README, or a commit the developer skimmed. The path is longer, and the volume of commits is higher.
The numbers on internal repositories deserve more attention than they get. Teams often scan public code and relax about private repos. The internal rate is almost six times the public one, which means your highest-density secret stores are the ones with the least scrutiny.
Try it yourself
Run the three searches above on one active repository, and write down how many literal credentials you find in assistant or MCP config files. Then repeat after moving them to environment references.
Click through it at your own pace, or open it full screen.
You can also check your dependency files with the free scan at gold.safeguard.sh/scan. It runs in your browser, with no login, and the file never leaves your machine.
Quick check
Does deleting a leaked key from the repo fix the problem?
No. The key remains in git history and in any clones, and it stays valid until revoked. Rotate it first.
What does the roughly 2x figure for Claude Code co-authored commits tell you?
That commits carrying the assistant's co-author mark leak secrets about twice as often as the baseline across public commits. It indicates a workflow risk worth guarding with hooks, not a verdict on one tool.
