TL;DR: P0 Security’s roundtable says non-human identities are growing at roughly 50 per human identity, while fragmented SaaS, cloud, and Kubernetes controls create blind spots that turn inventory into a governance problem. Least privilege, JIT access, and lifecycle management are now the real levers for NHI risk reduction.
At a glance
What this is: This roundtable summary argues that cloud-to-workload identity sprawl is making NHI governance harder because identities now span multiple platforms, accelerate faster than controls, and create transitive access paths that are difficult to govern consistently.
Why it matters: IAM, IGA, and PAM teams need to treat workload and service-account sprawl as a lifecycle and blast-radius problem, not just an inventory exercise, because fragmented control planes undermine least privilege and access review.
By the numbers:
- For every human identity, there are 50 non-human identities, according to P0 Security.
👉 Read P0 Security's analysis of cloud-to-workload identity sprawl and NHI governance
Context
Cloud-to-workload identity sprawl describes the spread of service accounts, APIs, cloud-provider agents, and background tasks across SaaS, cloud services, and Kubernetes environments. In this article, the governance gap is not simply how many identities exist, but that they are managed in separate systems with separate control assumptions.
That fragmentation weakens basic identity governance. When identities span multiple platforms without a shared lifecycle model, security teams lose visibility into standing privilege, review cadence, and ownership, which makes NHI risk look smaller than it is until abuse appears.
The article’s central claim is that the old distinction between human IAM and machine identity governance is no longer operationally useful. Least privilege, zero trust, JIT access, and lifecycle management must now be applied across the full cloud-to-workload identity chain.
Key questions
Q: What breaks when service accounts and workload identities are managed in separate silos?
A: Access reviews become incomplete, stale privileges persist longer, and indirect trust paths stay invisible. Separate tools may each look acceptable, but the combined identity estate can still allow lateral movement or data exposure. Teams need a single inventory and a shared governance model to see the real risk.
Q: Why do service accounts and AI agents increase lateral movement risk?
A: Service accounts and AI agents often operate with persistent permissions across multiple systems, which makes them useful stepping stones after compromise. If their access is broader than the task requires, attackers can pivot through cloud resources, manipulate infrastructure, or access sensitive data without needing to steal additional credentials.
Q: What are the signs that NHI lifecycle governance is failing in hybrid cloud?
A: The clearest signs are stale accounts that remain active after migrations, sync identities that still bridge multiple environments, and service accounts whose permissions no longer match their workload. Those conditions show that offboarding and recertification are not keeping pace with machine change.
Q: What should organisations do first when moving toward least privilege for NHIs?
A: They should start by discovering where non-human identities exist, who owns them, and what privileges they carry. After that, define policy for eligibility, review cadence, and revocation, then use JIT to time-box the permissions that remain necessary. Discovery comes before optimization because you cannot govern what you cannot see.
Technical breakdown
Why identity sprawl creates governance blind spots
Identity sprawl appears when the same organisation manages cloud identities, SaaS identities, and workload identities through different consoles, policies, and ownership models. The technical problem is not just scale. It is that every platform produces its own version of truth for entitlements, which makes it hard to tell whether an identity is active, overprivileged, or even still needed. In practice, that fragmentation breaks correlation between inventory, access policy, and review outcomes. A service account can remain live in one system after the owning team has moved on in another. That is how governance gaps become operational exposure.
Practical implication: unify identity inventory and ownership across platforms before you try to optimise least privilege.
Transitive access abuse in cloud provider service agents
Transitive access abuse occurs when a seemingly benign intermediary identity can act with permissions that reach beyond what operators would expect from its surface role. In cloud environments, provider-managed service agents can sometimes perform privileged actions on behalf of workloads or services, which means the effective access path is longer than the visible identity chain. The risk is not that the agent looks obviously dangerous. The risk is that the trust relationship between services, permissions, and delegated actions is not fully visible to the team trying to govern it. That makes scope control and entitlement mapping essential.
Practical implication: map indirect access paths, not just directly assigned permissions, when reviewing cloud workload privilege.
Blast radius is now the primary control objective
Blast radius is the practical measure of how far an attacker or misuse event can move once an identity is abused. In sprawl-heavy environments, standing privilege and broad trust boundaries turn one compromised workload or service account into a route across multiple systems. JIT access, permission boundaries, and segmentation all aim to reduce the amount of access that exists continuously. The article’s key insight is that this is no longer a secondary hardening topic. It is the central design problem for cloud-to-workload identity governance because the identity layer has become the main path to lateral reach.
Practical implication: design workload identity controls around containment first, then measure whether they shrink reachable scope.
Threat narrative
Attacker objective: The objective is to turn an ordinary workload or cloud service identity into a wider access path for data access, manipulation, or exfiltration.
- Entry occurs through a service account, cloud provider agent, or API-bound workload identity that already has access to operational resources.
- Privilege is abused through transitive trust, overbroad permissions, or stale lifecycle state that outlives the original need.
- Impact follows when the abused identity is able to reach data or controls outside its intended boundary, increasing the blast radius of the compromise.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
Cloud-to-workload identity sprawl is really a lifecycle problem disguised as a visibility problem. The article shows that identities are proliferating across cloud, SaaS, and Kubernetes faster than most governance models can reconcile ownership and entitlement state. When a service account can outlive the team, system, or workload that created it, inventory alone cannot answer who should still have access. Practitioners need to treat identity lifecycle as the governing control plane, not an afterthought.
Transitive access is the governance gap that NHI programmes still underestimate. The article’s cloud-provider service-agent example shows that effective privilege is not always the same as assigned privilege. A benign intermediate identity can inherit enough trust to perform actions far beyond what its label suggests, which means entitlement review must follow delegation chains rather than account names. Security teams should rework their risk models around reachable privilege, not just direct grants.
Least privilege only works when entitlement boundaries are explicit across platforms. In a fragmented environment, one team’s cloud policy, another team’s Kubernetes role, and a third team’s SaaS control can each look compliant in isolation while collectively creating excessive access. That is why NHI governance now depends on cross-platform policy reconciliation, not isolated control checks. The practitioner conclusion is simple: if the boundary is not shared, least privilege is not actually defined.
Blast radius has become the decisive metric for NHI governance maturity. The roundtable’s emphasis on JIT access, permission boundaries, and segmentation points to a field-level shift away from static access assumptions. In modern cloud environments, the question is not whether every identity is perfectly clean. It is whether any one identity can move far enough to matter. Programs that cannot answer that question are still measuring exposure too late.
50-to-1 identity growth changes the governance equation, not just the workload. The scale signal in the article is important because it explains why manual review cadences and siloed ownership models stop working first in NHI environments. At that density, periodic access reviews cannot keep up with runtime change, so governance has to move toward continuous lifecycle control and containment-oriented policy. Practitioners should assume the old review rhythm will miss the fastest-growing part of the estate.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Cloud-to-workload sprawl forces identity teams to move from account counting to reachability control. The operational question is no longer how many non-human identities exist, but how much privilege each one can chain through delegation. That shift makes ownership, lifecycle, and blast-radius analysis the practical core of NHI governance.
Access reviews are weakest where identities change fastest. Service accounts, cloud agents, and workload credentials can be created, repurposed, or retired faster than review cycles can catch up. Programs that still depend on periodic certification without runtime containment will continue to miss the fastest-moving risk surface.
Blast radius control is the named concept that best captures this article’s direction. It describes the need to limit how far a compromised workload identity can move across cloud and SaaS boundaries, even when the identity itself appears legitimate. The governance implication is that containment must be measured alongside privilege, not after it.
For practitioners
- Map every workload identity to an owner and lifecycle state Build a single inventory that ties service accounts, API keys, cloud agents, and workload identities back to a human owner, system owner, and decommission date. Use that inventory to identify orphaned identities and accounts that no longer have a clear business purpose.
- Trace indirect access paths before tightening permissions Review cloud provider service agents, delegated roles, and chained access paths to see what actions an identity can perform indirectly. Prioritise identities whose effective permissions exceed the visible role assignment.
- Replace standing privilege with task-scoped access Use JIT access for workload identities where continuous privilege is not needed, and pair it with short approval windows and bounded permissions. The goal is to reduce the time an identity can be misused if it is compromised.
- Set containment boundaries for every high-value workload Define permission boundaries, segmentation rules, and resource scoping so a compromised identity cannot move freely across cloud and SaaS boundaries. Measure success by how much reachable scope each identity has, not by how many policies exist.
- Automate periodic recertification of service-account privilege Schedule access reviews for service accounts, cloud agents, and API-bound identities at a cadence that reflects how often workloads change. Include removal of stale roles, unused entitlements, and accounts attached to retired services.
Key takeaways
- Cloud-to-workload identity sprawl turns NHI governance into a lifecycle and delegation problem, not a simple inventory exercise.
- Fragmented control planes make it easy for overprivileged service accounts and cloud agents to hide in plain sight until abuse occurs.
- The most useful controls in this environment are ownership mapping, indirect-access review, JIT access, and containment boundaries.
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-05 — Overprivileged NHI | The article centres on service accounts and cloud agents carrying more access than they should. |
| NHI-07 — Long-Lived Secrets | The roundtable highlights stale service accounts and API keys that remain active beyond their purpose. | |
| NHI-03 — Vulnerable Third-Party NHI | Cloud-provider managed service agents create delegated trust paths that can be abused if not governed. | |
| Recommendation — Audit workload and service-account permissions against NHI-05 and reduce standing privilege wherever access exceeds need. Track stale workload secrets to NHI-07 and retire credentials that outlive the workload they support. Review delegated cloud identities under NHI-03 and limit what third-party or provider-managed agents can do. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about entitlement sprawl and access scope across platforms. |
| Recommendation — Apply PR.AA-05 to reconcile workload entitlements across cloud, SaaS, and Kubernetes environments. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The abuse pattern described leads from delegated identity exposure to cross-environment movement. |
| Recommendation — Map abuse of cloud identities to TA0006 and TA0008 to improve detection of indirect access paths. | ||
Key terms
- Cloud-to-workload identity sprawl: The spread of identity objects across cloud services, SaaS tools, and workloads in separate control planes. It creates governance gaps because ownership, entitlement state, and lifecycle decisions are no longer managed in one place, making access harder to review and contain.
- Transitive Access: Transitive access is indirect reach gained through chained systems, integrations, or delegated workflows rather than through explicit direct permissions. It is a common source of hidden risk for AI agents because one allowed connection can open pathways into other services and data stores.
- 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.
- Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
What's in the full article
P0 Security's full article covers the operational detail this post intentionally leaves for the source:
- The roundtable discussion with cloud security practitioners on identity management trends and governance challenges
- The full explanation of transitive access abuse in Google Cloud service agents
- Panel commentary on lifecycle management, least privilege, and blast-radius reduction for service accounts and API keys
- The complete set of best-practice recommendations discussed in the video
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 August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org