Secrets Sprawl 2026: 28.65M Leaked Keys and 64% Still Valid Years Later

Every few months I run a secret scanner over something I am sure is clean, and every few months it finds a token. Usually it is mine, usually it is dead, and once in a while it is neither. That small personal ritual is the whole problem of secrets sprawl at a scale of one: credentials copied into places nobody tracks, outliving the reason they were created. The 2026 data says the problem is not shrinking. GitGuardian's latest report counted 28.65 million new secrets pushed to public GitHub in 2025, AI tooling is adding new leak paths faster than old ones close, and most leaked keys are never revoked. This post walks through the current numbers on leaked secrets in public repos, Docker images, MCP config files and AI-assisted commits, what they actually measure, and what I think engineering teams should change.

How many secrets leaked in 2025?

The anchor dataset is GitGuardian's State of Secrets Sprawl 2026, published 17 March 2026. Scanning roughly 1.94 billion public GitHub commits from 2025 (up 43 percent year over year), it found 28.65 million new hardcoded secrets, a 34 percent rise and the largest single-year jump in the report's five editions. The Hacker News summary adds the longer trend: leaked secrets are up 152 percent since 2021, while GitHub's public developer base grew 98 percent over the same period. Leaks are growing faster than the population producing them.

GitHub's own number is in the same range. In its April 2025 post announcing standalone Secret Protection, GitHub said more than 39 million secrets leaked across the platform in 2024, despite push protection being on by default for public repositories. The two figures come from different scopes and methods (GitGuardian counts unique secrets in public commits), so do not add or subtract them.

Public GitHub is also the easy part to measure. The Hacker News summary of the report says internal repositories are about six times more likely to contain a hardcoded secret than public ones: 32.2 percent of internal repos versus 5.6 percent of public repos. About 28 percent of incidents originated entirely outside source code, in tools like Slack, Jira and Confluence, and those were more likely to be rated critical (56.7 percent versus 43.7 percent for code-only incidents). The private, "safe" places are where the worst secrets live, because people paste into them without thinking.

Where secrets leak now: repos, images, chat and CI runners

The leak surface in 2026 is wider than git push. Here is the current evidence, with what each source actually measured.

Source	What was measured	Headline number
GitGuardian 2026	New secrets in public GitHub commits, 2025	28.65M, up 34%
GitGuardian 2026	Secrets for AI services	1,275,105, up 81%
GitGuardian 2026	Unique secrets in MCP-related config files	24,008, of which 2,117 valid
The Hacker News summary	Scanned Docker images containing secrets	18%, and 15% of those valid
Flare, Dec 2025	Docker Hub images uploaded in Nov 2025 leaking secrets	10,456 images, 101 companies
GitHub, Apr 2025	Secrets leaked across GitHub in 2024	more than 39M
Truffle Security, Feb 2025	Live secrets in the Dec 2024 Common Crawl archive	11,908
Wiz, Nov 2025	Forbes AI 50 companies with verified leaks	65%

Container images are the leak path I see underestimated most. A COPY . . in a Dockerfile captures whatever is in the build context, including .env files, and a layer deleted in a later step is still in the image. Flare looked only at images pushed to Docker Hub during November 2025 and found 10,456 exposing at least one secret, with almost 4,000 of the high and critical findings being AI model keys. Flare also reports that developers who noticed often removed the secret from the image within a day or two but did not revoke the credential. Deleting a leaked key from the latest tag is cosmetic: the old layers and every pull that already happened still have it.

The other surface that grew teeth in 2025 is the build machine. GitGuardian analysed the data the Shai-Hulud 2 npm worm exfiltrated: 6,943 compromised systems, 294,842 secret occurrences and 33,185 unique secrets, with each live secret appearing in about eight places on average. 59 percent of the compromised machines were CI/CD runners, not laptops. A CI runner holds deploy keys, registry tokens and cloud credentials by design, so a malicious dependency that runs during npm install gets all of them. I wrote about that worm family in The Worms Learned to Use Your AI Agent.

Do AI coding assistants leak more secrets?

This is the question everyone searches, and the honest answer is "the one published measurement says yes, with caveats". GitGuardian reports that commits assisted by Claude Code had a 3.2 percent secret-leak rate against a 1.5 percent baseline across all public commits. The report does not explain in the public summary how it attributed commits to the tool, and it explicitly says the gap should not be read as a simple tool failure, because a human still decides what gets accepted, edited and pushed. I would add a selection effect: people who let an agent commit for them are probably moving faster on prototypes, which is exactly where .env files and test keys get committed.

The mechanism does not need a study, though. Agents read your environment to be helpful. They open .env to debug a connection, paste the key into a test file to make it pass, echo a token into a log while troubleshooting, and then commit with the same enthusiasm. None of this is new behaviour. What changed is volume: GitGuardian counted 1,275,105 leaked AI-service secrets in 2025, up 81 percent, and eight of the ten fastest-growing detector categories were AI-related. Brave Search, Firecrawl and Supabase key leaks rose 1,255, 796 and 992 percent respectively. Those are the APIs agent builders wire together, and the keys are frequently long-lived, broadly scoped and billed per call, which makes them worth stealing.

AI also feeds old leaks back into the loop. Truffle Security scanned 400 TB of the December 2024 Common Crawl archive, a common LLM training source, and found 11,908 secrets that still authenticated, across 219 secret types, with 63 percent repeated across multiple pages. Wiz found that 65 percent of the Forbes AI 50 companies it examined had verified secret leaks on GitHub, often in deleted forks, gists and contributors' personal repos rather than the main organisation.

MCP config files are the new .env

The Model Context Protocol made it trivial to give an agent tools, and the standard way to configure a tool is a JSON file with a command, some arguments and an env block. People put API keys directly in that block, then commit the file so teammates get the same setup. GitGuardian found 24,008 unique secrets in MCP-related config files on public GitHub, 2,117 of them confirmed valid. I covered the protocol side of this in MCP Security in 2026; the config-file leak is the boring, high-volume half of the story.

The fix is unglamorous and already supported. Claude Code's MCP documentation recommends checking a project-scoped .mcp.json into version control, and it supports ${VAR} and ${VAR:-default} expansion in command, args, env, url and headers precisely so the file never holds the value. A safe pattern, plus the checks I run before anything ships, looks like this:

# 1. Commit references, never values. .mcp.json (checked in):
cat > .mcp.json <<'EOF'
{
  "mcpServers": {
    "search": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${SEARCH_MCP_TOKEN}" }
    }
  }
}
EOF

# 2. Keep real values out of the repo and out of the build context.
printf '.env\n.env.*\n*.pem\n' >> .gitignore
printf '.env\n.env.*\n.git\n' >> .dockerignore

# 3. Block secrets at commit time (gitleaks v8.30.1, via pre-commit).
cat > .pre-commit-config.yaml <<'EOF'
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks
EOF
pre-commit install

# 4. Scan the image you are about to push, every layer included
#    (trufflehog v3.99.3; only report credentials that still authenticate).
trufflehog docker --image docker://myorg/api:1.4.2 --results=verified --fail

The --fail flag makes TruffleHog exit non-zero on findings, so step 4 can sit in CI as a gate. If you want the full setup for the commit-time half, the gitleaks pre-commit guide walks through it.

Why leaked secrets stay valid for years

Here is the number in the report I find most damning. GitGuardian retested secrets it had confirmed valid in 2022: nearly 70 percent were still valid in January 2025, and in January 2026 the rate was still above 64 percent. Four years after a credential leaked publicly, roughly two out of three still work.

Why does nobody revoke? Because revocation is an operations problem, not a security one. To rotate a key safely you need to know every place that uses it, have a way to deploy the new value everywhere at once, and be confident nothing breaks. Shai-Hulud's victims averaged eight locations per live secret. If the key is in three repos, a CI variable, two Kubernetes Secrets, a teammate's laptop and an MCP config, rotation is a cross-team project, and the path of least resistance is to delete the commit and hope. Verizon's 2025 DBIR, as summarised by GitGuardian, put the median time to remediate a secret leaked to a GitHub repository at 94 days. That is three months of open window for a credential that automated scrapers are looking for continuously.

Scanning tells you a leak happened; it does not make the key stop working. The teams that recover quickly are the ones whose secrets come from a central store with a known list of consumers and an automated delivery path, so rotation is a change to one value rather than an archaeology dig. That is a platform engineering problem dressed up as a security finding.

Secrets sprawl is a non-human identity problem

Almost every secret in these reports belongs to a machine: a service, a pipeline, a bot, an agent. Static API keys are the oldest form of non-human identity, and the 2026 shift is that agents multiply them. Every tool an agent can call wants its own key, every developer wiring up an agent creates more, and each one has no owner field, no expiry and no audit trail beyond "someone pasted it here". GitGuardian frames the governance gap as three questions with no good answers in most organisations: which non-human identities exist, who owns them, and what can they access. I went through the identity standards and the breaches in detail in Non-Human Identity in 2026.

The structural fix is to need fewer static secrets at all. Workload identity federation (GitHub Actions OIDC to AWS, GCP and Azure; Kubernetes service account tokens exchanged for cloud roles; SPIFFE where you need it) replaces a stored key with a short-lived token minted on demand. Where a static secret is unavoidable, it should live in one store and be delivered to workloads by a controller, not copied by hand. Even Verizon's 2026 DBIR, which saw exploitation overtake credential abuse as an initial access vector (31 percent versus 13 percent, per GitGuardian's write-up), still found credential abuse somewhere in 39 percent of breaches.

For Kubernetes specifically, the sibling to this post, How to Manage Kubernetes Secrets with External Secrets Operator and Vault, shows the pattern end to end: one store, a controller that syncs on a refresh interval, and rotation that is a single write. For disclosure, I run PandaStack, a Firecracker microVM cloud for agent code execution, and the reason I care about this is that every sandbox an agent gets is another place a credential can be copied into; I would rather inject short-lived tokens at runtime than bake keys into images.

FAQ

What is secrets sprawl?

Secrets sprawl is the uncontrolled spread of credentials such as API keys, tokens, passwords and certificates across code, config files, container images, CI systems, chat tools and laptops. Each copy is a place the secret can leak from and a place you must update when you rotate it. The risk grows with the number of copies, not the number of secrets.

How long do leaked secrets stay valid?

Much longer than people assume. GitGuardian found that more than 64 percent of secrets confirmed valid in 2022 still worked in January 2026. Verizon's 2025 DBIR put the median time to remediate a secret leaked to GitHub at 94 days. Treat any leaked credential as compromised and revoke it, even if you have already deleted the commit.

Is deleting a secret from Git history enough?

No. Forks, clones, CI caches, Docker layers and scrapers may already have it. The only real fix is revoking or rotating the credential at the provider, then cleaning history as a secondary step to stop future scanners flagging it.

How do I stop AI coding agents from leaking keys?

Keep secrets out of the files the agent can read and commit: use environment variable references in .mcp.json and app config, list .env files in .gitignore and .dockerignore, and run a secret scanner as a pre-commit hook and a CI gate. Prefer short-lived credentials from a secrets manager or workload identity, so a leaked value expires on its own.

This quarter, if I were starting from a typical team, I would do three things in order. First, turn on push protection and a pre-commit scanner everywhere, including the repos that hold agent configs. Second, inventory the long-lived keys for AI services, because those grew 81 percent in a year and many have no owner; assign each one an owner and an expiry, and revoke the ones nobody claims. Third, pick the two or three most-copied secrets in the estate and move them behind a store and a sync controller so the next rotation is boring. None of this is new, which is rather the point: the AI era made the old discipline more valuable, not less.

Related: Non-Human Identity in 2026, From the RFCs to the Breaches, The Worms Learned to Use Your AI Agent: A Year of npm Supply-Chain Attacks and MCP Security in 2026: The Protocol Got Hardened. The Ecosystem Didn't.