NHI governance still fails when secrets sprawl outpaces IAM controls

At a glance

What this is: This is an analysis of how NHI sprawl turns secrets into an operational security problem and why existing IAM controls do not fully close the gap.

Why it matters: It matters because IAM teams need lifecycle visibility and remediation controls for secrets, not just policy definitions and access reviews.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read GitGuardian's article on protect non-human identities and secrets

Context

Non-human identity governance breaks down when credentials are treated as a byproduct of development instead of a governed identity lifecycle. In practice, secrets end up scattered across code, chat, ticketing systems, CI/CD tooling, and vaults, which leaves security teams trying to enforce policy after access has already been distributed.

GitGuardian's framing is consistent with the broader NHI problem: discovery without lifecycle control does not reduce exposure. The typical enterprise starting position is not a mature machine-identity programme, but a fragmented mix of IAM, vaulting, and manual remediation that cannot keep up with secrets sprawl.

Key questions

Q: How should security teams govern secrets for non-human identities?

A: Security teams should govern secrets as part of the full identity lifecycle, not as a storage problem. That means discovering where credentials live, assigning ownership, limiting scope, rotating on schedule, and revoking on offboarding. The goal is to reduce the time a secret remains valid and the number of places it can be reused.

Q: When does secrets sprawl become a material IAM risk?

A: Secrets sprawl becomes material when credentials are duplicated, long-lived, or stored in places outside approved controls. At that point, any one leak can create trusted access to multiple systems, and the organisation loses confidence in revocation. The risk is not the presence of secrets alone, but the inability to track and retire them quickly.

Q: What is the difference between vaulting and NHI governance?

A: Vaulting stores and protects secrets, while NHI governance manages the whole identity lifecycle around them. Governance includes discovery, ownership, access scope, rotation, monitoring, and offboarding. A vault can reduce exposure, but it does not by itself tell you where a secret was copied or whether it is still in use.

Q: Why do non-human identities increase attack surface in cloud environments?

A: Non-human identities increase attack surface because cloud systems depend on many machine credentials that must work automatically and at scale. Those credentials are often over-permissioned, reused, or spread across tools that security teams do not monitor closely enough. The result is more valid access paths than most organisations can comfortably govern.

Technical breakdown

Why secrets sprawl creates a machine identity governance gap

A non-human identity is only as secure as the secret that proves it. When API keys, tokens, and certificates are duplicated across code, chat, tickets, and pipelines, the organisation loses the ability to answer basic questions about owner, scope, and revocation state. That creates a governance gap: the credential may still work long after the business forgets where it was issued. Traditional IAM can record entitlements, but it rarely tracks every place a secret is copied or how quickly it should be retired.

Practical implication: Practitioners need inventory and lifecycle controls, not just access policy.

How compromised secrets enable escalation and lateral movement

Compromised secrets are valuable because they often authenticate as trusted service identities rather than as noisy user sessions. Once an attacker obtains a valid token or key, they can move laterally into adjacent systems, pivot through automation, or escalate privileges if the secret is over-scoped. This is why NHI risk is fundamentally about blast radius. The failure mode is not only theft, but persistence through valid credentials that remain accepted until someone rotates them or revokes their permissions.

Practical implication: Map every secret to its downstream permissions and shorten its usable lifetime.

Why visibility and remediation must extend beyond vaults

Vaults matter, but they are not a complete control plane. Many secrets live outside the vault in developer tools, logs, repositories, and collaboration systems, which means detection must span the full operating environment. Good NHI governance combines discovery, context, rotation, and offboarding. Without that chain, the organisation may know a secret exists while still missing who uses it, where it was exposed, and whether it has already been copied elsewhere.

Practical implication: Expand monitoring to code, chat, and ticketing systems, then automate revocation workflows.

Threat narrative

Attacker objective: The attacker wants durable access through trusted machine identities that can be reused for movement, escalation, or repeated access.

1. Entry occurs when an attacker finds a valid secret in public code, internal chat, or another exposed collaboration system.
2. Escalation follows when that credential authenticates to a workload or cloud service with broader permissions than intended.
3. Impact comes from lateral movement, privilege abuse, or persistence through credentials that remain valid after the exposure is discovered.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed 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 the practical form of NHI governance failure. The issue is not simply that too many credentials exist. The real failure is that organisations cannot consistently discover, classify, and retire them across the places where modern work happens. That leaves security teams with a visibility problem disguised as an access problem, and the correct response is lifecycle control across the full secret estate.

Traditional IAM does not disappear in NHI environments, but it stops being sufficient on its own. IAM can define who should have access, yet machine identities often fail at the point where the secret is copied, shared, or embedded. That is why NHI programmes need discovery, rotation, offboarding, and usage context as first-class controls. Practitioners should treat secrets governance as a parallel discipline, not an add-on to user identity.

Identity blast radius is the right lens for machine identity risk. A single exposed token can represent several systems, several permissions, and several paths to persistence. The smaller the usable scope and lifetime of each secret, the smaller the operational blast radius when exposure occurs. Teams should measure and reduce that blast radius explicitly.

Lifecycle automation is now the differentiator between visible risk and managed risk. Manual review still matters for approvals and exceptions, but it cannot keep pace with the volume and dispersion of secrets in cloud-native environments. Automated discovery, rotation, and revocation reduce the window in which an exposed NHI can be abused. Practitioners should move from periodic clean-up to continuous control.

Agentic systems will intensify this problem rather than replace it. As software becomes more autonomous, the number of machine identities and the frequency of machine-to-machine calls will rise. That means organisations need NHI governance models that assume growth, sprawl, and rapid credential churn. The practical conclusion is straightforward: design for continuous control now, or inherit a larger trust surface later.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which shows that exposure is already producing business impact.
• For lifecycle remediation, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding controls that reduce standing exposure.

What this signals

Secrets visibility is becoming a programme-level control, not an incident response luxury. Once credentials are scattered across code, collaboration tools, and pipelines, the control problem shifts from detection alone to ownership and retirement. Organisations that still treat secret discovery as a one-time clean-up exercise will continue to absorb recurring exposure, especially as automation increases credential churn. The practical response is continuous monitoring tied to enforced rotation and offboarding.

Identity blast radius should now be a formal metric in NHI governance. If a single token can open multiple systems, the organisation needs to measure how far that token can travel before it is revoked. A strong programme uses contextual inventory, privilege mapping, and time-bound access to constrain that radius. That approach aligns naturally with NIST Cybersecurity Framework 2.0 and the 52 NHI Breaches Analysis when prioritising containment.

With NHIs outnumbering human identities by 25x to 50x in modern enterprises, per the Ultimate Guide to NHIs, the operational model must assume scale rather than exception handling. That changes how teams set review cadence, decide what to automate, and define acceptable exposure windows. The next step is to align identity governance, secrets monitoring, and workload controls so the programme can absorb growth without losing sight of revocation.

For practitioners

• Implement continuous secrets discovery Scan repositories, CI/CD pipelines, chat tools, ticketing systems, and logs so exposed credentials are found where they actually appear, not only where they are supposed to live. Prioritise paths that create the largest blast radius and route findings into a revocation workflow.
• Map each secret to an owner and scope Require every API key, token, and certificate to carry an accountable owner, intended service, and explicit access boundary. Without ownership and scope, offboarding and rotation become guesswork instead of a controlled process.
• Shorten credential lifetime by default Use time-bound credentials and enforced rotation for high-risk workloads, especially where secrets are copied into code or automation. Pair shorter lifetime with validation that the secret is no longer referenced in downstream systems.
• Add offboarding to NHI review processes Include service accounts, tokens, and machine certificates in access review and decommissioning routines so orphaned identities do not persist after application changes, staff turnover, or vendor transitions.
• Measure secret exposure outside vaults Track how often secrets appear in code, developer tools, and collaboration platforms, then use that data to prioritise remediation work. Vault coverage alone is not a sufficient measure of control maturity.

Key takeaways

• Secrets sprawl turns non-human identities into an identity governance problem that traditional IAM alone cannot solve.
• The main risk is not only secret theft, but prolonged valid access through credentials that remain active across too many systems.
• Teams should focus on discovery, ownership, rotation, and offboarding across the full secret lifecycle, not just vault placement.

Key terms

• Non-Human Identity: A non-human identity is a digital identity used by software, workloads, bots, APIs, or AI agents to authenticate and access systems. It behaves like an identity control point, but it is often created and managed faster than human accounts, which makes lifecycle governance and privilege scope critical.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, tickets, chat, pipelines, logs, and other systems. It creates hidden exposure because the organisation cannot reliably track where secrets are stored, copied, or reused, which weakens rotation, revocation, and incident containment.
• Identity Blast Radius: Identity blast radius is the amount of access, reach, and downstream impact a single credential can create if it is compromised. It is a practical measure of how much damage one machine identity can cause, and it is reduced by least privilege, short lifetime, and tight scoping.
• NHI Lifecycle Management: NHI lifecycle management is the control of machine identities from creation through use, rotation, and retirement. It combines inventory, ownership, access scope, monitoring, and offboarding so credentials do not remain valid after they are no longer needed or after they have been exposed.

What's in the full article

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

• How its public and internal secrets monitoring is applied across code, Slack, Jira, Confluence, and CI/CD tools.
• How automated rotation and vaulting are positioned for secrets that already exist outside a secrets manager.
• How the platform maps permissions, owners, and consumer services to each secret for lifecycle context.
• How IDE and CLI scanning are used earlier in the development process to reduce exposure before release.

👉 GitGuardian's full post covers secrets detection, lifecycle mapping, and remediation workflows.

Deepen your knowledge

Secrets lifecycle governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with scattered credentials and unclear ownership, it is worth exploring.