PAM for cloud environments is being reshaped by NHI sprawl

At a glance

What this is: This is a cloud PAM analysis showing why static, human-centric privilege controls fail when access is spread across ephemeral infrastructure and non-human identities.

Why it matters: It matters because IAM teams have to govern privileged access across humans, workloads, and AI systems without relying on review cycles or credential lifetimes that no longer match how cloud systems operate.

By the numbers:

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

👉 Read Infisical's analysis of PAM for AWS, Azure, GCP, and multi-cloud

Context

Cloud privileged access management now has to deal with ephemeral infrastructure, non-human identities, and access paths that are created and destroyed faster than manual review cycles can keep up. The primary problem is not just volume, but the mismatch between static privilege governance and short-lived cloud execution.

That mismatch matters across AWS, Azure, and GCP because service accounts, workloads, pipelines, and AI-driven infrastructure actions all sit inside the privileged access surface. A cloud PAM programme that still assumes fixed servers and stable endpoints will miss where privilege actually lives and how quickly it changes.

Key questions

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

A: Start by making privilege task-scoped, time-bound, and automatically revoked when the request ends. Cloud JIT works best when it is tied to the actual workload or incident workflow, backed by session recording, and limited to the minimum set of roles needed for the action being performed.

Q: Why do multi-cloud environments make privileged access governance harder?

A: Because AWS, Azure, and GCP use different entitlement models, logging formats, and role inheritance patterns, a control that works in one provider can leave blind spots in another. Security teams need a cross-cloud governance layer that correlates access, session, and audit evidence before they trust a review result.

Q: What breaks when service account permissions are over-provisioned?

A: Over-provisioned service accounts turn a narrow automation identity into a broad escalation path. If impersonation, role assumption, or inherited permissions are too wide, a single compromise can move from one workload to many systems, widening the blast radius and making accountability hard to reconstruct.

Q: Who is accountable when privileged cloud access is granted outside normal review cycles?

A: Accountability sits with the programme owner who approved the control design, not just the operator who used the access. Cloud PAM needs clear ownership for who can grant elevation, who can revoke it, and who is responsible for audit completeness when access spans multiple clouds.

Technical breakdown

Why static credentials fail in ephemeral cloud environments

Traditional PAM was designed around durable systems and credentials that could be vaulted, reviewed, and rotated on a predictable schedule. In cloud environments, workloads disappear, scale out, and reappear continuously, so the identity is often the only stable control point. That changes the technical problem from endpoint administration to identity orchestration. If a credential can outlive the workload it protects, the access model is already misaligned with the runtime. This is why static secrets, long-lived roles, and monthly rotation cycles become weak control patterns in cloud-native infrastructure.

Practical implication: prioritize short-lived credentials and workload-bound access patterns over static privilege stores.

How multi-cloud privilege sprawl changes auditability

Multi-cloud environments introduce different role models, logging formats, session tools, and inheritance rules, so a single access pattern does not behave the same way in AWS, Azure, and GCP. That makes unified review difficult because each platform expresses privilege differently. A control that looks adequate in one cloud may leave blind spots in another, especially when access is delegated through roles or service account impersonation. The technical issue is not just complexity, but inconsistent visibility across identity planes and resource planes. Without central policy and correlated logs, privileged access becomes difficult to prove and harder to contain.

Practical implication: correlate entitlement, session, and audit data across clouds before you rely on any access review outcome.

Where JIT access and session recording fit in cloud PAM

Just-in-time access works in cloud PAM because it narrows privilege to the task window and removes persistent standing access. In practice, that means elevated permissions should be created at request time, tied to a specific workload or support action, and removed automatically when the task ends. Session recording extends the control by preserving evidence of what happened during the privilege window, including console, SSH, kubectl, and database activity where applicable. The technical limit is that these controls only help if they are integrated with cloud-native workflows and can cover the actual access paths used by engineers and automation.

Practical implication: wire JIT approval and audit capture into the same operational paths teams already use, or they will route around the control.

Threat narrative

Attacker objective: The attacker objective is to turn narrow cloud access into durable privileged control over infrastructure and the data or systems exposed by that control.

1. Entry begins with long-lived cloud credentials, over-permissioned roles, or service account impersonation that grants access beyond the original task.
2. Escalation occurs when role combinations, inherited permissions, or cross-account assumptions let the actor move from limited access to privileged cloud control.
3. Impact follows when the elevated identity is used to modify infrastructure, access sensitive systems, or widen the blast radius across accounts and regions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

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 is now an identity governance problem, not a server administration problem. The article shows that the old model assumed known endpoints, stable credentials, and a manageable list of privileged accounts. That assumption breaks once workloads are ephemeral and identities are mostly non-human. The implication is that privileged access policy has to be designed around runtime identity behaviour, not infrastructure permanence.

Standing privilege is the wrong default for cloud-native operations. If credentials are created once and revisited later, the access model already assumes time that cloud workloads do not have. Access review cycles, monthly rotations, and vaulted secrets were built for slower environments. In cloud PAM, those controls can lag behind the actual lifecycle of privilege, leaving exposure in place after the task is done. Practitioners should treat standing privilege as a structural mismatch, not just a configuration issue.

Multi-cloud privilege blast radius is the named concept this article exposes. Access models in AWS, Azure, and GCP do not fail in the same way, but they compound each other when policy and audit are fragmented. A role that is acceptable in one provider can become invisible when chained through another identity plane. The practitioner consequence is that least privilege must be evaluated across cloud boundaries, not inside each platform in isolation.

JIT access only works when the operational workflow is part of the control plane. The article makes clear that teams route around friction when access requests live outside their incident and engineering workflows. That means the governance failure is not only over-permissioning, but also control separation from real work. The implication is that PAM programmes must align approval, audit, and provisioning with how engineers actually operate, or the policy will be bypassed.

AI-driven infrastructure access makes the cloud PAM gap more visible. The article correctly places AI agents alongside service accounts and workloads as part of the privileged identity surface. When software can call infrastructure directly at scale, identity governance has to account for non-human decision paths as well as human requests. The practical conclusion is that cloud PAM and NHI governance are converging whether teams have formalised that boundary or not.

From our research:

• 59.8% of organisations see value in a solution that simplifies non-human access management and introduces dynamic ephemeral credentials, according to The 2024 Non-Human Identity Security Report.
• Only 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how much of the exposure still sits in basic handling practices rather than sophisticated attacks.
• For the governance baseline behind this shift, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding change when credentials are no longer static.

What this signals

Multi-cloud privilege review is becoming a correlation problem. Teams should expect access governance to move from single-platform entitlement checks to evidence stitching across workload identity, session recording, and audit telemetry. The programmes that hold up will be the ones that treat cloud privilege as a cross-domain identity record rather than a collection of cloud-native exceptions.

With 88.5% of organisations already saying their non-human IAM practices lag behind or merely match human IAM, the operational gap is no longer theoretical. Cloud PAM roadmaps now have to absorb NHI lifecycle, ephemeral credentials, and workload identity as first-class controls.

Identity blast radius: This article reinforces the idea that privilege should be measured by how far an identity can move, not just by what role name it carries. That means platform teams should review delegation chains, impersonation paths, and expiry enforcement together, while aligning cloud control design with NIST Cybersecurity Framework 2.0 governance and recovery expectations.

For practitioners

• Re-baseline privileged access around ephemeral workloads Map every cloud privilege path to the workload or task it supports, then remove any access that persists beyond that runtime. Prioritise short-lived credentials for autoscaling, containers, serverless functions, and cloud administration tasks.
• Unify entitlement visibility across AWS, Azure, and GCP Build a single view of role assignments, session activity, and audit logs across all providers so privilege can be reviewed as one governance problem. Separate native cloud controls from your cross-cloud decision record.
• Treat service account impersonation as privileged escalation Inventory where impersonation permissions, role assumption, and cross-account delegation can expose hidden privilege. Remove broad inheritance paths that let a low-friction identity acquire more access than its owning workflow requires.
• Embed JIT approval into engineering workflows Route privileged access requests through the chat, incident, or ops tools teams already use, then attach automatic expiry and recording to the approval outcome. Controls that add separate portals create bypass pressure.

Key takeaways

• Cloud PAM breaks when it is still built around fixed servers and human-paced review cycles.
• The scale problem is not only credential volume but also cross-cloud inconsistency, hidden escalation, and short-lived workloads that outlast manual governance.
• Practitioners need task-scoped access, unified audit evidence, and expiry-driven controls if they want least privilege to survive in cloud environments.

Key terms

• Cloud privileged access management: Cloud privileged access management is the discipline of controlling elevated access to cloud resources, control planes, and supporting identities. It focuses on granting the minimum access needed for a task, proving what happened during use, and removing access before it becomes standing privilege.
• Ephemeral infrastructure: Ephemeral infrastructure is compute or platform capacity that exists only for a short time and can be created or destroyed automatically. In identity governance, it shifts control away from static servers and toward workload-bound access that expires with the runtime it serves.
• Service account impersonation: Service account impersonation is the ability for one identity to act as a service account and inherit its permissions for a period of time. It is powerful for automation, but it also creates a hidden escalation path if the impersonation scope is broader than the task requires.
• Identity blast radius: Identity blast radius is the amount of damage an identity can cause if its access is abused, compromised, or mis-scoped. In cloud and machine identity governance, it is a practical measure of how far privilege can spread across accounts, regions, or platforms before it is contained.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• AWS-specific escalation paths such as iam:PassRole and ec2:RunInstances combinations that can turn low privilege into administrative control
• Azure-specific friction points between Entra ID, ARM, PIM, and Bastion that affect approval, session control, and audit coverage
• GCP-specific service account impersonation risks, key handling pitfalls, and inheritance issues that are easy to miss in reviews
• The implementation mechanics behind dynamic credential generation, session recording, and approval workflow integration across cloud platforms

👉 Infisical's full post covers the cloud-specific escalation paths, audit blind spots, and implementation detail.

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 governance in your organisation, it is worth exploring.