TL;DR: GitGuardian argues that Vault, cloud IAM, Kubernetes, and CI secret stores can still leave organisations without a reliable inventory of service accounts, keys, certificates, and other NHIs because ownership, visibility, and lifecycle control remain fragmented. Secret storage is only one layer of governance; the harder problem is governing where non-human identities live, what they can reach, and when they should be revoked.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's blog post: Secret managers do not by themselves solve NHI governance, and identity sprawl persists across Vault, cloud IAM, Kubernetes, and CI systems.
Why it matters: It matters because IAM, PAM, and NHI programmes need a full inventory and lifecycle view, not just a safer place to store credentials.
👉 Read GitGuardian's analysis of why secret managers alone fail to govern NHI sprawl
Context
A secret manager reduces exposure, but it does not automatically create governance over every non-human identity in a cloud-native environment. Once credentials, roles, certificates, and API keys are spread across Vault, cloud IAM, Kubernetes, and CI systems, the core problem becomes inventory, ownership, and lifecycle control rather than storage alone.
In this article, GitGuardian shows how cloud-native teams can end up with multiple disconnected sources of truth for NHIs. That fragmentation matters for IAM and NHI governance because the organisation can no longer answer basic questions about who or what has access, where secrets live, and which systems can revoke them.
The practical issue is not whether a secret manager exists, but whether the environment has a governable identity model across machines, workloads, and automation paths. In mature programmes, this is a lifecycle problem first and a tooling problem second.
Key questions
Q: What breaks when secret managers are treated as the whole NHI programme?
A: The programme loses sight of identities that are created, stored, or consumed outside the vault, including cloud roles, Kubernetes secrets, and CI variables. That breaks ownership, recertification, and revocation because no single system holds the full lifecycle picture. The result is a partial inventory that cannot support real governance or fast incident response.
Q: Why does fragmented NHI ownership create security risk?
A: Because fragmented ownership breaks accountability. When no single team can prove responsibility for a service account or API key, remediation slows down, recertification becomes unreliable, and stale access persists longer than it should. The risk is not just administrative confusion, but delayed control action on identities that may already be overexposed.
Q: How can organisations tell whether NHI governance is actually working?
A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review. If teams can produce that chain without manual reconstruction, the programme is mature enough to withstand audit pressure. If they cannot, the governance model is still fragmented.
Q: What should organisations do when they have secrets in Vault but identities elsewhere?
A: They should treat Vault as one control point and build a governance layer that reconciles every other source of identity and secret creation. The priority is to map ownership, scope, and lifecycle across cloud IAM, Kubernetes, and CI so that revocation and review do not depend on tribal knowledge. That is the difference between storage and governance.
Technical breakdown
Why secret managers do not become the source of truth
A secret manager stores and distributes secrets, but many NHIs are created, consumed, and revoked outside it. Cloud IAM roles, Kubernetes secrets, CI variables, and dynamically generated credentials often live in separate control planes with different APIs, different ownership models, and different audit surfaces. That means the same environment can have several partial inventories, none of which is complete enough to support governance on its own. The result is not just duplication, but control fragmentation: one system knows the secret exists, another knows the role exists, and a third knows who requested it. Practical implication: treat the secret manager as one control point in a wider NHI inventory model, not the governance system of record.
Practical implication: build a cross-system inventory that reconciles identities, secrets, roles, and ownership across every source of NHI creation.
How NHI sprawl creates blind spots in least privilege
Least privilege depends on knowing every active identity, its privileges, and its business owner. In fragmented environments, NHIs are often spun up by code, handed to pipelines, and forgotten when projects change. That creates orphaned or over-privileged accounts that still authenticate successfully long after the operational need has passed. Because NHIs do not have a human manager or a ticket trail by default, they are easy to over-provision and hard to recertify. Practical implication: build recertification and ownership into NHI lifecycle management so privilege can be reviewed, not merely issued.
Practical implication: connect ownership and recertification workflows to every NHI so stale privilege does not survive project changes.
What changes when NHIs are governed across Kubernetes, CI, and cloud IAM
The governance problem changes from secret storage to identity orchestration. Kubernetes secrets, Jenkins credentials, GitLab variables, and cloud IAM roles each create different trust relationships, so the organisation needs a single view of where credentials originate, where they are used, and how they can be revoked. Without that view, incident response becomes a manual hunt across systems rather than a controlled containment process. This is where NHI programmes stop being about vaulting and start being about lifecycle and blast-radius management. Practical implication: map each identity to its source system, its runtime location, and its revocation path before the next incident exposes the gap.
Practical implication: document the revocation path for every identity type before an incident forces manual containment.
Threat narrative
Attacker objective: The attacker aims to use a leaked or forgotten non-human credential to reach sensitive systems and extend access before defenders can map the blast radius.
- Entry occurs when a leaked token, temporary password, or service credential is issued or stored in one of several disconnected systems rather than in a centrally governed identity plane.
- Credential access expands because the environment contains many over-privileged NHIs, each with different storage locations and inconsistent monitoring coverage.
- Escalation and lateral movement become easier when one compromised credential can reach cloud resources, pipelines, or Kubernetes workloads that were never jointly reviewed.
- Impact follows when the organisation cannot quickly determine what the credential can access or revoke it cleanly across all systems.
Breaches seen in the wild
- 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
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
Secret managers do not solve NHI governance by themselves. The governance gap is not storage but fragmented control over discovery, ownership, and lifecycle across multiple systems. Vault can hold secrets, but it cannot by itself reconcile cloud roles, CI variables, and Kubernetes secrets into one accountable identity model. The practitioner conclusion is simple: if the inventory is fragmented, governance is fragmented too.
Identity sprawl is a lifecycle problem, not just a secrets problem. NHIs are created by code, used by automation, and forgotten when projects move on. That means the real failure mode is unmanaged persistence, where credentials remain valid after the business need has changed. Practitioners should treat offboarding, recertification, and ownership as first-class controls for machines, not only for humans.
Cross-system visibility is the control that changes incident response economics. When SRE and security teams cannot answer what a credential can reach, containment becomes a manual search across disconnected platforms. That raises time to resolution and increases the chance that compromise outlives response. The practitioner conclusion is that blast-radius analysis must exist before the incident, not during it.
NHI blast-radius governance is the right named concept for this problem. The article shows that the real objective is not just finding secrets, but understanding where each non-human identity lives, what it can access, and how far compromise can spread. That makes governance a question of scope, ownership, and revocation paths, not a vault-only design choice. The practitioner conclusion is to govern spread, not just storage.
Dedicated secret management is necessary but insufficient for modern identity programmes. Cloud-native estates now mix human access, workload access, CI access, and service access across different administrative planes. That forces identity teams to think in terms of federated control points and lifecycle accountability. The practitioner conclusion is to align NHI governance with IAM and PAM, not leave it isolated inside the secrets team.
From our research library:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs
What this signals
NHI blast-radius governance: Teams should stop assuming that secret storage equals control. Once credentials are created in CI, Kubernetes, or cloud IAM, the governing question becomes whether the organisation can see each identity, assign ownership, and revoke it across every runtime path.
The next maturity step is to connect lifecycle governance to the same inventory that security and SRE use for operations. When ownership, recertification, and offboarding are visible in one place, manual cleanup becomes policy-driven control instead of a best-effort response.
For practitioners
- Build a unified NHI inventory Reconcile cloud IAM, Kubernetes, CI systems, and secret managers into one inventory that shows each identity, its owner, and its runtime location.
- Assign ownership to every non-human identity Require a named owner for service accounts, API keys, certificates, and pipeline credentials so orphaned identities can be reviewed and retired.
- Track revocation paths before incidents happen Document how each credential is disabled or rotated in every system that can issue or store it, including pipelines and cloud IAM.
- Separate secret storage from identity governance Use Vault and similar tools as storage and delivery controls, but govern discovery, scope, and lifecycle in a broader NHI programme.
- Measure unused and over-privileged NHIs Review accounts and credentials that have no recent use, no clear purpose, or access beyond the workload they support.
Key takeaways
- Secret managers reduce exposure, but they do not resolve the broader governance problem created by NHI sprawl across cloud, CI, and Kubernetes.
- The failure mode is fragmented visibility, which leaves teams unable to prove ownership, enforce least privilege, or revoke access consistently.
- A unified inventory with lifecycle control is the control boundary that changes both governance quality and incident response speed.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Orphaned NHIs outlive projects when offboarding is fragmented across systems. |
| NHI-05 — Overprivileged NHI | The article highlights NHIs that accumulate permissions without central review. | |
| NHI-07 — Long-Lived Secrets | Manually managed tokens and credentials can persist far beyond the intended access window. | |
| Recommendation — Map every credential to an offboarding path and remove identities when the workload or team changes. Review non-human access scopes regularly and trim privileges that exceed the workload's actual needs. Rotate long-lived secrets and replace them with shorter-lived credentials wherever feasible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements across multiple identity systems. |
| Recommendation — Centralise entitlement review so permissions for NHIs can be authorised, recertified, and revoked consistently. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Leaked or forgotten NHIs can be abused for credential access and movement across systems. |
| Recommendation — Hunt for credential exposure and correlate compromised NHIs with possible lateral movement paths. | ||
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.
- NHI Sprawl: The uncontrolled growth of non-human identities such as service accounts, API keys, OAuth clients, and machine roles. It becomes a governance problem when ownership, purpose, rotation, and decommissioning are unclear, leaving dormant credentials active long after their original use case ends.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- The concrete cross-system inventory approach used to reconcile Vault, cloud IAM, Kubernetes, Jenkins, and GitLab identities
- Examples of the scripting pattern used to collect NHIs from AWS IAM and GitLab variables
- The managed NHI Governance feature set for discovery, policy enforcement, and blast-radius analysis
- The trade-off between a DIY internal portal and a dedicated governance platform for ongoing maintenance
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 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org