Cloud permissions are becoming the real PAM battleground in DevOps

At a glance

What this is: This is Sonrai Security's account of why cloud permissions have become the main PAM battleground, alongside adoption growth and product milestones tied to default-deny and JIT control at the permission layer.

Why it matters: IAM and PAM teams need to treat cloud entitlements as the control plane for human, machine, and AI access, because legacy privilege assumptions do not map cleanly to DevOps velocity or cloud-scale delegation.

By the numbers:

• Sonrai Security says it saw 4x year-over-year ARR growth in 2025.
• Sonrai Security says it saw 220% growth in customers in 2025.
• Sonrai Security says 60% of customers expanded Cloud Permissions Firewall deployments.
• Sonrai Security says independent research showed the Cloud Permissions Firewall preventatively blocked 16 of 16 real AWS privilege-escalation attack paths.

Context

Cloud permissions are the entitlements that determine what a human, workload, service, or agent can do in a cloud environment. When those permissions are granted broadly, left standing, or shared across changing workloads, the result is an access layer that becomes hard to reason about and easy to abuse.

Sonrai Security's news argues that legacy PAM models were built for static systems and human administrators, while DevOps clouds now depend on fast-moving machine and AI-driven access patterns. The issue is not just who gets access, but how quickly it appears, how long it persists, and whether every change is actually governed.

The article also places third-party access in the same governance bucket as internal privilege, which reflects the reality that cloud permission sprawl rarely stays inside one team or one trust boundary.

Key questions

Q: What breaks when cloud PAM is still managed with static tools and manual processes?

A: Static tools struggle to keep pace with cloud systems that scale up and down continuously. That gap creates poor visibility into overprovisioning, weak certification of least privilege, and more manual work for teams trying to track access risk. The result is often stalled PAM maturity, slower response to change, and higher exposure to breaches, audit failure, and policy drift.

Q: Why do standing privileges in cloud infrastructure create outsized risk for engineering teams?

A: Standing privileges increase the blast radius of both human error and account compromise because access remains available after the task is complete. In cloud environments, that makes customer environments, sensitive policies, and managed resources harder to protect. Teams should prefer ephemeral access, explicit approvals, and fast de-provisioning so access exists only when a business need is active.

Q: What are the signs that cloud resource governance is failing?

A: Common signs include unexpected cost spikes, resources being enlarged without review, new assets appearing outside approved procedures, and engineers not knowing the financial impact of what they deploy. If teams cannot explain what should be running or in what configuration, governance is already weak. These symptoms usually show up before the monthly bill makes the problem obvious.

Q: Should organisations govern third-party and AI access the same way as internal cloud privilege?

A: Yes, because the risk comes from what the identity can reach, not whether it is human, vendor, workload, or agentic. Different identity classes may request access differently, but the governance question is the same: who approved it, what it can touch, and when it should expire. Separate models create blind spots.

Technical breakdown

Why cloud permissions are a PAM control plane problem

Cloud PAM shifts the control point from a login event to the permission layer itself. In DevOps environments, access is often mediated by roles, policies, ephemeral sessions, and delegated identities rather than a single privileged account. That makes entitlement scope, approval workflow, and logging more important than a traditional admin-session model. When permissions are the thing being exercised, privilege is not just who can sign in, but what actions can be taken across cloud resources, pipelines, and data planes. This is why default-deny and just-in-time access are positioned as cloud governance controls rather than convenience features.

Practical implication: Map privileged access controls to cloud entitlements, not just admin accounts, so policy follows the resource and action being authorised.

How just-in-time access changes standing privilege in cloud operations

Just-in-time access means privilege is issued for a bounded task window instead of remaining present by default. In cloud environments, that matters because broad standing access can be copied across roles, reused by automation, or inherited by downstream tools long after the original reason for access disappears. The control value comes from shrinking the time during which an attacker or misconfigured workflow can use the permission, while also creating an approval and audit event for each privilege grant. This is especially important where DevOps teams need speed but still cannot tolerate always-on administrative scope.

Practical implication: Replace persistent cloud privilege with task-scoped grants wherever operationally possible, then log each issuance and approval.

Why third-party and AI-driven access widen the cloud permission blast radius

Third-party access and AI-driven workflows expand the number of identities that can reach cloud resources without necessarily fitting a human-admin model. That creates a wider blast radius when permissions are excessive, because external users, machine identities, and AI agents may all inherit or request access in different ways. The governance challenge is consistency: the same resource may be reachable through a portal user, a workload identity, a delegated vendor account, or an agentic workflow. Without unified permission governance, each access path becomes a separate control exception, and the environment drifts away from least privilege.

Practical implication: Inventory every non-human and third-party access path to cloud resources and govern them under the same permission review standard.

NHI Mgmt Group analysis

Cloud permissions are becoming the practical boundary of privileged access. Traditional PAM was designed around human administrators and discrete elevated sessions, but cloud operations distribute privilege into policies, roles, tokens, and delegated paths. That makes the permission layer the real control surface for DevOps security, not the login prompt. Practitioners should treat cloud entitlements as the privileged asset.

Default-deny and JIT only matter if they are enforced at the entitlement layer. A task-scoped approval is useful only when the permission cannot silently persist elsewhere in the cloud stack. Cloud-scale governance fails when teams secure the session but leave the role, policy, or inherited permission untouched. The named concept here is permission-layer privilege drift: access appears controlled while the underlying entitlement remains broad.

Third-party access belongs in the same governance model as internal cloud privilege. Vendor access, workload identities, and AI-assisted operations all expand the same attack surface when the permission model is inconsistent. A cloud programme that separates human PAM from machine and external access is already accepting fragmented governance. The practical conclusion is that permission review must span every identity type reaching cloud resources.

Agentic AI makes cloud PAM assumptions less stable, not more automated. An AI agent can request, combine, and act on permissions inside workflows that were originally designed for human review cadence. That does not make the problem purely agentic, but it does mean cloud privilege can no longer be assumed to follow a stable operator model. The implication is that cloud PAM must be evaluated against runtime behaviour, not just identity class.

The market is moving toward permission governance as the organising principle for cloud identity security. When vendors frame cloud PAM around default-deny, JIT, and cross-identity control, they are signalling that entitlement governance is overtaking account-centric access control. For practitioners, that validates a shift already underway in cloud security architecture. The question is no longer whether to govern permissions, but how broadly to extend that governance across humans, workloads, third parties, and AI-enabled operations.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Permission-layer governance is becoming the new control boundary for cloud PAM. Teams that still think in terms of privileged accounts will miss the real exposure, which sits in roles, policies, and delegated access paths. The programme-level shift is to govern the entitlement itself, not just the session that uses it.

Identity blast radius is now a cloud design problem. When third parties, workloads, and AI-enabled workflows all share the same resource plane, overly broad permissions turn each access path into a multiplication point for risk. That means entitlement scoping is no longer an optimisation task, but a core containment control.

Just-in-time controls matter only when they are attached to the exact permission being exercised. A task approval that leaves broader access intact does not meaningfully reduce exposure. For practitioners, the test is whether the permission disappears when the task does, not whether the workflow feels controlled.

For practitioners

• Map privileged cloud access to entitlement paths Identify which cloud roles, policies, and delegated permissions actually confer administrative reach, then classify them as privileged assets for review and approval.
• Replace standing cloud privilege with task-scoped grants Use just-in-time access for elevated cloud actions so approvals are tied to the task rather than permanently attached to the identity.
• Extend governance to third-party access paths Bring vendor users, contractors, and external integrators into the same permission review and logging process used for internal cloud access.
• Review AI-assisted access against the same cloud policy Check whether agentic workflows can request or reuse cloud permissions outside the intended approval path, then bound those paths explicitly.
• Audit for permission-layer blast radius Look for roles or policies that can still reach data, keys, or infrastructure after the original reason for access has passed.

Key takeaways

• Cloud PAM is shifting from account-centric thinking to permission-centric governance because cloud privilege now lives in roles, policies, and delegated access paths.
• The article's evidence points to strong market demand for controls that reduce standing privilege without slowing DevOps, especially where machine and third-party access are involved.
• Practitioners should focus on entitlement scope, task-scoped approvals, and consistent oversight across human and non-human access paths.

Key terms

• Cloud Privileged Access Management: Cloud Privileged Access Management is the discipline of discovering and controlling identities that can make high-impact changes in cloud environments. It covers human and non-human identities alike, with continuous enforcement of least privilege, task-scoped access, and lifecycle ownership across accounts, roles, and automation.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.