Secrets Sprawl Is Now an Identity Problem — and AI Coding Agents Are Making It Worse

AI-assisted commits are leaking credentials at roughly twice the rate of human-written ones, new data shows. The fix isn't better scanning — it's treating every AI agent as an identity that needs its own scoped, short-lived access.

AI coding agents are changing how fast software gets written — and how fast credentials leak while it's being written. According to GitGuardian's 2026 State of Secrets Sprawl report, commits identified as AI-assisted, specifically those co-authored by Claude Code, showed a secret leak rate of roughly 3.2%, compared with a 1.5% baseline across all public GitHub commits — close to double [1]. The same report recorded 28.65 million new hardcoded secrets added to public GitHub in 2025, a 34% jump over the prior year, with credentials tied to AI services growing 81% year over year, faster than any other leaked-secret category [1].

None of this is a new class of vulnerability. Developers have hardcoded API keys and pasted tokens into config files for as long as there's been version control. What's different is the pace and reach. A coding agent can read an entire repository, edit files, call external APIs, and talk to Model Context Protocol (MCP) servers in roughly the time it takes a human reviewer to get through one pull request. Every one of those capabilities is a place a credential can be touched — and a path it can spread through.

Why this is an identity problem, not a model-behavior problem

It's tempting to frame this as an AI safety issue: get the model to behave better around secrets, and the problem goes away. That framing misses the actual mechanism. When an agent queries a database, calls an API, or pushes to staging, some credential is authorizing that action — the same as it would for a script or a human operator. Organizations can't fully predict what an autonomous agent will do next, but they can control what identity is standing behind it and what that identity is allowed to reach. That's an access-governance question, not a model-tuning one.

A Keeper Security survey of 109 cybersecurity professionals at RSA Conference 2026 puts a number on the gap: 46% of respondents said AI-powered tools already have access to critical systems and sensitive data, while 76% said those identities aren't consistently governed under privileged access policies [2]. In other words, the access is being granted well ahead of the governance that's supposed to go with it.

Four ways coding agents end up touching secrets they shouldn't

Project files hold leftover credentials. Developers routinely keep .env files and local config with real API keys, often left over from a debugging session and never meant for source control. An agent asked to review or refactor a project doesn't distinguish "code you asked about" from "config file that happens to sit next to it" — unless access is explicitly scoped, a production key sitting in a config file becomes part of what the agent can read.

Agent and MCP setup steps normalize plaintext keys. Connecting an AI coding tool to a database or external API usually means authenticating somehow, and the path of least resistance is pasting the credential straight into a config file. Because that file never touches version control, it's easy to assume it's safe — but it can still sit in plaintext on a developer machine, in a location the agent has permission to read.

The same secret lives in more places than repo scanners check. A key doesn't usually stay in one file. It ends up in an .env, a CI/CD variable, and a Jira ticket from the time someone was troubleshooting a failed deploy — and an agent connected to those systems adds one more reader to the list. Rotating the copy that a repository scanner flagged does nothing if the same key is still valid in a ticketing system or chat log the scanner never touches.

Agents accumulate more access than they end up needing. Broad permissions get granted during prototyping so nothing breaks, and then nobody revisits them once the workflow is in production. That risk compounds in multi-agent setups: an orchestration layer holding credentials for several agents becomes a single point that, if compromised, hands over everything those agents were collectively authorized to reach.

Where secrets actually live — and where scanning stops

That last row is the one most detection programs are built around, and it's also the smallest slice of the real problem. GitGuardian's data covers only public repositories; the report itself notes the picture across internal systems, collaboration tools, and self-hosted infrastructure is considerably worse [1]. Scanning catches secrets after they've already spread. It doesn't stop the spreading.

What actually narrows the exposure

Banning AI coding tools isn't realistic for most engineering organizations, and the evidence doesn't really point that way either — the fix is architectural, not prohibitive. A few things make the most concrete difference:

• Keep secrets out of the developer environment entirely. Pulling credentials from a centralized secrets manager at runtime, instead of storing them in .env files or MCP configs, means there's nothing sitting in plaintext for an agent to stumble across.
• Shorten credential lifespans. A static key that leaks stays dangerous for as long as it's valid — which the GitGuardian data shows can be years: 64% of secrets confirmed valid in 2022 were still exploitable in January 2026 [1]. A credential that expires in minutes narrows that window by definition.
• Scope each agent separately. Shared service accounts make it impossible to tell which agent did what, and they guarantee every agent inherits the broadest permission any of them needs. Individual, task-scoped, time-limited access closes that gap.
• Watch surfaces outside the repo. CI/CD systems, ticketing tools, and chat platforms hold credentials that repository scanners never see, and a meaningful share of exposure now originates there rather than in code.
• Put a human in the loop for sensitive actions. Credential access, production deploys, and privilege changes are reasonable places to keep an approval step rather than letting an agent execute autonomously by default.

What's still unclear

The GitGuardian and Keeper figures describe patterns across large samples of public commits and a conference-floor survey, not a single confirmed breach tied to a named victim. Neither source claims a specific incident of an AI agent independently exfiltrating a credential and causing measurable harm — the risk described here is exposure and governance gaps, not a documented active-exploitation event. How much of the AI-service credential growth reflects genuinely new risk versus more services simply requiring more keys is also not fully separated out in the public data.

The takeaway

AI agents didn't invent secrets sprawl. They're exposing how many organizations were already managing machine credentials loosely, just at a speed that makes the old detect-and-rotate approach too slow to matter. Scanning still has a role, but it only finds secrets after they've already spread. The more durable fix is making the secrets an agent might encounter not worth stealing in the first place — short-lived, narrowly scoped, and tied to an identity someone is actually watching.

Sources & References

1. GitGuardian — State of Secrets Sprawl Report 2026
2. Keeper Security — RSA Conference 2026 survey on AI agents and non-human identity governance
3. Keeper Security — Keeper Secrets Manager (product background, referenced for context)
4. The Hacker News — "Secrets Sprawl Is an Identity Problem That AI Just Made Impossible to Ignore"