What is secret sprawl?
By Identra · Updated
Secret sprawl is the uncontrolled spread of credentials, API keys, tokens, certificates, and passwords, across source code, chat tools, CI logs, AI prompts, and browsers. Each exposed secret is a working credential for a non-human identity, so sprawl turns every stray copy into an unowned, unexpiring entry point.
Key numbers
- 28.65 million new hardcoded secrets hit public GitHub in 2025, up 34% year over year (GitGuardian State of Secrets Sprawl, 2026)
- Leaked secrets tied to AI services reached 1.27 million in 2025, up 81% from 2024 (GitGuardian State of Secrets Sprawl, 2026)
- 64% of valid secrets leaked in 2022 were still active in January 2026 (GitGuardian State of Secrets Sprawl, 2026)
- About 28% of secret incidents start outside repositories, in tools like Slack and Jira (GitGuardian State of Secrets Sprawl, 2026)
What causes secret sprawl?
Every piece of software that talks to another piece of software authenticates with a secret. Microservices, CI/CD jobs, SaaS integrations, scripts, and now AI agents each mint API keys, tokens, and service-account passwords. Non-human identities already outnumber human ones many times over in most organizations, and nearly every one of them carries at least one secret.
Secrets are created far faster than they are inventoried. A key issued for one integration gets copied into a teammate's environment file, pasted into a Slack thread for debugging, echoed into a build log, and committed to git history. None of those copies is tracked, and most never expire.
- Machine-to-machine growth: every new service, pipeline, and integration adds credentials
- Convenience copying: one key ends up in wikis, chat threads, .env files, and personal notes
- No default expiry: GitGuardian (2026) found 64% of secrets leaked in 2022 were still valid in January 2026
- Detection lags creation: scanners catch known key formats, while generic passwords and connection strings slip through
Why is secret sprawl an identity problem?
A secret is not a random string to be tidied up. It is the entire authentication ceremony for a non-human identity. When a human password leaks, there is a named owner, a reset flow, and usually MFA behind it. When a machine secret leaks, there is often no recorded owner, no expiry date, and no second factor: whoever holds the string simply is that identity.
That is why sprawl is better understood as unowned identities multiplying than as messy string hygiene. Each stray key is a login that works from anywhere, for anyone, indefinitely. The 2024 breach of the U.S. Treasury Department began with a single leaked API key for BeyondTrust's platform, a credential that bypassed the surrounding security stack outright (reported in GitGuardian's 2025 analysis).
How does AI accelerate secret sprawl?
AI added three new leak vectors at once. First, AI-generated code leaks more: GitGuardian (2026) measured a 3.2% secret-leak rate in Claude Code-assisted commits versus a 1.5% baseline. Second, AI services themselves mint high-value keys, and those keys are leaking fast: 1.27 million AI-service secrets were exposed in 2025, up 81% year over year. Third, agent infrastructure is a new storage surface: 24,008 unique secrets were found in MCP configuration files, the JSON that wires AI agents to external tools.
There is also a quieter vector: secrets pasted directly into prompts. A database password dropped into a chat window to debug a connection now lives in conversation history, provider logs, and potentially future context windows. And agents that hold vault tokens or broad OAuth grants become secret concentrators, a single compromised agent yields every credential it was trusted with.
Is the browser a secret sprawl surface?
Yes, and it is largely unscanned. SaaS admin consoles render API keys in the page for copying. Users paste credentials into web-based AI chats and online formatters. Session tokens and JWTs sit in cookies and local storage where malicious extensions or injected scripts can read them. The clipboard itself briefly holds every secret a person moves between tools.
GitGuardian (2026) found roughly 28% of secret incidents originate entirely outside repositories, in collaboration and productivity tools, and those incidents were more likely to be rated critical. Repo scanning alone watches the surface where secrets are created, not the surfaces where people and agents actually handle them.
Where do secrets sprawl to?
Sprawl follows the paths of least resistance. The common surfaces, and the reason each one keeps leaking, look like this:
| Surface | Typical exposure | Why it persists |
|---|---|---|
| Source code and git history | Hardcoded keys, committed .env files | History preserves secrets even after deletion |
| CI/CD pipelines and logs | Tokens echoed into build output | Logs are broadly readable and rarely scrubbed |
| Collaboration tools | Keys pasted into Slack, Jira, wikis | About 28% of incidents start here (GitGuardian, 2026) |
| AI prompts and agent configs | Secrets in prompts, MCP config files | Conversation logs and agent configs sit outside scanners |
| Browsers | Tokens in local storage, keys pasted into web apps | No code-scanning tool sees this surface at all |
How do you contain secret sprawl?
Containment starts by treating every secret as a credential attached to an identity, then shrinking what any single leak can do.
- Inventory with ownership: map every secret to the non-human identity it authenticates and a named human owner
- Scan beyond repos: cover chat, tickets, wikis, build logs, and agent configuration files, not just git
- Prefer short-lived credentials: workload identity and expiring tokens over static, long-lived API keys
- Rotate on detection, verify validity: a leaked key is an incident until proven revoked, not a cleanup ticket
- Watch runtime use: an old key used from a new location or by a new process is the earliest exploitation signal
How Identra thinks about it
Secret sprawl is usually framed as a hygiene problem: scan, alert, rotate, repeat. Identra's view is that this treats the symptom. A leaked secret is dangerous because it is a bearer credential for an identity nobody is watching at runtime, and the population of those identities, human, workload, and AI agent, is growing faster than any scanning program can keep up with. The durable fix is to make the identity, not the string, the unit of security: know which workload or agent a credential belongs to, who owns it, what it is entitled to touch, and whether its use at runtime matches that purpose. With that context, a leaked key stops being an anonymous skeleton key and becomes a detectable anomaly.
Go deeper: The Non-Human Majority
Frequently asked questions
How do secrets usually get leaked?
The most common paths are hardcoding keys in source code and committing them to git, echoing tokens into CI/CD logs, pasting credentials into chat tools and tickets, and baking secrets into container images and configuration files. Newer paths include AI prompts and agent configuration files. Git history is especially dangerous because a secret deleted from code survives in past commits.
What is the difference between secret sprawl and secrets management?
Secrets management is the control: a vault that stores, rotates, and injects credentials under policy. Secret sprawl is the failure condition: copies of credentials spreading into code, logs, chat, and browsers outside any vault. An organization can run a mature vault and still suffer sprawl, because the vault only governs the secrets that were checked in.
How do you detect secret sprawl?
Run scanners across git repositories and their full history, CI/CD logs, container images, chat platforms, ticketing systems, and wikis. Verify which findings are still valid credentials, since live keys are incidents rather than cleanup items. Then map each secret to the system it unlocks and a named owner, so revocation and rotation have someone accountable.
Is a secret still a risk after it is deleted from the code?
Yes. Version control preserves every committed value in history, so a key removed in a later commit remains retrievable by anyone who can clone the repository. Forks, mirrors, and local copies spread it further. Treat any secret that ever touched a repository as exposed: rotate it, then rewrite history only as a secondary cleanup step.