Cloud permissions are becoming the real PAM battleground in DevOps

At a glance

What this is: This is Sonrai Security’s year-end growth update, and its key finding is that enterprises are adopting cloud permissions controls as a distinct PAM layer for human, machine, and AI identities.

Why it matters: It matters because IAM and PAM teams are being forced to govern cloud permissions as a first-class attack surface, not as an extension of legacy server-era privilege models.

By the numbers:

• Sonrai Security reported 4x year-over-year ARR growth, 220% customer growth, and 60% of customers expanded Cloud Permissions Firewall deployments in 2025.
• Sonrai Security said its Cloud Permissions Firewall preventatively blocked 16 of 16 real AWS privilege-escalation attack paths in independent research.

👉 Read Sonrai Security’s update on cloud permissions firewall adoption and cloud PAM growth

Context

Cloud permissions are no longer a back-end administration issue. In cloud environments, the permission layer often determines whether a compromised identity can move from routine access to meaningful impact, which is why cloud privileged access management is now a governance problem for IAM, PAM, and cloud security teams together.

Sonrai Security’s update argues that legacy PAM was built for static systems and human administrators, while modern cloud operations involve human, machine, and AI identities acting at scale. That is the central gap this post addresses: controlling privilege without slowing DevOps or treating cloud access as if it were a server cabinet problem.

Key questions

Q: How should security teams govern cloud privileged access in DevOps environments?

A: Security teams should govern cloud privileged access at the permission layer, not only at login or session time. The practical model is default-deny, just-in-time approval, and tight scope for the smallest set of actions needed. That approach reduces standing privilege while preserving operational continuity for DevOps and platform engineering teams.

Q: Why do cloud permissions create more risk than traditional server-era PAM models?

A: Cloud permissions create more risk because they can authorize identity creation, policy changes, data access, and service deployment across highly dynamic environments. Traditional PAM assumed stable systems and bounded admin sessions. Cloud IAM must now control blast radius created by permissions that can be reused, chained, or expanded quickly.

Q: What breaks when standing privilege remains in cloud environments?

A: Standing privilege breaks the assumption that access is only used when needed and only for a narrow task. In cloud environments, persistent permissions give attackers and overextended operators a larger window to escalate, pivot, or create new access paths. The result is not just excess privilege, but excess reach.

Q: Who should be accountable for cloud PAM when human, machine, and AI identities all have access?

A: Accountability should sit with the identity and cloud control owners who define permissions, approval policy, and revocation rules across all actor types. Human users, service accounts, and AI-driven operational identities should not be governed by separate privilege logic unless their risk profiles are explicitly different.

Technical breakdown

Why cloud permissions now function as the attack surface

In cloud architectures, permissions are not just administrative settings. They define which identities can enumerate resources, create keys, spin up services, access data, and alter guardrails. That makes permission sprawl a practical risk surface, especially when human operators, service accounts, and AI-assisted workflows all inherit different forms of access. A cloud PAM layer attempts to govern privilege at the permission boundary rather than only at the login or session boundary. The architectural shift is from static entitlement to controlled, scoped execution.

Practical implication: review cloud permissions as an attack surface in their own right, not only as an access control by-product.

How default-deny and just-in-time access change cloud PAM

Default-deny means access is blocked unless explicitly approved, while just-in-time access grants privilege only when needed and for the specific task. In cloud settings, that combination is meant to remove standing privilege without forcing teams into manual bottlenecks. The operational value depends on whether approvals, logging, and scope enforcement occur at the permission layer rather than as a separate after-the-fact review process. If implemented well, the identity system constrains what an identity can do before the action happens, not after.

Practical implication: map high-risk cloud permissions to JIT approval flows and confirm the control is enforced at the permission layer.

Cloud PAM across human, machine, and AI identities

The article frames cloud PAM as relevant to human users, machine identities, and AI identities because all three can hold permissions that create blast radius. That matters because the governance problem is no longer limited to a privileged human administrator. Service accounts, automation, and AI-assisted operators can all accumulate access that persists longer than the task that required it. Once those identities are treated as first-class actors, the control model has to address lifecycle, approval, and scope in a consistent way across identity types.

Practical implication: build one permission governance model that spans humans, workloads, and AI-driven operational identities.

NHI Mgmt Group analysis

Cloud permissions have become the control plane that legacy PAM never covered. Sonrai Security’s update reflects a broader truth: access in cloud environments is no longer concentrated in a few admin sessions, but distributed across permissions attached to users, workloads, and automation. Legacy PAM was designed around human privileged logins and finite server access, not dynamic cloud permissioning. The practitioner implication is that permission governance now sits at the center of cloud identity security.

Cloud PAM is increasingly a governance model for blast-radius reduction, not just privilege reduction. The article’s strongest signal is not feature growth but market demand for controlling where a granted permission can lead. In cloud environments, one over-scoped role can expose data, create new identities, or enable follow-on abuse at machine speed. Practitioners should treat permission scope as the primary blast-radius variable in cloud IAM and PAM design.

Human, machine, and AI identities cannot be governed with separate privilege assumptions. Sonrai Security explicitly positions its Cloud Permissions Firewall across all three identity classes, which is directionally correct for cloud operations. The governance challenge is that the same permission may be safe for one actor type and excessive for another. The implication is that identity programmes need actor-aware privilege rules rather than one-size-fits-all entitlement models.

Default-deny at the permission layer is the right response to cloud-scale privilege accumulation. The reason this matters is that approval and logging after the fact do not reduce exposure if standing access already exists. Cloud teams need a model that combines scope restriction, task-bound approval, and auditability before actions are executed. The practitioner conclusion is simple: if permissions remain persistent by default, cloud PAM is still incomplete.

Cloud permissions governance is now converging with agentic operational models. The mention of AI agent security and agentic AI consulting is not incidental, because cloud environments increasingly include software actors that make independent access decisions. That pushes identity governance toward runtime control rather than static assignment. Practitioners should assume the cloud permission layer will be asked to govern both traditional workloads and more autonomous systems.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
• From our research: 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, according to the 2026 Infrastructure Identity Survey.
• For a deeper framework view, see Ultimate Guide to NHIs for lifecycle, visibility, and privilege governance across machine identities and agents.

What this signals

Cloud PAM is moving from a privileged-admin problem to an actor-aware governance problem. With 70% of organisations already granting AI systems more access than they would give a human employee performing the same job, the line between workload governance and identity governance is collapsing. Teams that still treat cloud permissions as static entitlements will struggle to keep up with this shift, especially as AI systems move deeper into operational control.

Permission scope is becoming the practical measure of identity programme maturity. The signal to watch is not whether a team has PAM in name, but whether it can constrain reach before access is used. The 4.5x incident gap between least-privileged and over-privileged AI systems shows that access scope is now an outcome metric, not just a policy choice.

Cloud identity programmes need a named control concept: permission-layer governance. That means the control objective is not only to approve access, but to control what the permission can do once granted. Practitioners should align cloud IAM, PAM, and workload identity reviews so that human and non-human privilege are evaluated under the same blast-radius lens.

For practitioners

• Inventory high-risk cloud permissions by actor type Separate permissions held by humans, service accounts, automation, and AI-assisted workflows so you can see where standing access exists and where task-bound access is missing.
• Move privileged cloud access to task-scoped approval Use just-in-time approval for sensitive cloud actions and enforce the grant at the permission layer, not only through post-access review or ticketing.
• Prioritise permission scopes that can create new blast radius Focus first on roles that can create identities, alter policies, read secrets, or expand access paths, because those permissions turn small errors into large incidents.
• Align cloud PAM with workload and AI identity lifecycle Apply the same offboarding, scope review, and revocation discipline to non-human and AI-driven identities that you already expect for human privileged users.

Key takeaways

• Cloud permissions are now a primary identity control surface, and legacy PAM models do not fully address that reality.
• Sonrai Security’s reported growth and customer expansion indicate that organisations are buying cloud permission controls to reduce standing privilege and constrain blast radius.
• IAM and PAM teams should move toward actor-aware, permission-layer governance that covers humans, workloads, and AI-driven identities together.

Key terms

• Cloud Permissions Firewall: A cloud privilege control layer that governs access at the permission level rather than only at login or session time. It is designed to reduce standing privilege, limit blast radius, and make high-risk actions explicitly approved and logged before they occur.
• Just-in-time Access: A temporary access pattern that grants privilege only when a task needs it and removes it when the task is complete. In cloud environments, JIT is most effective when it is enforced at the permission boundary and tied to a specific action or approval event.
• Default-deny: An access model where nothing is allowed unless it has been explicitly approved. For cloud identities, default-deny is a practical way to suppress accidental overexposure and ensure that permissions exist only when a workflow genuinely requires them.
• Blast Radius: The amount of damage an identity can cause if it is overprivileged, compromised, or misused. In cloud IAM, blast radius is shaped by what a permission can touch, create, alter, or expose once access has been granted.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: Sonrai closes 2025 with 4x ARR growth as Cloud Permissions Firewall adoption surges. Read the original.