Next-gen PAM for cloud security is shifting identity control

At a glance

What this is: This is an analysis of why cloud PAM is moving away from proxy-based SSH control toward agentless, cloud-native governance across servers, services, and non-human identities.

Why it matters: It matters because IAM and PAM teams now have to govern SSH, cloud APIs, service accounts, and ephemeral access together rather than treating each as a separate control problem.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read P0 Security's analysis of next-gen PAM for cloud security

Context

Cloud PAM is no longer just about brokering SSH into virtual machines. In practice, enterprises now need to govern privileged access across cloud APIs, service accounts, Kubernetes, and the human operators who still need emergency access into production systems.

The core governance gap is that proxy-based PAM was designed for network paths, not for cloud-native identity planes. That leaves security teams trying to force bastion workflows, endpoint agents, and static keys into environments where access is distributed, ephemeral, and increasingly tied to non-human identities.

For teams managing NHI, human admin access, and cloud operations together, the issue is not whether access can be proxied. The real question is whether the PAM model can see, scope, and revoke privilege at the identity layer across every system that now matters.

Key questions

Q: What breaks when PAM is built mainly around SSH proxies in cloud environments?

A: Proxy-centric PAM breaks when access is no longer concentrated in a single network path. Cloud operations now depend on native identity planes, service accounts, cloud APIs, and ephemeral workflows, so a bastion can broker SSH without actually governing the broader privilege surface. Teams then lose visibility into who can act, where, and for how long.

Q: Why do standing credentials create outsized risk in cloud and SaaS environments?

A: Standing credentials turn a single successful compromise into reusable enterprise reach. They outlive the task that justified them, can be copied or chained into other systems, and often bypass the review cycles that were designed for slower, human-paced access governance.

Q: How do organisations know whether cloud PAM is actually reducing risk?

A: Look for shrinking credential lifetime, fewer standing entitlements, faster revocation, and better audit visibility across both human and non-human identities. If access still depends on static secrets or slow approval chains, the control is present in name only. Effective cloud PAM produces measurable reduction in privilege duration and exposure.

Q: Who is accountable when a cloud privileged account is misused?

A: Accountability should sit with the business owner of the privilege, the platform team that granted it and the governance function that approves its persistence. In practice, shared accountability fails when service accounts and administrative roles are left without clear ownership. Frameworks such as the NIST Cybersecurity Framework 2.0 support clearer access governance and review discipline.

Technical breakdown

Why proxy-based PAM breaks in cloud-native environments

Proxy or bastion PAM inserts a mediation layer between the user and the target system, which works tolerably well for SSH into a small set of servers. In cloud environments, that model becomes brittle because privilege is no longer concentrated in one protocol. Access now spans AWS IAM roles, GCP service accounts, Azure-native controls, Kubernetes, and ephemeral developer workflows. Once the control plane is split across services, a single proxy no longer represents the full trust boundary.

Practical implication: treat proxy-only PAM as incomplete for cloud identity governance and map every access path to the native control it actually uses.

How agentless, cloud-native PAM changes the control point

Agentless PAM shifts enforcement closer to the cloud provider’s own identity APIs and managed access mechanisms, rather than depending on an always-on proxy or instance agent. That matters because privilege can then be granted, observed, and revoked using the cloud platform’s own control plane, which is where modern access actually lives. For SSH, services such as AWS SSM, GCP IAP, and Azure Bastion can replace traditional jump-host dependency while preserving auditable access paths.

Practical implication: prefer native cloud access paths where possible so access governance follows the identity system rather than an external relay.

Why just-in-time access matters more than standing privileged access

Just-in-time access removes the assumption that privileged access should exist before the task is known. In cloud operations, that is critical because standing access becomes a durable failure mode when developers, operators, and service identities accumulate broad permissions over time. JIT changes the governance model from persistent entitlement to ephemeral permission tied to a request, which reduces the window in which stolen credentials or misused admin rights can be exploited.

Practical implication: use JIT as the default pattern for elevated cloud access and reserve standing privilege only for tightly justified break-glass cases.

Threat narrative

Attacker objective: The objective is to turn durable privileged access into broad control over cloud infrastructure, customer environments, or sensitive data paths.

1. Entry begins when attackers or over-burdened insiders obtain long-lived SSH keys, overprivileged cloud roles, or other standing credentials tied to cloud operations.
2. Escalation follows when those credentials allow sudo use, lateral movement into cloud services, or abuse of IAM roles, service accounts, and Kubernetes permissions that were never meant to persist.
3. Impact is achieved when cloud infrastructure, customer environments, or sensitive data stores are altered, exfiltrated, or left exposed by privilege that outlasted the task it was meant to support.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Proxy-based PAM is an identity control for yesterday’s cloud. It was built for a world where privileged access meant a person connecting through a network chokepoint to a small number of servers. That assumption breaks when privilege lives across cloud APIs, service accounts, Kubernetes, and temporary workflows. The implication is that PAM strategy now has to follow the identity plane, not the network path.

Standing privileged access remains the core failure mode in cloud operations. The article’s use case shows why persistent SSH keys, reusable admin access, and bastion-dependent workflows keep surviving inside modern infrastructure teams. Those patterns are easy to inherit and hard to retire. The practitioner conclusion is that privilege duration, not just privilege scope, has become the control variable that matters most.

Lifecycle governance for cloud access is now a cross-actor problem. The same JML, recertification, and offboarding discipline must apply differently to human admins, cloud roles, and non-human identities. A human operator can be challenged through MFA or break-glass review, but a cloud role or service account needs lifecycle controls that are native to its execution context. The programme implication is that one PAM operating model cannot govern all three actor types well unless it differentiates them explicitly.

Cloud-native PAM is becoming a governance layer, not just an access broker. The useful question is no longer whether a tool can open an SSH session, but whether it can inventory identities, identify overprivileged access, and automate remediation across environments. That shifts PAM closer to IGA and NHI governance. Security teams should expect tighter convergence between privileged access, cloud identity discovery, and workload governance.

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 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• The access-governance problem is already broad enough that the NHI Lifecycle Management Guide is becoming a practical reference for provisioning, rotation, and offboarding across actor types.

What this signals

Standing privilege is becoming the real cloud governance fault line. As enterprises spread access across SSH, cloud APIs, and non-human identities, the old assumption that privilege can be safely brokered once and reused many times no longer holds. Teams should expect PAM, NHI governance, and cloud IAM to converge around lifecycle control rather than session brokerage.

Identity blast radius: the useful measure is no longer whether a user can authenticate, but how far that identity can move before access is revoked. That makes cloud inventory, access review, and offboarding operational controls, not administrative hygiene. The programme that cannot answer where privilege persists is already behind.

The pattern aligns closely with OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0, especially where teams need to connect identification, protection, and recovery for cloud-native privilege. Security leaders should prepare for tighter evidence demands around who had access, why it existed, and when it was removed.

For practitioners

• Audit standing privileged access across cloud and SSH paths Inventory every long-lived SSH key, cloud admin role, and service account that can reach production systems. Classify each by business necessity, task scope, and revocation path so you can see where privilege persists longer than the work requires.
• Replace proxy dependence with native cloud access paths Where the platform supports it, move SSH access to native services such as AWS SSM, GCP IAP, or Azure Bastion so access is mediated by the cloud control plane rather than an external relay.
• Enforce just-in-time access for elevated operations Require time-bound, request-scoped elevation for administrator activity and keep standing privilege limited to documented break-glass use cases with explicit approval and post-use review.
• Govern non-human identities alongside human admins Include AWS IAM roles, GCP service accounts, and other machine identities in the same access review and offboarding motion as human privileged users so cloud governance is not split by actor type.
• Measure where cloud privilege outlives the task Track how often elevated access is still present after the operational need has ended, then use that signal to target recertification, credential rotation, and access removal workflows.

Key takeaways

• Legacy PAM models built around proxies and bastions do not fully govern cloud privilege, because modern access now spans APIs, service accounts, and native platform controls.
• Standing credentials remain the most consequential failure mode, because risk rises whenever access outlives the task that justified it.
• Cloud security teams should shift PAM toward native, just-in-time, lifecycle-governed access that covers both human administrators and non-human identities.

Key terms

• PAM — Privileged Access Management: Solutions that control, monitor, and audit privileged access for both human and non-human identities. Traditional PAM tools are being extended to cover machine identities, service accounts, and agentic AI workloads.
• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.

What's in the full article

P0 Security's full article covers the operational detail this post intentionally leaves for the source:

• A closer look at the proxy-based deployment model and why it creates operational friction at scale.
• Specific cloud access patterns for AWS, GCP, and Azure that show how next-gen PAM fits into real environments.
• The vendor's own comparison points for SSH governance, JIT workflows, and non-human identity coverage.
• Implementation context for teams evaluating whether their current PAM architecture can support cloud-native access at all.

👉 P0 Security's full article covers the cloud access model, NHI governance scope, and operational trade-offs in more detail.

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 or PAM programme, it is worth exploring.