GUIDE · REFERENCE 10 min ·

The state of secrets leakage in 2026What the numbers say. Where the trend goes.

Secrets leakage is getting faster. AI tokens are the fastest-growing category, and the tooling that accelerates development is also accelerating exposure. The numbers are now large enough to stop treating this as edge-case hygiene.

TL;DR· the answer, in twenty seconds

What: GitGuardian's State of Secrets Sprawl 2026 found AI-service token leaks up 81% year-over-year. Commits from AI-assisted workflows leak credentials at roughly twice the rate of baseline commits. The contributing mechanisms are now documented across Knostic, OX Security, and Check Point disclosures from the first weeks of 2026.

Fix: Audit agent state directories (.claude/, .cursor/, .aider/) in every repo. Add them to .gitignore, .npmignore, and .dockerignore. Run git log --all -- '.claude/*' '.cursor/*' per repo and rotate any secrets found.

Lesson: The source of the problem is not any particular tool. It is a runtime model where agents read ambient environment variables, persist them to on-disk state, and that state flows into published artifacts through normal dev pipelines. Changing that model at the architecture level removes the surface for this whole category.

GitGuardian's State of Secrets Sprawl 2026 found AI-service token leaks up 81% year-over-year. That number would be notable even if the overall secrets leakage picture were improving. It is not. Detected secrets in public repositories grew for the fifth consecutive year, and the detection rate improved only because tooling improved, not because teams got cleaner.

The shift in 2026 is that we can name the mechanism. A year ago, "AI coding tools might leak secrets" was a concern without much concrete evidence. By February 2026 there were CVEs, disclosure reports from named researchers, reproducible bug reports, and GitGuardian data showing a 2x lift in credential leakage from AI-assisted commits. The gap between plausible and documented closed inside a single quarter.

Developers adopt AI coding tools faster than security teams instrument them. Each new layer in the stack (agent, MCP server, IDE plugin, CI integration) adds a path for secrets to travel from a developer's shell to somewhere unintended. The leakage curve follows the adoption curve with a short lag.

What to know in 60 seconds

  • GitGuardian's 2026 report found AI-service token leaks up 81% YoY and AI-assisted commits leaking credentials at 2x the baseline rate.
  • Knostic found Claude Code's settings.local.json in roughly 1-in-13 npm packages in February 2026, containing environment variables from dev sessions.
  • Knostic found an equivalent state-file leak in Cursor's .cursor/ directory in late January 2026.
  • OX Security documented about 7,000 MCP servers with approximately 150 million downloads and no signature requirement as of early 2026.
  • Check Point published CVE-2025-59536, a command injection bug in Claude Code project files, in early February 2026. Anthropic patched it in late February.

The headline numbers

GitGuardian's State of Secrets Sprawl 2026 covers the calendar year through late 2025 and is the most widely cited public data source on secrets leakage at scale. The AI-service token category (Anthropic, OpenAI, and similar providers) grew 81% year-over-year. That is faster than any other credential category they track, including cloud provider keys and database URLs. The growth reflects where developers are putting new integrations: AI APIs first, everything else second.

The AI-assisted commit finding matters more operationally. Repos with AI coding tool integrations leak credentials at roughly twice the rate of equivalent repos without them. GitGuardian does not publish the exact methodology for isolating that signal, but the direction matches what the Knostic disclosures explain mechanically: agent tools write state files, state files contain environment data, publishing pipelines ship state files.

The 2x multiplier comes from the tools, not from careless developers. Early adopters of AI coding tools are often the most productive engineers on a team. These tools read a broader slice of the environment than traditional CLI tools do, and they write that context to disk in more places. A state file sitting in a project directory is not a bug. A publishing pipeline picking it up is not a bug either. The two behaviors together produce the incident.

Knostic's February 2026 scan found settings.local.json (Claude Code's per-project state file) in roughly 1-in-13 published npm packages. The file records environment variables from agent sessions. Any key exported in the developer's shell at session time was a candidate for capture. The 1-in-13 figure applies to packages where Claude Code was used; it is not a global npm registry rate.

Knostic had disclosed the same category of problem in Cursor three weeks earlier, in late January 2026. The .cursor/ directory stores IDE state including session context. Cursor's default excludes did not cover the path in all publish scenarios. Two different tools, two different file paths, the same missing .gitignore entry producing the same outcome.

Where the leaks happen

Four surfaces account for most exposures.

Public registries are the most documented. npm publish ships whatever is in the package directory unless you exclude it. PyPI behaves the same (MANIFEST.in controls the sdist). Docker Hub picks up dotfiles and agent directories from any COPY . line. Go module proxies have a narrower impact because Go binaries do not typically ship source directories, but go:embed patterns will pull in anything they match. The 1-in-13 npm finding is the registry surface at its clearest.

Git history is permanent. State files that enter git history persist indefinitely. git filter-repo can remove them from the tree, but the npm tarball for already-published versions is immutable. The registry treats each published version as a permanent artifact. Removing a commit does not retract the tarball.

CI log retention is the quietest surface. Most CI platforms keep job logs for 90 days by default (GitHub Actions, GitLab CI). A debug step that runs cat .claude/settings.local.json or env during an agent workflow puts the contents into the log stream for the full retention window. Anyone with read access to the repo, which includes all contributors and sometimes GitHub Apps, can pull those logs.

Agent state files are the upstream source for all three. Claude Code writes .claude/settings.local.json. Cursor writes into .cursor/. Aider writes .aider.chat.history.md and related files. Each tool has its own schema and retention behavior. None of them appear in the default .gitignore template that npm init, cargo init, or go mod init generates. That missing entry is where the problem starts; the registry, git, and CI surfaces are all downstream from it.

MCP servers add a fifth surface with less visibility than the others. OX Security documented about 7,000 MCP servers with approximately 150 million downloads in early 2026. There is no package-signing requirement for MCP servers, no centralized security advisory system, and no standardized audit format. An MCP server that handles credentials does so on its own terms. npm at least requires 2FA for popular packages and has Sigstore integration in progress. MCP has neither, and no SLSA guidance specific to it. The MCP ecosystem in early 2026 is roughly where npm was around 2014.

Who is shipping the fix

Anthropic acknowledged the settings.local.json environment variable capture issue and patched it in late February 2026. The patch scopes what the file records; environment variables no longer land in the state file by default. The patch covers new sessions only. Files written before the patch still hold whatever they captured.

Cursor did not publish a timeline equivalent to Anthropic's late-February patch communication, but the Knostic disclosure in late January prompted updated default excludes. The update landed in a point release; check the Cursor changelog for your version and confirm your project settings do not override the new defaults.

Aider added .aider* to a recommended .gitignore snippet in its documentation after the Knostic disclosures in February. Aider does not use the same session-state model as Claude Code, but its chat history files can contain inline secrets that users paste into prompts.

MCP has no central governance. The Model Context Protocol specification does not define a security model for credential handling. Individual server authors decide whether to log, cache, or persist the secrets they receive. OX Security's early-2026 report found no signing requirement for MCP packages. A compromised or malicious MCP server is indistinguishable from a legitimate one at install time. There is no MCP equivalent of npm's audit database, no security advisory system, and no disclosure coordination process. The fix has to come from the tooling layer (your IDE or agent host), not from the protocol itself.

Check Point's CVE-2025-59536 (command injection in Claude Code project files, published early February 2026) is a distinct issue from the state-file leak, but it lands in the same place on a risk register: local project configuration as an attack surface. Anthropic patched it in late February alongside the state-file fix.

What changed in 2026 versus 2025

In 2025, the risk from agent-assisted development was theoretical. Researchers at DEF CON and Black Hat walked through plausible prompt-injection scenarios. Security teams read the writeups, filed them under "worth watching," and moved on. Public disclosures of actual credential leaks from agent workflows were sparse enough to treat as edge cases.

In early 2026, the same risk is empirical. Knostic found npm packages with live secrets in a public registry scan. GitGuardian measured a credential exposure lift in AI-assisted repos. The $82K GCP bill from 2024 (an AI agent with unconstrained credential access ran up cloud charges) was an early warning. The 2026 disclosures are systematic, not anecdotal.

Agent adoption is accelerating and the attack surface is growing with it. More developers use more tools more of the time. 7,000 MCP servers in early 2026 will be more by mid-year, each one another path for a credential to leave its intended boundary. Vendor responses lag the growth: Anthropic patched a specific issue in late February, but the runtime model that produced it remains intact across most of the category. Other vendors have not published equivalent patches.

The 2026 incident count will be higher than 2025. That is where the data points.

What the stats undercount

The GitGuardian numbers cover public repositories. Private surfaces are the larger share of the problem.

Private repositories are measurably worse on secrets hygiene than public ones. The perceived blast radius of a private repo leak feels smaller, so developers are less careful. Teams that commit .env files into private repos and rely on "nobody outside the company can see this" are exactly the population where state-file leaks accumulate undetected. They also tend to skip .npmignore hardening because their package is not public, until it is.

Internal CI systems do not feed GitGuardian telemetry. A self-hosted GitLab instance, a Jenkins setup, an internal Buildkite org: the job logs on those systems retain agent workflow output with no external scanner watching. An env dump in a debug step sits in those logs for whatever the retention policy allows. GitGuardian's 81% figure does not count those.

Internal package registries are another gap. Artifactory, Nexus, and GitHub Package Registry private feeds receive the same agent state files that public npm receives, with less scrutiny and often no automated scanning. A developer who would never publish a sensitive package to public npm publishes to the internal registry without a second thought.

Third-party integrations are the hardest gap to measure. When a developer connects an AI coding tool to a GitHub App, a CI integration, a Slack bot, or a project management webhook, each integration receives whatever context the tool hands off. The OAuth scopes and token retention policies of those integrations are rarely audited against the sensitivity of what they can observe. A GitHub App with read access to your repos can read CI logs. A Slack integration that receives agent summaries may log those summaries indefinitely. Most engineering teams have no inventory of what credentials each integration can see.

The public numbers are useful for benchmarking and useless for risk sizing. Treat the GitGuardian figures as a lower bound.

Audit questions for your team

Paste this into a sprint retro or an infrastructure review.

## Secrets leakage audit - agent tooling

- [ ] List every AI coding tool used across engineering (Claude Code, Cursor, Aider, Codex, others)
- [ ] For each tool: identify the state directories it writes to in project repos
- [ ] Confirm all state directories are in the org-wide .gitignore template
- [ ] Confirm all state directories are in .npmignore / MANIFEST.in / .dockerignore / .dockerignore where applicable
- [ ] Run: git log --all -- '.claude/*' '.cursor/*' '.aider*' across critical repos
- [ ] Pull last 5 npm/PyPI published tarballs per internal package and grep for agent paths
- [ ] Review CI job logs for the last 90 days for any env or cat of agent state files
- [ ] List all MCP servers in use; confirm each one's credential handling policy
- [ ] Confirm no long-lived tokens are exported in shared CI environment variables
- [ ] Verify that secrets used by agent workflows are rotated per incident response policy
- [ ] Document which team member owns agent tooling security for each major repo

Run this quarterly. Add each new tool to the list when it lands.

What this means for your stack

Early 2026 disclosures each trace back to the same origin: secrets live in the environment, agents read everything in the environment, and normal dev pipelines carry the result somewhere it does not belong. Patching individual tools reduces the blast radius of a specific incident. Patching the runtime model removes the surface for the whole category.

The runtime model that eliminates this category: secrets sit in one encrypted local store, not in shell exports or .env files spread across projects. Agents request access at the call site and receive a process-scoped injection for a specific command. The value appears inside that child process and disappears when it exits. An append-only audit log records every grant. "Did the agent touch the prod token on Tuesday?" becomes a three-second query instead of an afternoon of log archaeology.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, and the next agent session receives a reference instead of a live key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

81% YoY is what you measure when tooling adoption laps credential infrastructure by two or three years. The gap is still widening.

Sources· cited above, in one place

NEXT STEP~90 seconds

Stop handing the agent your real keys.

hasp keeps secrets in one local encrypted vault, brokers them into the child process at exec, and never lets the agent read the value.

  • Local, encrypted vault — no account, no cloud, no telemetry by default.
  • Brokered run — agent gets a reference, the child process gets the value.
  • Pre-commit + pre-push hooks catch managed values before they ship.
  • Append-only HMAC audit log answers "did the agent touch the prod token?" in seconds.
→ okvault unlocked · binding ./api
→ okgrant once · pid 88421
→ okagent never read

macOS & Linux. Source-available (FCL-1.0, converts to Apache 2.0). No account.

Browse all clusters· eight threads, one index