TL;DR: GitGuardian says non-human identities rely on secrets that are duplicated, long-lived, and scattered across code, chat, CI/CD tools, and vaults, while traditional IAM, IGA, and PAM controls still leave gaps in visibility, lifecycle governance, and offboarding. The real security problem is not storage alone but discovery, context, rotation, and removal across the full NHI lifecycle.
At a glance
What this is: This is an analysis of why secrets sprawl keeps defeating NHI governance, with the central finding that visibility and lifecycle control matter more than storage alone.
Why it matters: It matters because IAM, PAM, and IGA teams now have to govern credentials that appear in code, collaboration tools, and pipelines, not just in central vaults.
👉 Read GitGuardian's analysis of NHI governance gaps and secrets sprawl
Context
Secrets sprawl is the condition in which machine credentials, tokens, and keys are spread across development tools, collaboration platforms, pipelines, and vaults without a single governed lifecycle. In NHI governance terms, the problem is not simply where secrets are stored, but whether the organisation can inventory, contextualise, rotate, and revoke them before they are abused.
GitGuardian argues that traditional IAM, IGA, and PAM programmes do not fully cover this lifecycle because non-human identities are created and consumed at machine speed. That creates an operational gap between who owns access on paper and where secrets actually exist in practice.
The article’s starting point is typical of modern software environments: rapid API and automation growth expands NHI use faster than governance catches up.
Key questions
Q: What breaks when NHI secrets are stored in code or CI/CD systems?
A: You lose the containment boundary. A single exposed secret can be copied into build logs, deployment tools, developer machines, and downstream environments, which makes revocation slower and incident scope much wider. Vaulting is meant to prevent exactly that replication problem by controlling where secrets can live and who can retrieve them.
Q: Why do leaked machine credentials create lateral movement risk so quickly?
A: Because an NHI secret often authenticates a non-human workload directly, and the associated permissions may already span multiple systems. If the secret is valid and over-scoped, an attacker can move from one exposed credential to broader access without needing to break authentication again.
Q: How should teams prioritise NHI discovery versus credential rotation?
A: Discovery comes first when the estate is unknown, because you cannot rotate what you have not found. But rotation becomes the higher priority once critical credentials are identified, because unrotated secrets preserve risk even after inventory improves. The two controls must be sequenced, not treated as alternatives.
Q: When does vaulting fail as an NHI control?
A: Vaulting fails when it becomes the end state instead of the control point. If secrets are still copied into pipelines, chat tools, logs, and repos, the vault stores one copy while the rest remain outside lifecycle governance and can still be used or leaked.
Technical breakdown
Why secrets sprawl breaks NHI visibility
Non-human identities authenticate with secrets such as API keys, tokens, certificates, and service credentials. When those secrets are copied into repositories, logs, chat tools, CI/CD jobs, and third-party systems, the identity estate becomes fragmented and hard to govern. The technical issue is not only leakage; it is that the same secret can exist in multiple places with different owners, permissions, and revocation paths. Once that happens, inventory accuracy collapses and traditional access models lose context about where the credential is active.
Practical implication: build a single inventory that ties each secret to its owner, scope, and consumer service.
Why standing privilege turns secret exposure into lateral movement
A leaked secret is only as dangerous as the privilege attached to it, but NHIs are often provisioned with broad access and long lifetimes. That combination turns one exposed token into a reusable path for privilege escalation or lateral movement. In practice, the attacker does not need to defeat authentication again if the credential remains valid and over-scoped. This is why the lifecycle of the secret matters as much as the storage location: old credentials remain exploitable long after the original business need has changed.
Practical implication: reduce standing privilege on machine credentials and shorten their usable lifetime.
Why vaulting alone does not solve NHI governance
Vaults centralise secrets, but they do not automatically govern every place a secret is copied, embedded, or consumed. The article’s key architectural point is that NHI control must span vaults, source control, collaboration tools, deployment systems, and cloud providers. If governance stops at the vault, the organisation still lacks offboarding, usage context, and exposure tracing. The result is a control plane that stores credentials well but cannot prove where they are in use or whether they should still exist.
Practical implication: govern secret lifecycle across all consumption points, not just inside the vault.
Threat narrative
Attacker objective: The attacker aims to turn a single exposed machine credential into durable access across systems and workloads.
- Entry occurs when a secret is exposed in code, chat, logs, or another internal system and is later discovered by an attacker or insider.
- Credential access follows when the exposed secret is reused to authenticate as the NHI without additional challenge.
- Escalation and lateral movement occur when that credential has broad permissions or remains valid long enough to reach additional systems.
- Impact is the abuse of machine trust to move across environments, access sensitive data, or expand the breach beyond the original exposure point.
Breaches seen in the wild
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
- 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 governance problem, not a storage problem. The article shows that machine credentials move through code, chat, CI/CD, and vaults, which means the control boundary is no longer a single secrets manager. Governance has to follow the secret wherever it is consumed, because the operational risk sits in uncontrolled distribution as much as in disclosure. The practitioner conclusion is that visibility across the full credential estate is the first control plane.
Standing privilege is the real force multiplier behind leaked NHI secrets. A leaked token matters most when it remains valid and broadly authorised, because that converts exposure into lateral movement. That is why NHI governance cannot treat secrets as static objects separate from access scope. The practitioner conclusion is to evaluate every credential by permission depth and usable lifetime, not by whether it is stored in a vault.
Traditional IAM assumes identities are centrally registered; NHIs often are not. The article makes clear that microservices, APIs, and automation create identities faster than teams can inventory them. That means joiner-mover-leaver logic, recertification, and offboarding all break when the secret is the only trace of the identity. The practitioner conclusion is that NHI governance must begin with discovery and ownership, not with periodic review.
Ephemeral access without lifecycle governance only shifts the exposure window. The problem is not that modern environments use more automation, but that credentials can be issued, copied, and left behind faster than governance cycles can respond. Identity blast radius: the effective damage domain of one secret grows when one credential unlocks multiple tools, workloads, and environments. The practitioner conclusion is that reducing blast radius is now a central NHI design goal.
Machine identity governance and human IAM now intersect at the point of accountability. Developers may create the secret, platform teams may host it, security teams may monitor it, and no single group may own its full lifecycle. That cross-functional gap is where NHI programmes fail in practice. The practitioner conclusion is that ownership, not just detection, has to be explicit for every secret-bearing identity.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Guide to NHI Rotation Challenges
What this signals
Identity blast radius: the more places a machine secret can live, the harder it is for IAM, PAM, and IGA to describe the true access surface. The operational shift is from managing a vault to governing every consumption point where a secret can be copied, reused, or left behind.
Machine identity programmes should now treat secret discovery as an ongoing control, not a one-time hygiene task. Once teams can see where credentials actually exist, they can make rotation and revocation meaningful instead of purely ceremonial.
The article reinforces a simple but uncomfortable point: an NHI programme that cannot inventory secrets across development and collaboration tools is not controlling the identity layer, only part of its storage layer.
For practitioners
- Map every secret to an owning service and human steward Create an inventory that records the secret, the workload that consumes it, the business owner, the technical owner, and the revocation path. Treat unowned secrets as governance defects, not just technical leftovers.
- Reduce the permissions attached to machine credentials Review each secret for actual runtime scope and remove unnecessary write, admin, and cross-environment access. Broad credentials turn routine exposure into lateral movement.
- Shorten the usable lifetime of non-human credentials Replace long-lived static secrets with credentials that expire quickly enough to limit reuse if they are copied into logs, code, or chat systems.
- Scan collaboration and pipeline tools for hidden secrets Extend detection beyond source repositories into Slack, Jira, Confluence, CI/CD, and logs so the organisation can find copies that vault-only controls miss.
- Define an offboarding rule for every non-human identity When a workload, integration, or third-party relationship ends, revoke the associated secret and verify that no downstream copies remain active.
Key takeaways
- Secrets sprawl turns NHI governance into a lifecycle problem because credentials now move across code, chat, pipelines, and vaults.
- The scale of the issue is amplified by the fact that NHIs outnumber human identities by 50x in enterprises.
- Teams reduce risk only when they can discover secrets, constrain privilege, and revoke credentials everywhere they are used.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set 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 and duplicated machine secrets across tools and repositories. |
| NHI-05 — Overprivileged NHI | The article says developers grant NHIs excessive permissions and long lifespans. | |
| NHI-07 — Long-Lived Secrets | Long-lived credentials are a core reason secrets sprawl becomes exploitable. | |
| Recommendation — Scan for exposed machine secrets and revoke any credential that appears outside governed storage. Reduce NHI permission scope and eliminate standing access that exceeds runtime need. Replace long-lived secrets with shorter-lived credentials and enforce expiry-based governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is uncontrolled entitlements attached to machine credentials. |
| Recommendation — Review entitlements on every NHI credential and remove permissions that are not required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle management directly applies to rotation and revocation of secrets. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and replace stale machine credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article explicitly ties exposed secrets to credential abuse and lateral movement. |
| Recommendation — Map exposed secrets to credential access and lateral movement risk in threat detection and response. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- 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.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
What's in the full article
GitGuardian's full analysis covers the operational detail this post intentionally leaves for the source:
- Secret discovery workflows across code repositories, CI/CD tools, chat platforms, and ticketing systems
- Lifecycle automation details for rotation, vaulting, and revocation across mixed NHI estates
- How the platform correlates permissions, owners, and consumer services for each secret
- Examples of internal and external secret monitoring patterns that support remediation
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 building or maturing an IAM programme, 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