An AWS policy that defines who or what is allowed to assume a role. It is a critical control point because it governs the transition from one identity context to another. When properly constrained, it can enforce MFA, network conditions, account boundaries, and other assumptions.
What a role trust policy controls
A role trust policy is the allow-list that determines which principals can assume an AWS role. It is the control that separates “having permission to call STS” from being trusted to cross into the role’s identity and privilege context.
That distinction matters because the trust policy defines the boundary of assumption, not the permissions the role grants after assumption. In practice, it is where AWS role federation, cross-account access, workload delegation, and temporary credential issuance are accepted or refused.
For workload and machine access patterns, this is the same control point practitioners use to constrain who may exchange one identity context for another, which is why Cloud Workload Identity Guide is a useful companion when you are reasoning about AWS roles, STS, and federated workload access.
Why the trust boundary is security-critical
The trust policy is part of the authentication and authorization handoff. If it is too broad, any principal that matches the condition can enter the role and inherit its permissions, which can erase account boundaries or make federation far wider than intended.
Trust conditions are most effective when they bind assumption to specific identity attributes, source accounts, external IDs, session constraints, or other contextual checks. That is why NHI Authentication Guide is relevant here, since it covers the kinds of authentication signals that often underpin trusted role assumption.
Role trust policy design is also closely related to temporary credential architecture. NIST Cybersecurity Framework 2.0 provides the broader govern, protect, detect, respond structure that fits this kind of access boundary control.
How trust policies differ from role permissions
A common mistake is to treat the trust policy and the permissions policy as the same thing. They are separate: the trust policy answers “who may assume this role,” while the permissions policy answers “what that assumed role may do.”
That separation is important because a tightly scoped permissions policy can still be undermined by an overly open trust policy. Conversely, a narrow trust policy does not make a broadly privileged role safe if the attached permissions are excessive.
For teams using federated build and deployment paths, CI/CD Pipeline Identity Security Guide is a strong reference for understanding how trust policy decisions intersect with OIDC federation, publishing tokens, and pipeline-issued credentials.
Common trust policy patterns and constraints
Role trust policies often use conditions to narrow assumption by account, principal ARN, external ID, MFA, session context, or network-related signals. The more precise the conditions, the less likely the role becomes a reusable privilege bridge for unintended callers.
In cross-account and workload scenarios, the policy may allow a specific IAM role, a federated identity provider, or a workload identity source rather than a broad identity class. SPIFFE workload identity specification is a useful external reference for the broader idea of binding workload identity to cryptographic trust and attestation.
At the cloud control level, NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both align with the need to constrain access paths, enforce least privilege, and monitor privileged transitions.
Risk and Threat Considerations
An overly permissive trust policy can turn a role into a privilege escalation path. If an attacker or unintended principal can satisfy the trust conditions, they may assume the role, obtain temporary credentials, and move laterally with the role’s permissions.
Failure mechanism: Weak principal scoping, missing external ID checks, broad federation rules, or relaxed conditions allow unintended assumption of the role, especially in cross-account and automation-heavy environments.
Impact: The result can be unauthorized access, cloud resource manipulation, data exposure, or persistence through a trusted temporary credential path that defenders may overlook.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Role trust policies govern who may assume a role and enter a new access context. |
| Recommendation — Restrict role assumption to approved principals and conditions before issuing temporary access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Trust policy scope determines whether role assumption can expand access beyond necessity. |
| IA-5 — Authenticator Management | Trust policies often depend on strong auth artifacts, tokens, certificates, or federated assertions. | |
| Recommendation — Limit assumption paths so role entry does not become an unnecessary privilege expansion. Bind role trust to strong authenticators and manage the credentials that enable assumption. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Role trust policies are a non-human identity authentication gate for workload and automation access. |
| NHI-05 — Overprivileged NHI | A permissive trust policy can let too many actors assume a privileged role. | |
| Recommendation — Harden trust conditions so machine and workload identities cannot assume roles opportunistically. Constrain trust relationships to prevent broad assumption of high-privilege non-human roles. | ||
Practitioner Guidance
Governance implication: Treat the trust policy as a privileged access decision, not a formality attached to the role. Review it with the same care you would apply to a sensitive authentication or delegation boundary, especially where roles are assumed by automation, partner accounts, or federated workloads.
What to watch for: Broad principals, wildcard-like trust patterns, missing contextual conditions, and roles that accept assumption from more than one business function are the usual signs that the boundary is too loose. A role can be low risk on paper and still be unsafe if the trust relationship is under-constrained.
Practitioner takeaway: Separate “who can assume” from “what the role can do,” and verify both whenever a role is reused across accounts, pipelines, or workload identities.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
