This post is based on GitGuardian’s State of Secrets Sprawl 2026 report, published March 2026.
What’s New This Week
GitGuardian published the full State of Secrets Sprawl 2026 report this week. The headline MCP findings are new – 24,008 unique secrets in MCP-related configuration files is the first time GitGuardian has broken this out as a distinct surface area, which suggests it is now large enough to warrant its own category.
Changelog
| Date | Summary |
|---|---|
| 17 Mar 2026 | Initial publication. |
28.65 million new hardcoded secrets were added to public GitHub in 2025. That is a 34% year-over-year increase and the largest single-year jump GitGuardian has recorded in eight years of tracking this. AI-assisted development is accelerating software creation – and it is accelerating the rate at which credentials get shipped with it.
The two trends are not coincidental. They are mechanically connected.
The scale
Public GitHub commits reached 1.94 billion in 2025, up 43% year-over-year. The active developer base grew 33%. More people are shipping more code faster than at any prior point. That is the context for the secrets numbers – they are not growing because individual developers got sloppier, they are growing because the population of people committing code, and the volume of commits they are producing, expanded dramatically.
AI service secrets specifically reached 1,275,105 – up 81% year-over-year. Eight of the ten fastest-growing secret detectors GitGuardian tracks were tied to AI services. LLM infrastructure (orchestration, RAG, vector storage) leaked at five times the rate of core model providers. The market is moving faster than the tooling that should be securing it.
113,000 leaked DeepSeek API keys is a concrete example of what this looks like in practice. A new provider enters the market, gets adopted quickly, and the credentials for it start appearing in commits before anyone has built the institutional habits to protect them.
The 3.2% finding – what it means and what it doesn’t
Claude Code-assisted commits showed a 3.2% secret-leak rate. The baseline across all public GitHub commits is 1.5%. Double the rate.
The naive read: Claude Code is causing credential leaks. Stop using it.
The correct read is more useful. Developers remain in control of what gets accepted, edited, and pushed. The leak still happens through a human workflow. What AI-assisted development changes is the conditions around that workflow: timelines compress, commit volume increases, less experienced engineers ship production code that previously would have gone through more review. The friction that would normally catch a hardcoded API key before it lands in a commit gets reduced – not by the tool failing, but by the tool succeeding at making development faster.
The distinction matters because it points to the right response. Adding a pre-commit secret scanning hook addresses the problem. Avoiding AI coding tools does not.
This pattern is visible elsewhere in the data. AI does not invent the mistake. It changes the conditions – speed, volume, population of contributors – that determine how often the mistake happens.
MCP configs as a credential dump
24,008 unique secrets were exposed in MCP-related configuration files on public GitHub. Of those, 2,117 were valid credentials – 8.8% of all MCP-related findings still active and exploitable.
The mechanism here is documentation, not ignorance. Popular MCP setup guides recommend putting API keys directly into configuration files, command-line arguments, or embedded connection strings. Developers follow the quickstart. The quickstart is insecure. The problem spreads at ecosystem speed.
This is identical to the npm documentation problem from around 2018, where package readmes routinely showed hardcoded tokens in example code. It took years for the ecosystem to establish “use environment variables” as the default pattern. The MCP ecosystem is at day one of that same curve, except it is spreading across every AI tool integration simultaneously rather than one package at a time.
If you have MCP server configurations in your codebase, audit them now. Search for hardcoded strings in any mcpServers configuration block. If you find them, rotate the credentials and move them to environment variables or a secrets manager before the next commit.
The broader lesson is that new ecosystems arrive with convenience-first examples. Security assumptions that seem obvious inside an established platform do not transfer automatically to a new one.
Internal repos and the private-by-default illusion
Internal repositories are approximately six times more likely than public ones to contain hardcoded secrets.
This is the number most engineering teams are not prepared for, because the intuition runs in the opposite direction. Public repo: high risk, must be clean. Internal repo: private, therefore safer. In practice, the private-by-default assumption makes internal codebases less disciplined, not more. The exposure feels less immediate, so the credential ends up committed and stays there.
The problem compounds because internal repos are where the high-value credentials live – database passwords, internal service accounts, production infrastructure keys. Once an attacker has internal access (via a supply chain compromise, a phishing credential, or a breach of any internal system) the internal repo becomes a credential store for the entire infrastructure.
The glassworm supply chain attacks and similar campaigns targeting developer tooling are specifically designed to get that internal access. Once they have it, the hardcoded secrets do the rest of the work for them.
The correct posture: treat internal repositories with the same security controls as public ones. Pre-commit scanning, rotation policies, no exceptions for “it’s private.”
The 28% outside code – Slack, Jira, urgent debugging
28% of incidents originate entirely outside repositories – in Slack, Jira, and Confluence.
Those leaks are 13 percentage points more likely to be categorised as critical than secrets found only in code.
The mechanism is operational urgency. Someone needs a database password at 2am to debug a production incident. They paste it into Slack because that is the fastest way to get it to the person who needs it. It stays in the Slack channel. It gets attached to the Jira incident ticket. Two years later it is still there, still valid, readable by everyone who has ever had access to those channels.
The credentials being shared urgently tend to be the production ones. That is why the criticality is higher – not because people are being less careful, but because the credentials worth rushing to share are the ones that matter most.
Any credential that has touched a communication tool should be rotated. Not eventually – this week. Slack search and Jira ticket history are persistent credential stores that most security programmes are not monitoring.
Developer workstations as the new attack surface
AI agents with local access change the value of a compromised developer machine.
Before agentic workflows, compromising a developer workstation gave an attacker their commits, maybe some SSH keys, possibly browser-saved passwords. The blast radius was bounded. Now, an agent with local terminal, file system, editor, and environment variable access can read every .env file, scan the credential store, access the shell history, and interact with anything the developer can interact with.
GitGuardian’s analysis of the Shai-Hulud 2 dataset puts empirical weight on this. Across 6,943 compromised machines from that supply chain attack, they found 294,842 secret occurrences – 33,185 unique secrets. And 59% of those machines were CI/CD runners, not personal workstations. The developer laptop is one part of the problem; the build infrastructure connected to it is another.
This connects directly to the developer workstation attack surface pattern and the credential theft chain that runs from compromised local environment to production access. The action layer is where the risk materialises, but the workstation is where the credentials are.
Agentic workflows need least-privilege architecture. An agent that can read your terminal should not have access to your credential store. An MCP server that needs one API key should not be configured in a file that also contains five others.
Six things to do this week
1. Add pre-commit secret scanning. GitGuardian, gitleaks, and trufflehog all work. Pick one, install it, enforce it for everyone on the team. This catches hardcoded credentials before they hit a commit. It is the most effective single intervention in this list.
2. Audit your MCP configurations. Search your codebase and dotfiles for mcpServers configuration blocks. Any API key hardcoded in a config file, command-line argument, or connection string should be moved to an environment variable and the original rotated.
3. Rotate credentials that have touched communication tools. Search Slack for common credential patterns. Review Jira tickets from incident response. Rotate anything you find. Set a policy that credentials shared in comms tools are rotated within 24 hours.
4. Apply the same standards to internal repos. If your internal repositories are not scanned for secrets, they are almost certainly storing them. The data suggests at a higher rate than your public repos. Start scanning them.
5. Review AI-generated service client code. Be sceptical of any AI-generated code that initialises a service client with a literal string rather than an environment variable lookup. This is a pattern that appears frequently in AI-assisted code – the model generates working code that is not production-safe.
6. Audit your CI/CD runner environments. 59% of the machines in the Shai-Hulud 2 dataset were CI/CD runners. What credentials do your build runners have access to? What environment variables are injected into build environments? Treat the build infrastructure as a secrets surface area, not just the output it produces.
The leak surface has grown proportionally with the tooling surface. AI did not create secrets sprawl – it accelerated the conditions that produce it: faster shipping, broader participation, more integrations, more configuration surfaces. The 2026 numbers reflect that acceleration.
The defences are not new. Pre-commit scanning, environment variables over hardcoded credentials, rotation policies, scanning internal repos and communication tools – none of this is exotic. Most teams know they should be doing it. Most teams have not deployed it comprehensively.
The gap between knowing and doing is where the 28.65 million secrets live.