Cloud PAM fails when teams JIT users instead of permissions

At a glance

What this is: This is a cloud PAM analysis arguing that just-in-time access breaks down when organisations JIT users instead of permissions.

Why it matters: It matters because IAM, PAM, and cloud security teams need to govern permission scope and expiry across human, workload, and third-party access rather than rely on account-level controls.

By the numbers:

• Using least-privileged AI access cut incident rates to 17%, versus 76% for over-privileged systems.

👉 Read Sonrai Security's analysis of cloud PAM and permission-based JIT

Context

Cloud privileged access management fails when organisations optimise the request flow but leave the underlying permissions model unchanged. In practice, that means teams can make access feel temporary while roles, group membership, and inherited permissions remain persistent.

The article’s core claim is that identity governance in cloud environments must operate at the permission layer, not the account layer. That shift matters across human administrators, service accounts, and other non-human identities because blast radius is determined by what an identity can do, not by how quickly it was approved.

Key questions

Q: How should security teams implement just-in-time access in cloud environments?

A: Security teams should implement JIT at the permission layer, not the account layer. That means granting only the specific cloud actions needed for the task, enforcing automatic expiry, and validating that revocation removes effective access across roles, groups, and inherited policies. If the workflow leaves standing privilege behind, it is not true JIT.

Q: Why does legacy PAM fail for cloud identity governance?

A: Legacy PAM fails because it was built for static servers, human administrators, and session brokering. Cloud identities operate through policies, roles, tags, and API permissions, so recording access is not the same as controlling it. The gap is structural: the control plane, not the session, defines real privilege.

Q: What breaks when organisations JIT users instead of permissions?

A: When organisations JIT users instead of permissions, the access window may shrink but the effective privilege often remains broad. Role membership, group sync timing, and shared-account patterns can preserve access beyond the intended task. That creates standing privilege with a temporary wrapper, which still allows escalation and persistence.

Q: Who is accountable when cloud access expires on paper but persists in practice?

A: Accountability sits with the team that owns policy enforcement across the cloud control plane, not only the team that approves access. If expiry is handled in tickets, directory sync, or manual follow-up, the organisation has not actually governed revocation. Frameworks such as NIST CSF and ZTA expect effective control, not paperwork.

Technical breakdown

Why cloud JIT fails at the account layer

Cloud JIT breaks when access is granted through role switching, shared accounts, or directory group changes while the effective permissions remain broad. In that model, the account may be temporary, but the authorisation boundary is not. Expiration also fails when directory sync timing, ticket queues, or break-glass exceptions delay revocation long enough for standing privilege to reappear. The result is not true ephemeral access. It is time-bounded workflow around persistent privilege.

Practical implication: move controls to the permission layer and verify that expiry removes effective access, not just the session wrapper.

Why legacy PAM misses cloud permission risk

Legacy PAM was built around static servers, human administrators, and session brokering. Cloud identity is different because access is expressed through policies, roles, service boundaries, tags, and API-level permissions across thousands of identities. That means recording a privileged session does not prevent misuse when valid credentials already carry excessive rights. The architecture mismatch is structural, not operational. Cloud PAM must understand policy inheritance and API action scope, not just vaulting and checkout workflows.

Practical implication: assess whether your PAM stack can govern cloud-native permissions directly, rather than only broker credentials and sessions.

Why permission scope is the real control variable

The central technical variable in cloud least privilege is not who requested access, but which actions the identity can perform once granted. With expansive permission sets, many identities hold rights they never use, which creates standing privilege even when access appears tightly managed. In cloud environments, risk concentrates in unused but powerful permissions because attackers and insiders only need one high-impact API action to change the environment. Permissions are therefore the durable control surface for both prevention and containment.

Practical implication: inventory high-risk API permissions and prioritise controls that narrow action scope before you optimise approval workflows.

Threat narrative

Attacker objective: The objective is to turn valid but over-broad cloud access into durable control over production infrastructure and recovery paths.

1. Entry occurs when an attacker or operator gains valid cloud credentials that already map to excessive permissions, so the initial access is legitimate rather than forced through a perimeter bypass.
2. Escalation happens when broad roles, group membership, or role chaining expose more effective permissions than the operator should have, allowing privileged API actions without additional approval.
3. Impact follows when those permissions are used to alter production systems, persist access, or create drift that survives the original access window.

Breaches seen in the wild

• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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 PAM has a permissions problem, not a user problem. The article is correct that shifting access requests earlier does not change the underlying control point. Cloud least privilege fails when organisations treat account lifecycle as the security boundary while permissions remain broad and reusable. The practitioner implication is that governance must follow the permission stack, not the approval workflow.

Standing privilege is often hidden inside apparently temporary controls. Role switching, group membership, directory sync timing, and break-glass exceptions can all preserve effective access after the ticket closes. That is a cloud-specific governance failure because the identity looks governed while the permission graph still carries blast radius. Practitioners should assume that visible expiry does not equal effective revocation.

Blast radius is defined by permission scope, not access duration. In cloud environments, a short session can still be high-risk if it includes broad API actions, service control permissions, or cross-account reach. This is why permission granularity matters more than the ceremony around granting access. Security leaders should measure how much damage a valid identity can do in one granted window, not just how often access is reissued.

Legacy PAM assumptions fail when cloud identity is policy-native. The model that works for static servers, human admins, and brokered sessions does not generalise to environments where identities act through policies, tags, and service boundaries. The failure is conceptual: old PAM presumes privilege is attached to a session, while cloud privilege is embedded in the control plane. Teams need to govern the control plane directly, not adapt server-era checks to it.

Permissions on demand is the right named concept for cloud least privilege. The article surfaces a model where access should be provisioned at the permission layer, enforced centrally, and removed automatically when the task ends. That phrase captures the governance shift better than JIT alone because it moves the unit of control from user checkout to effective action scope. Practitioners should rebuild policy around permissions, not identities.

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 makes the next step clear: OWASP Agentic AI Top 10 shows why permission scope, tool access, and runtime control now need to be treated as one governance problem.

What this signals

Permissions-on-demand is becoming the only defensible cloud PAM model. As cloud estates keep expanding, teams can no longer assume that a temporary account or checkout workflow equals temporary privilege. The governance task is to prove that access disappears at the control plane when the task ends, not after an operational delay.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey, the same control assumption is failing across both cloud operations and autonomous systems. That is a warning for IAM teams that user-centric expiry logic will not contain machine-speed privilege.

Permission stack governance: the next phase of cloud identity work is about governing action scope across accounts, roles, services, and policy boundaries as one system. Teams that keep treating PAM as session handling will miss the point where cloud risk actually accumulates.

For practitioners

• Inventory effective cloud permissions, not just accounts Map the actions each identity can actually perform across roles, permission sets, group membership, and inherited policies. Prioritise high-risk API actions that create persistence, privilege escalation, or data exposure.
• Validate that expiry removes effective access Test whether role switching, directory sync delay, or break-glass workflows leave residual access after the intended window closes. Confirm that revocation is enforced in the cloud control plane, not only in the ticketing process.
• Replace account-centric JIT with permission-centric controls Design approval and enforcement around specific permissions and service actions, especially in environments where AWS-style permission sprawl creates hidden standing privilege. Use native cloud policy constructs to narrow action scope.
• Review PAM coverage for cloud-native permission graphs Check whether your PAM platform can govern API-level activity, role chaining, and organisation-wide policy boundaries. If it only brokers sessions or vaults credentials, it will miss the control plane where cloud risk lives.

Key takeaways

• Cloud PAM fails when organisations time-box access without truly narrowing the permissions that make the access dangerous.
• The article’s evidence shows that cloud privilege problems persist because effective access is still shaped by roles, groups, and policy inheritance, not by the ticket that approved them.
• Practitioners should redesign controls around permission scope and control-plane revocation if they want JIT to be more than a temporary wrapper around standing privilege.

Key terms

• Cloud Privileged Access Management: Cloud Privileged Access Management is the discipline of controlling elevated access in cloud environments through native policies, roles, and service boundaries. It differs from legacy PAM because the real control point is the permission graph, not a session vault or checkout workflow.
• Standing Privilege: Standing privilege is access that remains effective beyond the immediate task, even when it appears to have been granted temporarily. In cloud environments it often hides inside role membership, inherited permissions, and group sync timing, creating persistent blast radius under a temporary wrapper.
• Permission Layer: The permission layer is the level at which an identity can actually perform actions, regardless of how the access was requested or approved. For cloud governance, this is where teams must enforce scope, expiry, and revocation because the account itself is not the true boundary of risk.
• Blast Radius: Blast radius is the amount of damage an identity can cause if its credentials are misused or overpowered. In cloud identity governance, it is determined by the API actions, service reach, and policy inheritance attached to the identity, not simply by how long the access lasted.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Shift Left Is Dead for Cloud PAM. Read the original.