IAM:PassRole misconfigurations create hidden privilege escalation paths

At a glance

What this is: This is an analysis of seven common IAM:PassRole configuration pitfalls and how they create hidden escalation paths in AWS.

Why it matters: It matters because PassRole misconfiguration can let compromised humans, pipelines, or NHIs borrow higher privilege, which breaks least-privilege assumptions across IAM programmes.

By the numbers:

• 22% of analyzed breaches used credential abuse as the top initial attack vector.

👉 Read Apono's analysis of IAM:PassRole pitfalls in AWS

Context

IAM:PassRole is an AWS delegation control that lets one principal assign a role to a service, which means access can be passed without being directly assumed. In practice, that makes it a governance issue, not just a permissions detail, because the control sits at the junction of workload identity, trust policy, and privilege boundary.

The article’s central point is that PassRole becomes dangerous when standing access, permissive trust relationships, and unmanaged NHIs combine. That combination creates an attack path that looks operationally normal but can let a compromised credential turn into broader account control.

For IAM teams, the issue is not whether PassRole is useful. The issue is whether delegation is still constrained by specific role scope, specific services, and active monitoring after the environment has scaled and the original access model has drifted.

Key questions

Q: How should security teams restrict IAM:PassRole in AWS environments?

A: Security teams should restrict PassRole to explicit role ARNs, pair it with service-specific conditions, and keep the target role trust policy narrow. The safest design is one where a principal can only delegate a role to the workload it was intended for, and only within the environment where that role belongs.

Q: Why do standing NHI permissions make PassRole abuse more dangerous?

A: Standing NHI permissions make PassRole abuse more dangerous because the access path stays available after the workflow that justified it has changed. If a token or key is leaked, an attacker can keep passing roles repeatedly until the credential is revoked, which turns a temporary mistake into a persistent escalation route.

Q: What breaks when AWS trust policies are too permissive?

A: When AWS trust policies are too permissive, the role’s receiving side no longer controls who can assume it. That means a strict PassRole policy can still be undermined if the target role accepts broad principals or services, creating confused deputy risk and expanding the blast radius of compromise.

Q: How do teams know whether PassRole is being abused?

A: Teams know PassRole is being abused when role-passing activity appears outside normal deployment patterns, comes from unexpected identities, or creates workloads that later request stronger access. Monitoring should focus on unusual service combinations, off-hours delegation, and workloads that inherit more privilege than their normal job requires.

Technical breakdown

How PassRole becomes a privilege delegation path

IAM:PassRole lets a principal attach a role to a workload such as EC2, Lambda, or ECS so the service can act with that role’s permissions. The security boundary sits in two places: who may pass the role and whether the target role is willing to trust the service. If either side is too broad, delegation becomes a privilege transfer mechanism rather than a bounded operational control. This is why PassRole abuse often shows up when a low-privilege identity can also launch compute or create workloads that inherit stronger permissions.

Practical implication: constrain who can pass which role and pair it with workload launch restrictions so delegation cannot become escalation.

Why trust policies matter as much as pass permissions

A PassRole policy can look safe while the target role’s trust policy stays wide open. If the trust policy accepts an entire account, a broad service principal, or a wildcard pattern, the receiving side of the delegation no longer enforces intent. That creates a confused deputy condition, where a legitimate service can be made to act for the wrong party. In other words, the role’s entry conditions determine whether the pass itself is a controlled handoff or an exploitable shortcut.

Practical implication: review assume-role trust policies as part of every PassRole control decision, not as a separate checklist item.

Why NHIs make PassRole harder to govern

Pipelines, bots, and other NHIs often receive PassRole permissions so automation does not stall. The problem is that these identities are persistent, frequently overlooked in lifecycle reviews, and often backed by long-lived secrets. Once a token or key is exposed, attackers can reuse the same delegation path repeatedly without needing to re-enter the environment. That turns machine identity from a convenience layer into a reliable privilege broker when access is not time-bound and monitored.

Practical implication: include NHIs in access review, lifecycle offboarding, and alerting for role use outside expected deployment patterns.

Threat narrative

Attacker objective: The attacker’s objective is to convert a low-privilege AWS identity into administrative or near-administrative control through delegated workload access.

1. Entry begins with a leaked key, a compromised token, or another low-privilege identity that already has PassRole and workload-launch permissions.
2. Escalation occurs when the attacker attaches a higher-privilege role to a service or instance and then uses that workload to obtain stronger access.
3. Impact follows when the attacker pulls temporary credentials from the workload, expands privileges, and maintains a reusable escalation path until the access is revoked.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

PassRole is not a convenience permission, it is a delegation boundary. The article shows that the control only stays safe when both the delegator and the target role are tightly constrained. Once either side is broad, PassRole becomes a route for privilege inheritance rather than a bounded workflow step. For IAM teams, that means treating delegation scope as an enforceable security property, not an administrative detail.

Standing NHI access is the condition that makes PassRole persist into an attack path. Pipelines and bots often keep pass permissions long after the workflow that justified them has changed. That means a credential leak does not just expose access, it exposes a durable delegation channel that manual review struggles to see. The practical conclusion is that NHI governance has to include lifecycle and offboarding discipline, not only policy review.

Confused deputy risk is the hidden failure mode in many AWS delegation designs. The article correctly points to permissive trust policies as the second half of the problem. If a role trusts too many services or principals, a legitimate workload can be tricked into executing on behalf of an attacker. IAM programmes should therefore evaluate the trust side of every role with the same rigour applied to the pass-side permission.

Blast radius in AWS is often created by the right to create execution context, not by direct admin rights. The article’s pattern is familiar: a principal with minimal apparent privilege can create a resource, attach a stronger role, and inherit its power. That breaks the assumption that least privilege can be judged only from the human or NHI policy attached to the caller. Practitioners should view workload launch rights as part of privilege analysis, not a separate operational concern.

PassRole misuse is a lifecycle problem, not a one-time misconfiguration. As environments scale, role usage drifts, automation expands, and the original approval context disappears. The article’s warning is that static reviews cannot keep pace with active delegation pathways. The implication for identity governance is clear: role-pass relationships need continuous validation, especially where NHIs and standing credentials are involved.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• That gap makes lifecycle discipline and workload identity governance the next control layer to prioritise, as outlined in Ultimate Guide to NHIs.

What this signals

PassRole governance is increasingly a workload identity problem, not just an AWS policy problem. When automation identities keep delegation rights longer than the workflows that justified them, the control model shifts from permissions administration to lifecycle governance. Teams should expect more scrutiny on NHIs that can create or attach privilege in cloud environments, especially where short-lived access is not yet the default.

The strongest immediate signal is not whether a policy exists, but whether role-passing activity can be tied to a real deployment pattern and a current owner. That is where monitoring, offboarding, and entitlement review need to converge. For a broader control frame, align this work with the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs.

Identity blast radius is the metric that matters here. The point is not to count PassRole permissions in isolation, but to measure how many downstream workloads can inherit privilege from one compromised caller. Once that is visible, teams can reduce the number of identities that can create execution context and shrink the number of places where escalation can hide.

For practitioners

• Tighten PassRole to named role ARNs Replace wildcard resource scope with explicit role ARNs and separate staging from production delegation so a compromised identity cannot attach high-value roles by default.
• Bind roles to specific services Use iam:PassedToService conditions so a role created for Lambda cannot be reused on EC2 or another more interactive service that gives an attacker a richer control surface.
• Review trust policies with the same rigor as PassRole policies Check the role trust boundary for broad account IDs, wildcard principals, and over-permissive service trusts because the receiving side can undo an apparently strict pass policy.
• Put NHIs into lifecycle review and offboarding Inventory pipelines, bots, and service identities that can pass roles, then revoke stale access and remove permissions that no longer match current deployment patterns.
• Alert on role passage outside deployment patterns Create detections for off-hours or unusual PassRole use, especially from long-lived keys and automation identities, because that is where hidden escalation often hides.

Key takeaways

• IAM:PassRole becomes a hidden escalation path when delegation scope, workload launch rights, and trust policies are not tightly bounded.
• The article’s evidence points to a familiar cloud failure mode, where low-privilege identities and standing NHI permissions combine to make privilege escalation look like normal operations.
• Practitioners should treat PassRole, trust policy review, and NHI lifecycle governance as one control problem, not three separate ones.

Key terms

• IAM:PassRole: IAM:PassRole is an AWS permission that allows one principal to assign a role to a service or workload. It matters because it governs delegation, not direct role assumption, so a misconfiguration can let a low-privilege identity create a higher-privilege execution path.
• Trust Policy: A trust policy defines which principals or services are allowed to assume a role. In AWS governance, it is the receiving side of delegation, and if it is too broad, it can neutralise an apparently strict permission on the caller side.
• Workload Identity: Workload identity is the identity a machine or service uses to authenticate and access resources. It includes pipelines, bots, and cloud workloads, and it must be governed across lifecycle, privilege, and monitoring just as carefully as human identity.

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 Apono: 7 Pitfalls to Consider When Configuring IAM:PassRole. Read the original.