Secrets sprawl is still outpacing enterprise credential revocation

At a glance

What this is: This is GitGuardian’s 2025 analysis of secrets sprawl, showing that hardcoded credentials, API keys, and tokens continue to leak at scale across public code and AI-related workflows.

Why it matters: For IAM and NHI practitioners, the report underscores that discovery without automated revocation leaves standing access in place long after exposure.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read GitGuardian's 2025 report on secrets sprawl and credential exposure

Context

Secrets sprawl is the broad, repeated exposure of credentials across code, collaboration tools, pipelines, and AI-adjacent systems. In IAM and NHI terms, it creates a governance gap because the identity itself remains valid even when the secret has already been copied, shared, or indexed elsewhere.

GitGuardian’s latest analysis treats this as an operational security problem rather than a simple hygiene issue. The data points to a familiar enterprise pattern: organizations can discover exposure quickly, but many still cannot revoke, rotate, and reissue credentials fast enough to shrink blast radius.

The report is especially relevant as AI development introduces more machine-issued and machine-consumed secrets into the environment. That makes the subject typical for modern engineering teams, not an edge case limited to immature security programs.

Key questions

Q: How should organisations respond when a secret is exposed in code or a workflow?

A: Treat the exposure as an active identity incident, not a hygiene issue. Revoke the secret, check for copies in logs and mirrored repositories, rotate any dependent credentials, and confirm that the owning service or workload has a valid replacement before closing the case.

Q: Why do leaked secrets remain dangerous after they are detected?

A: They remain dangerous because discovery does not automatically invalidate authentication. If the secret is still valid, an attacker can reuse it exactly as the legitimate system would, which turns a past mistake into present access.

Q: What is the difference between secret scanning and secret revocation?

A: Secret scanning finds exposure, while secret revocation removes the ability to authenticate with the exposed credential. Scanning reduces blind spots, but revocation is what actually breaks attacker reuse and shrinks blast radius.

Q: Should teams treat AI-related credentials differently from ordinary application secrets?

A: Yes. AI-related credentials often sit in rapidly changing pipelines, tool connections, and agent workflows, so ownership and scope can be unclear. Teams should give them separate inventory, tighter scope, and faster rotation than legacy application secrets.

Technical breakdown

Why secrets sprawl becomes an identity problem

A secret is the proof used to authenticate a non-human identity, such as a service account, API key, token, or certificate. When that proof leaks, the credential can be copied without the owner’s knowledge and reused until it is revoked or expires. That means the security issue is not only where the secret appeared, but whether the underlying identity remains trusted across systems. In practice, secrets sprawl converts a local mistake in one repo or workflow into enterprise-wide authentication risk. The mechanism is simple, but the governance failure is structural: many environments still treat secret exposure as an alert, not as an access-control event.

Practical implication: Treat leaked secrets as active identity incidents and tie every detection to revocation, rotation, and reissuance workflows.

Why public, private, and collaboration-tool leaks behave differently

GitGuardian’s data shows that secrets do not only leak from source code. Private repositories, Slack, Jira, Confluence, and package registries all create different exposure paths, but the common failure mode is the same: credentials move faster than controls. Public code creates immediate adversary visibility, while collaboration-tool leaks often hide in text, screenshots, or pasted snippets that escape code scanning. Private repositories are not a safe assumption either, because internal visibility can create a false sense of containment. For NHI governance, the lesson is that detection coverage must extend beyond repositories and into the full software delivery and collaboration footprint.

Practical implication: Expand scanning and response coverage to collaboration tools, CI/CD systems, and package releases, not just source repositories.

What MCP and AI service leaks change for control design

Model Context Protocol files and AI service integrations introduce a new class of credential concentration. MCP configurations can embed access to tools and data sources, which makes them attractive targets when the agentic stack grows faster than governance. Likewise, AI service credentials are often wired into development workflows before teams have built revocation, scope review, and ownership mapping. The result is not simply more secrets, but more secrets tied to autonomous or semi-autonomous systems that can act quickly once compromised. That is why AI-era NHI governance must include issuance discipline, scope limitation, and recovery playbooks from day one.

Practical implication: Inventory AI-related secrets separately and require ownership, rotation, and emergency revocation paths before production rollout.

Threat narrative

Attacker objective: The attacker objective is to turn a leaked credential into durable authenticated access that can be reused for lateral movement, data access, or supply-chain compromise.

1. Entry occurs when a hardcoded secret, API key, or token is exposed in a public repository, package release, or collaboration tool.
2. Escalation follows when the credential remains valid long after discovery, allowing threat actors to authenticate as the non-human identity.
3. Impact occurs when attackers use the trusted credential to access systems, move through pipelines, or harvest additional secrets for wider compromise.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets sprawl is now an NHI governance problem, not just a secure-coding problem. The report shows that exposure persists because the credential itself remains valid even after the leak is found. That shifts the control question from detection coverage to identity lifecycle control, including revocation, rotation, ownership, and access review. Practitioners should treat every secret as a live non-human identity with a lifecycle, not a static string in a file.

Ephemeral exposure does not mean ephemeral risk. A secret that lives for minutes in a workflow can still create a long-lived trust relationship if it is copied into logs, packages, or mirrored repositories. The new named concept here is ephemeral credential trust debt: the accumulation of unresolved trust from short-lived credentials that continue to exist beyond their intended window. Teams should measure how much residual trust survives after each leak, then reduce that debt with automated cleanup.

AI adoption is amplifying the volume and diversity of credential exposure. The report’s AI-related findings show that the growth of model pipelines, agent tooling, and external AI services is now creating fresh secret-management pressure faster than conventional IAM processes can absorb. That means security teams need separate policy treatment for AI credentials, not just another row in the same secrets inventory. Practitioners should assume the AI estate will expand exposure unless governance is designed into it.

Detection without enforced revocation is no longer a credible operating model. GitGuardian’s findings reinforce what many incident teams already see: a discovered secret is still an active identity until it is invalidated. This invalidation gap is where the real loss occurs, because attackers only need one valid reuse path. Security leaders should align ownership, tooling, and response metrics around time-to-revoke, not just time-to-detect.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• In the same study, 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and those incidents are 13% more likely to be classified as critical than code-based leaks.
• For a broader view of how AI and agent workflows expand credential exposure, see Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Ephemeral credential trust debt: short-lived credentials can still generate long-lived exposure when they are copied, cached, or reused outside their intended window. For programmes built around NHI governance, the practical question is how much residual trust survives each leak, and how quickly that trust is extinguished with automation and access review. This is where secret management becomes identity lifecycle management, not just scanner output.

With 28,650,000 new hardcoded secrets detected in 2025, the scale of the problem is large enough to distort IAM backlog planning and incident response capacity. Teams should expect more alerts from AI-related pipelines, more ownership ambiguity, and more pressure to align to control families such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026. The next phase of maturity is not better discovery alone, but faster trust removal.

For practitioners

• Implement time-to-revoke as a core control metric Measure the interval from first exposure to credential invalidation across repositories, pipelines, and collaboration tools. Set escalation thresholds for secrets that remain valid after discovery, and report the metric alongside detection counts so leadership can see residual exposure.
• Extend scanning beyond source code Cover Slack, Jira, Confluence, package registries, and CI/CD runners with the same detection and response workflow you use for repositories. The goal is to catch non-code leak paths early enough that revocation still matters, especially for AI and MCP-related credentials.
• Separate AI credentials into a dedicated control set Inventory model, agent, and tool-integration secrets separately from standard application credentials. Require named owners, explicit scope, rotation intervals, and an emergency kill process before the secrets are allowed into production workflows.
• Build revocation automation into incident response Automate secret invalidation, token replacement, and downstream dependency checks so response teams are not manually chasing every usage point. If the same secret can persist in multiple places, the response runbook must remove trust everywhere at once.

Key takeaways

• Secrets sprawl is an NHI governance issue because a leaked credential is still a live identity until it is revoked.
• The evidence points to a scale problem, with exposure spreading across code, collaboration tools, package releases, and AI workflows.
• Practitioners should optimise for time-to-revoke, not just time-to-detect, if they want to reduce blast radius.

Key terms

• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, collaboration tools, and package artifacts. It becomes a governance problem when teams can no longer account for where secrets exist, who can use them, or how quickly they can be revoked after exposure.
• Non-Human Identity: A non-human identity is any machine-usable account or credential that authenticates software instead of a person. That includes service accounts, API keys, tokens, certificates, bots, workloads, and AI agents that need controlled access to systems and data.
• Credential Revocation: Credential revocation is the act of invalidating a secret so it can no longer be used to authenticate. In practice, it must be fast, automated, and tied to ownership, because a valid leaked credential remains an active access path until it is replaced or disabled.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the residual risk that remains after a short-lived secret is exposed, copied, or cached beyond its intended window. It captures the gap between how temporary the credential was supposed to be and how long its trust value actually persists.

What's in the full report

GitGuardian's full report covers the operational detail this post intentionally leaves for the source:

• Year-over-year breakdowns of secret leakage by repository type, service type, and industry
• Examples of valid secret types that remained exposed five days after detection
• The report's methodology for scanning 1.1 billion commits and validating leaked credentials
• Operational guidance on reducing false positives for generic secrets and improving remediation workflow

👉 The full GitGuardian report covers leak validity, AI-related exposure, and remediation gaps in more detail.

Deepen your knowledge

Secrets sprawl and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a response model for leaked credentials, it is worth exploring.