PassRole controls who may hand a role to a service, while the trust policy controls whether the role can be assumed at all. If either side is too permissive, the effective boundary disappears. That is why hidden escalation often survives policy reviews: one control looks narrow while the other quietly reopens the door.
How trust policies and PassRole create the gap attackers look for
Escalation appears when people treat role assignment and role assumption as one decision. In cloud systems, they are two separate checks, so a weak policy on either side can let a user, pipeline, or workload hand off privilege in ways the reviewer never intended. The dangerous pattern is not a single bad permission, but a mismatched pair of permissions that jointly widen the blast radius.
A trust policy answers who or what may assume a role. PassRole answers who may attach that role to a service or service-like control plane action. If the trust side is broad, a low-privilege actor can become the caller of a high-value role. If PassRole is broad, the actor can place that role into a service path that was never meant to hold it. The escalation path emerges when those two gates align in the same request chain.
This is why “can pass it” and “can assume it” must be reviewed together. A role that looks safe in isolation may still be reachable through an indirect path, especially when service creation, deployment automation, or orchestration APIs can nominate roles on behalf of a caller. The reviewer needs to trace both the permission that hands over the role and the trust relationship that accepts it.
Risk and Threat Considerations
The risk is silent privilege transfer. An actor with limited direct access can sometimes route around least privilege by selecting a more powerful role for a service, then relying on a permissive trust policy to make that role usable. That creates a high-value escalation path even when no single statement appears obviously overbroad.
Failure mechanism: One policy authorizes role delegation while another authorizes role assumption, and the combination allows privilege to flow through an indirect service path that was not reviewed as a single control boundary.
Impact: The result can be unauthorized administrative access, broader data reach, or the ability to launch follow-on actions under a trusted role, which makes blast radius larger than the initial identity or workload should have allowed.
What to check when reviewing role delegation and trust
In practice, the important question is not whether a role is “protected,” but whether the same principal can both nominate it and satisfy its trust conditions. That is where escalation paths hide. When deployment tooling, automation runners, or application operators can pass roles, the trust policy should be narrow enough that only the intended service, account, or workload can assume them.
Pay particular attention to broad wildcard trust, cross-account trust, service principals that are wider than necessary, and role usage embedded in templates or pipelines. A role that is never directly assumed by a human may still be fully reachable through an orchestrated control plane path if the trust policy and PassRole permission are not aligned.
The review should also ask whether the role being passed is more privileged than the caller needs for the task. If yes, the problem is not just access, it is privilege amplification through delegation. That is where hidden escalation often survives policy review, because each control seems narrow when viewed alone.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Role delegation paths depend on controlling credential and token use across services. |
| AC-6 — Least Privilege | PassRole escalation is fundamentally an excessive-authority problem across a delegated path. | |
| AC-3 — Access Enforcement | Trust policy and PassRole together determine whether access is actually enforced at assumption time. | |
| Recommendation — Limit role-capable credentials and rotate or revoke any token that can reach privileged roles. Restrict who can pass roles and narrow each role to the minimum actions needed. Enforce the assumption boundary so only intended principals can activate the role. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service roles and machine identities can become overprivileged through broad pass-and-assume paths. |
| NHI-04 — Insecure Authentication | A permissive trust policy weakens the assurance needed before a role can be assumed. | |
| NHI-01 — Improper Offboarding | Stale trust relationships or unused pass-role grants can remain after a workload or team changes. | |
| Recommendation — Audit non-human roles for excessive permissions and remove unnecessary pass-role authority. Require strong, constrained assumption conditions for any role that can reach sensitive actions. Revoke unused role-assumption paths and retire trust relationships when services change. | ||
Practitioner Guidance
What to verify: Check the full chain, caller permission to pass the role, the service’s ability to assume it, and the actual actions the role can perform after assumption. If any link is broader than the intended task, treat the chain as an escalation candidate rather than a routine configuration.
Decision rule: If a principal can influence both role selection and role assumption, tighten one side until the two controls no longer compose into unintended privilege. If you cannot express the intended use case without broad trust, redesign the access path instead of accepting the exception.
Common mistake: Reviewing PassRole as a standalone permission and trust policy as a standalone trust document. That misses the combined effect, which is what actually determines whether privilege can move from one context to another.
Practitioner takeaway: Escalation prevention here depends on composability, not individual policy strength, so verify the delegation path and the assumption path together before trusting either one.