Legacy PAM cannot control cloud privilege sprawl in dynamic environments

At a glance

What this is: This is a Sonrai Security analysis of why cloud privilege is a permissions problem, not a traditional PAM problem, with the key finding that cloud environments now span massive, fast-changing permission sets.

Why it matters: IAM and NHI teams need to treat cloud privilege as a continuous governance issue because over-permissioned machine identities and AI agents widen attack paths faster than manual review can contain them.

By the numbers:

• Of those, 1,095 are privileged.
• 92% of identities holding these privileged permissions never use them.

👉 Read Sonrai Security's analysis of cloud privilege and legacy PAM limits

Context

Cloud privilege is the set of actions an identity can perform in a cloud environment, and it is governed by permissions rather than by a simple administrator login. That distinction matters for NHI governance because service accounts, workloads, pipelines, third-party integrations, and AI agents often carry the real operational power, while legacy PAM assumptions still focus on human sessions and vaults.

Sonrai Security's argument is that cloud environments change too quickly for static privilege controls to remain accurate. Permissions accumulate as identities proliferate, creating a wider attack surface and a governance gap that traditional PAM does not close. That starting position is common in mature cloud estates, not an edge case.

The practical issue for practitioners is not whether access exists, but whether each permission is still justified, observable, and bounded over time. In that sense, cloud privilege management is a lifecycle problem, not a one-time access control decision. The article reflects a typical cloud-native maturity challenge rather than an unusual configuration flaw.

Key questions

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

A: Security teams should govern cloud privilege at the permission layer, not just the login layer. That means inventorying what each non-human identity can do, removing unused access, enforcing task-scoped approvals, and reviewing entitlements continuously as workloads and integrations change. The goal is to keep privilege aligned to current function, not historical deployment decisions.

Q: When does just-in-time access reduce cloud risk?

A: Just-in-time access reduces cloud risk when standing privilege is the main problem and the baseline permissions are already tightly scoped. If the default role is overly broad, temporary access only shortens exposure time without fixing the entitlement model. Teams should use JIT after they have reduced excess privilege and clarified ownership.

Q: What is the difference between legacy PAM and cloud-native privilege control?

A: Legacy PAM focuses on protecting human sessions, vaults, and interactive admin access. Cloud-native privilege control focuses on what identities can do through permissions across humans, workloads, pipelines, third parties, and AI agents. In cloud estates, the second model is broader and more relevant because the real risk sits in entitlement design, not only in logins.

Q: Why do over-permissioned cloud identities create so much risk?

A: Over-permissioned identities create risk because an attacker only needs one useful permission to expand access, alter controls, or reach sensitive data. Even permissions that are rarely used still matter if they remain active and exploitable. That is why dormant privilege should be treated as attack surface, not as harmless slack.

Technical breakdown

Why permissions, not logins, define cloud privilege

In cloud platforms, privilege is expressed through permissions attached to identities, roles, and policies rather than through a single administrative account. That means risk can hide in narrow actions such as policy edits, key policy changes, or role assumptions that look routine in isolation but become dangerous when combined. For NHI governance, the important question is not who logged in, but what the identity can do across services, data, and control planes. Traditional PAM models built around vaulting and session control do not naturally inspect that permission graph.

Practical implication: Inventory privileged permissions directly and review the actions each NHI can perform, not just whether a login is protected.

How permission sprawl expands the NHI attack surface

Permission sprawl occurs when identities accumulate access faster than teams remove it, especially in environments with automation, third-party connections, and ephemeral workloads. Because cloud resources are dynamic, the privilege set can outgrow the business need without any visible change in user behaviour. That creates idle privilege, which is still exploitable even when it is rarely used. For NHI practitioners, the architecture problem is lifecycle drift: identities remain active, but their access no longer matches current function.

Practical implication: Use continuous entitlement review and remove unused privileges before they become standing attack paths.

What cloud-native privilege enforcement changes

Cloud-native privilege enforcement shifts control from session-centric monitoring to policy-based restriction at the permission layer. In practice, that means denying unnecessary privilege by default, then restoring access only when a task justifies it. This aligns with just-in-time access and zero standing privilege, but it only works if the policy engine can operate across every identity class, including workloads and AI agents. The main architectural gain is reduced blast radius without relying on proxies or manual ticket handling.

Practical implication: Design access policy around task-scoped permissions so privilege is granted only when the identity has a current, documented need.

Threat narrative

Attacker objective: The objective is to convert hidden cloud permissions into durable control over data, identity, or security controls.

1. Entry begins when an over-permissioned cloud identity, such as a service account or automation pipeline, is compromised or abused.
2. Escalation occurs when the attacker uses a privileged permission such as policy modification or key-policy rewriting to expand access.
3. Impact follows when the attacker turns idle, unused privilege into data exposure, infrastructure abuse, or persistent backdoor creation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• 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

Cloud privilege governance has become an NHI problem, not a PAM product problem. Legacy PAM was designed for human administrators and session control, while cloud estates now run on machine identities, role assumptions, and granular permissions. That mismatch leaves large portions of cloud access outside the control model most teams still rely on. Practitioners should treat privilege as a continuous identity governance issue across every non-human actor.

Idle privilege is the real cloud risk surface. When most privileged permissions are never used, the problem is not shortage of control but excess standing access. Unused privilege still creates a viable attack path because compromise only needs one exploitable permission, not a frequent one. Security teams should focus on eliminating dormant privilege before they try to perfect monitoring.

Ephemeral access only helps if the underlying permission model is accurate. Just-in-time access can reduce standing privilege, but it does not fix bad entitlement design, broad policy templates, or uncontrolled role inheritance. If the baseline permission set is too permissive, time-bounding the access window only limits exposure marginally. The practitioner priority is policy precision before access timing.

Cloud privilege is an identity blast radius issue. The danger is not merely that an identity exists, but that a single compromise can unlock a wide set of permissions across services and accounts. That is why cloud governance must account for permission edges, not just credential custody. Teams should measure and reduce blast radius, not just count identities.

Named concept: permission-level privilege debt. This article describes the accumulated risk of unused, over-broad cloud permissions that remain active long after the original business need has changed. Permission-level privilege debt builds quietly across humans and NHIs alike, and it becomes a compound risk during incidents and audits. Practitioners should treat debt reduction as a standing control objective.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• That gap aligns with the OWASP Agentic AI Top 10, which practitioners can use to map privilege abuse, tool misuse, and agent governance controls.

What this signals

With 70% of organisations granting AI systems more access than human employees, the governance problem is no longer theoretical. Cloud privilege controls now have to account for autonomous actors that inherit permissions faster than teams can review them, which is why policy precision must precede automation.

Permission-level privilege debt: the longer teams leave broad cloud permissions in place, the harder it becomes to prove least privilege during audit or incident response. The practical response is to combine lifecycle controls with Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs discipline, especially for offboarding and rotation.

This topic also tracks closely to the OWASP Top 10 for Agentic Applications 2026, because tool access and policy inheritance are becoming operational risk factors. Security programmes should prepare for more AI-driven change requests, not fewer, and should define approval paths before autonomous systems begin acting at scale.

For practitioners

• Map privileged permissions, not just privileged users Build an inventory of high-risk actions across cloud platforms and tie each one to the identities that can invoke it. Focus on service accounts, pipelines, third parties, and AI agents because those NHIs often carry the broadest operational access.
• Remove unused access on a continuous schedule Review permissions that have not been exercised and revoke them when there is no current operational justification. Pair the review with exception handling so teams can re-approve access only when the task truly requires it.
• Shift from session control to task-scoped policy Use just-in-time access and zero standing privilege for cloud identities where possible, then enforce the policy at the permission layer rather than through vaults and jump hosts. This is especially important for workloads that never log in.
• Prioritise NHI lifecycle governance for cloud credentials Set offboarding, rotation, and access review controls for machine identities with the same rigor you use for people. The goal is to keep permissions aligned to function as systems, pipelines, and agents change over time.

Key takeaways

• Cloud privilege is governed by permissions, so legacy PAM alone cannot contain the risk created by NHIs and AI agents.
• Unused and over-broad permissions matter because they expand attack paths even when they are rarely exercised.
• Practitioners should move toward continuous entitlement review, just-in-time access, and zero standing privilege for cloud identities.

Key terms

• Cloud Privilege: Cloud privilege is the set of actions an identity can perform through permissions in a cloud environment. It is defined by role assignments, policies, and inherited entitlements rather than by a single administrator account, which makes governance dependent on continuous review of effective access.
• Permission Sprawl: Permission sprawl is the accumulation of unnecessary or outdated access across identities over time. In cloud and NHI environments, it grows through automation, rapid deployment, and weak offboarding, leaving more standing privilege than the business actually needs.
• Standing Privilege: Standing privilege is access that remains active all the time instead of being granted for a specific task or window. It increases blast radius because compromise of the identity immediately exposes the permissions without requiring a fresh approval or temporary elevation.
• Just-in-Time Access: Just-in-time access is a control pattern that grants elevated permissions only when a specific task requires them and removes them afterward. For NHIs and cloud workloads, it reduces persistent exposure, but only if the underlying entitlement model is already narrow and well governed.

Deepen your knowledge

Cloud privilege governance and just-in-time access for NHIs are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to align cloud permissions with a similar governance model, it is worth exploring.

This post draws on content published by Sonrai Security: Cloud Privilege Is a Mess. Why Legacy PAM Can’t Fix It. Read the original.