Subscribe to the Non-Human & AI Identity Journal
Governance, Ownership & Risk

IAM:PassRole

← Back to Glossary
By NHI Mgmt Group Updated June 24, 2026 Domain: Governance, Ownership & Risk

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.

Expanded Definition

IAM:PassRole is an AWS delegation control, not a credential for directly becoming a role. It lets one principal instruct a service to use a role on its behalf, which means the caller needs permission to pass that role and the receiving service must also be allowed to assume it.

In NHI security, this distinction matters because the risk is often hidden in orchestration flows. A deployment pipeline, automation user, or application owner may never hold the target role’s permissions directly, yet still create an execution path that runs with those permissions. AWS documents the control through the IAM PassRole permission, while the governance question is whether the role being passed is narrowly scoped to the exact service and resource path required.

Definitions across vendors are consistent on the AWS mechanism, but operational usage is still often misunderstood as simple role assumption. The most common misapplication is granting PassRole broadly to a human or automation principal when the condition limiting which role can be passed is absent or too permissive.

Examples and Use Cases

Implementing PassRole rigorously often introduces deployment friction, requiring organisations to weigh automation speed against tighter delegation boundaries.

  • A CI/CD runner can deploy an AWS Lambda function only if it is allowed to pass one specific execution role, not any role in the account.
  • An infrastructure engineer can create an ECS task definition that references a service role, but only when the policy restricts PassRole to approved task roles.
  • A security team reviews whether a break-glass automation account can pass administrative roles, or whether that path should be blocked entirely.
  • An incident response workflow launches a remediation function with a dedicated role, avoiding reuse of a high-privilege role intended for unrelated workloads.

These patterns align with NIST guidance on least privilege and access control, especially when mapped to the NIST Cybersecurity Framework 2.0 function for access governance. NHI Management Group also highlights how privilege paths often hide inside cloud automation, including cases similar to Azure Key Vault privilege escalation exposure, where a narrow-looking permission can still open a wider execution path. In practice, PassRole should be paired with explicit role naming, service restrictions, and resource conditions so that delegation stays predictable.

Why It Matters in NHI Security

PassRole is a classic NHI governance issue because the principal using it may be ephemeral, automated, or embedded in a pipeline, yet the delegated role can persist as the real source of authority during execution. When PassRole is overbroad, a low-trust identity can redirect workloads into privileged roles without ever needing to steal the role’s long-term credentials.

That creates a direct path from ordinary automation to privilege escalation, especially in environments where roles are reused across teams, services, or accounts. NHI Management Group reports that 97% of NHIs carry excessive privileges, which makes delegation controls like PassRole especially important because the abuse path often begins with a permission that appears harmless during review. It also shows why cloud identity review cannot stop at static role documents; it must examine who can delegate what to which workload.

Organisations typically encounter the impact only after an unexpected workload launch, privilege escalation, or audit finding, at which point PassRole becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01PassRole is a delegated NHI privilege path that can enable escalation when too broad.
NIST CSF 2.0PR.AC-4Least-privilege access control applies directly to delegation permissions like PassRole.
NIST Zero Trust (SP 800-207)Zero Trust treats every delegation step as a policy decision that must be explicitly authorized.

Evaluate PassRole as a trust decision and enforce service-scoped authorization conditions.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org