TL;DR: GitGuardian's 2025 secrets sprawl analysis says hardcoded credentials continue to spread faster than organisations can revoke them, with leaked secrets still lingering after detection and outside the control of central secrets managers. The real governance problem is not discovery alone but whether credential lifecycle controls can contain exposure before reuse.
At a glance
What this is: This is a GitGuardian analysis of 2025 secrets sprawl showing that hardcoded credentials still leak widely and remain exposed long enough to outlast conventional revocation workflows.
Why it matters: It matters because IAM, PAM, and NHI teams need controls that shorten exposure windows, not just better detection of leaked secrets after the fact.
By the numbers:
- 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services.
👉 Read GitGuardian's 2025 analysis of secrets sprawl and revocation lag
Context
Secrets sprawl is the accumulation of credentials, API keys, tokens, and other secrets across code, collaboration tools, and deployment systems faster than they are revoked or inventoried. In practice, the security gap is not whether organisations can detect one leaked secret, but whether they can contain the exposure before it becomes reusable.
GitGuardian's 2025 analysis frames that gap as a lifecycle problem for NHI governance. Hardcoded secrets, especially those embedded in development workflows and adjacent collaboration systems, persist because discovery, owner identification, and revocation are usually handled as separate processes instead of one governed workflow.
The result is a control mismatch: many programmes can find a leak, but far fewer can prove that the credential was actually revoked, replaced, and removed from downstream systems. That is the condition this report exposes, and it is typical rather than exceptional across modern software estates.
Key questions
Q: What breaks when a leaked secret is revoked without context?
A: Uncontextualised revocation can break live integrations, payment paths, or other production dependencies while failing to reduce exposure in a controlled way. The result is a worse incident, not a cleaner one. Teams need to know whether the credential is isolated, staged, vaulted, or embedded in a business-critical workflow before they act.
Q: Why do leaked API keys and tokens create such a large security risk?
A: They authenticate actions directly, so anyone who finds them can act as a trusted caller. If the secret is long-lived or broadly scoped, the attacker gains standing access that may bypass normal user controls, making the leak a privilege and identity problem as much as a data exposure issue.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.
Q: Should organisations prioritise secret rotation or secret discovery first?
A: They should do both, but rotation is the control that reduces immediate exposure when a secret is already live. Discovery tells you where the problem is. Rotation and revocation tell you whether the credential still works. If you can only choose one urgent action after a leak, invalidate the credential and confirm it is no longer active.
Technical breakdown
Why secrets sprawl persists across modern delivery pipelines
Secrets sprawl persists when credentials move through source control, tickets, chat, CI/CD, and package artefacts faster than inventory and revocation can keep up. A secret manager centralises storage, but it does not eliminate copies already embedded in code, logs, comments, or human workflows. The technical failure is fragmentation: discovery tooling sees one surface at a time, while attackers only need one valid copy. In NHI terms, the identity lifecycle is wider than the vault boundary, so leaked access can survive even when the primary store is controlled.
Practical implication: treat every secondary copy of a secret as part of the governed lifecycle, not as an exception outside it.
Why leaked credentials remain exploitable after detection
A leaked secret becomes dangerous only if it stays valid after discovery, which is why revocation speed matters more than notification volume. The article's emphasis on zombie leaks shows the operational gap between identifying exposure and actually invalidating the credential everywhere it can be used. This is especially acute for service and API credentials because the same secret may authenticate across multiple systems. In NHI governance, the control objective is not merely finding the leak, but shrinking the period in which the credential can still be accepted.
Practical implication: tie detection to automated revocation and downstream propagation checks, not to email alerts alone.
How AI service adoption changes the secret exposure surface
AI services increase the number of places where secrets appear because teams embed provider keys into applications, orchestration layers, and experimentation workflows. That broadens the attack surface beyond classical repository scanning and into collaboration systems and developer tooling. The main architectural issue is that AI integrations often rely on static credentials for convenience, which creates long-lived trust paths that are hard to audit later. For identity practitioners, this is not an AI model problem but a credential governance problem created by AI adoption patterns.
Practical implication: classify AI service keys as high-risk NHIs and govern them with stricter issuance, rotation, and offboarding rules.
Threat narrative
Attacker objective: The objective is to reuse a still-valid secret to gain unauthorised access before the organisation revokes it.
- Entry occurs when a hardcoded secret is exposed in a public commit, package release, or collaboration tool outside the organisation's primary control boundary.
- Credential access follows when an attacker or mirror bot retrieves the valid secret before it is revoked or replaced.
- Escalation happens when the same credential grants access to additional systems, environments, or AI services that trust the leaked secret.
- Impact is achieved when the exposed credential is reused to read data, alter systems, or stage further compromise before the secret is invalidated.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secrets sprawl is now a credential lifecycle failure, not just a detection problem. The article shows that organisations can find exposed secrets while still failing to invalidate them fast enough to matter. That means the real control boundary is issuance, propagation, and revocation, not the scanner alone. The practitioner conclusion is blunt: if revocation is slower than exposure, governance has already lost the race.
Leaked secrets create identity blast radius because one credential often spans multiple systems. A hardcoded key in code is not just a code hygiene issue when the same secret also authenticates to cloud services, AI APIs, or downstream build steps. This turns a single exposure into a multi-system trust problem. The implication is that secrets must be governed as reusable identities with explicit scope, ownership, and offboarding.
Secrets embedded in collaboration tools are evidence that inventory has drifted beyond code. GitGuardian's analysis points to Slack, Jira, and Confluence as active leak locations, which means traditional repository-centric programmes are already incomplete. That widens the governance boundary from software development to operational communication channels. Practitioners need to treat non-code locations as first-class NHI storage surfaces.
AI service adoption is amplifying static credential debt. The report's AI-secret pattern shows that teams are extending old authentication habits into new workloads, which increases the number of long-lived keys in circulation. This is a governance smell, not just a tooling issue. The field should read it as a sign that AI rollout without identity redesign simply multiplies secret sprawl.
Ephemeral access is not yet the default, which is why zombie secrets keep winning. The article makes clear that many leaked credentials stay valid long after discovery, proving that the lifecycle model has not caught up with how secrets are actually distributed. That breaks the assumption that a leaked credential is effectively dead once found. The practitioner conclusion is that exposure control must be designed into the identity model itself.
From our research library:
- 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, according to the State of Secrets Sprawl 2026.
- 8 of the top 10 fastest-growing types of leaked secrets year-over-year are tied directly to AI services, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secrets sprawl is now a lifecycle problem as much as a discovery problem. Teams that only scan code are already missing leak locations in Slack, Jira, Confluence, and release artefacts. The governance lesson is that inventory must follow the secret across the full collaboration and delivery chain, not stop at the repository boundary.
Ephemeral credential trust debt: When organisations keep relying on static keys for cloud and AI services, they accumulate a trust debt that shows up later as zombie secrets. The practical implication is that every new integration increases the cost of delay in revocation and ownership.
The strongest signal from this report is that secrets governance is becoming a cross-functional identity discipline. IAM, PAM, engineering, and platform teams all need the same revocation evidence, or exposure will keep outpacing control.
For practitioners
- Map every secret to an accountable owner Require each API key, token, certificate, and service secret to have a named owner, a system of record, and a defined revocation path before it reaches production.
- Automate revocation after secret detection Connect scanning tools to revocation workflows so a detected leak triggers invalidation, rotation, and downstream access checks instead of a manual ticket queue.
- Expand scanning beyond source control Include Slack, Jira, Confluence, CI/CD variables, build logs, and package artefacts in the secret discovery scope because the leak surface now extends past repositories.
- Classify AI service credentials as high-risk NHIs Treat model and embedding service keys as privileged machine identities with tighter issuance, shorter lifetime, and explicit offboarding when projects end.
- Measure revocation lag as a security metric Track time from first detection to confirmed invalidation and removal from downstream systems, then use that lag as a control health signal in governance reporting.
Key takeaways
- Secrets sprawl now exposes a basic governance gap: organisations can discover leaks faster than they can confidently revoke the credentials behind them.
- The report ties the problem to broad usage of hardcoded credentials across repositories, collaboration tools, and AI-related services, which expands the attack surface.
- The most effective control is not more alerting but tighter ownership, faster invalidation, and proof that downstream access paths have actually been closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on leaked hardcoded secrets across code and collaboration tools. |
| NHI-07 — Long-Lived Secrets | The core issue is leaked secrets staying valid long after detection. | |
| NHI-05 — Overprivileged NHI | Leaked keys often have broader access than the task requires, increasing blast radius. | |
| Recommendation — Scan all collaboration and delivery surfaces for exposed secrets and revoke any credential found. Shorten secret lifetime and enforce rapid rotation so exposure windows stay small. Reduce secret scope so any leaked credential can access only the minimum required systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle management directly maps to secret rotation and invalidation. |
| Recommendation — Apply IA-5 to manage issuance, rotation, and revocation of machine authenticators. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The pattern reflects credential harvesting and reuse from exposed secrets. |
| Recommendation — Map exposed-secrets detection to TA0006 and watch for reuse that leads to exfiltration. | ||
Key terms
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Zombie Leak: A zombie leak is a secret exposure that continues to remain valid after it has been discovered. The secret may be deleted from one location, but if the underlying credential is still accepted elsewhere, the exposure remains active and can still be abused.
- Revocation Latency: Revocation latency is the time between a decision to remove access and the point at which that access is actually gone. It is a practical measure of how long stale privilege remains usable after a role change, offboarding, or contract end. Shorter latency means smaller exposure and cleaner audit evidence.
- Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
What's in the full report
GitGuardian's full report covers the operational detail this post intentionally leaves for the source:
- Year-over-year leak patterns by secret type, including the fastest-growing AI-related exposures
- Industry-level leak concentration data that can help security leaders benchmark where secrets are most likely to surface
- The zombie leak analysis showing how long secrets remain valid after discovery
- AI-detection methodology and the generic secret scoring work behind the report's findings
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org