A trust policy controls who can assume the role. A permission policy controls what the role can do after it is assumed. Both are required, but they solve different problems: trust decides access to the role itself, while permissions decide the actions available once that access has been granted. Confusing them leads to weak access control reviews.
Why Trust Policies and Permission Policies Solve Different Problems
An AWS role trust policy governs who or what is allowed to assume the role, so it is about establishing the boundary for role entry. A permission policy governs what actions the role can take once assumption succeeds, so it is about constraining the resulting authority. That separation matters because a role can be correctly trusted but still dangerously overpowered, or tightly permissioned but open to assumption by the wrong principal. The distinction is especially important in reviews of cross-account access, federated access, and automation that uses temporary credentials.
For practitioners, the key point is that assumption is not the same as authorization. A trust policy answers the identity question at the moment of role entry, while a permission policy answers the action question after entry. Mixing them up often leads teams to believe they have reduced access when they have only moved the control to the wrong layer. For background on the broader non-human identity context, NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks explains why role scope and credential scope must be treated separately in machine access governance.
In practice, many access failures are discovered only after a trusted principal has already assumed a role and exercised permissions that were never meant to be bundled together.
How the Two Policies Work Together in Practice
In AWS, the trust policy sits on the role object and defines the principals, conditions, and sometimes external identifiers that may assume it. The permission policy, attached to the role, defines the API actions and resource scope available after the role issues temporary credentials. That means a successful assume-role event is only the start of the access chain, not the end of the control decision.
For example, a CI job might be allowed by trust policy to assume a deployment role, but the permission policy should limit that role to the smallest set of resources and operations needed for deployment. If the trust policy is too broad, any allowed principal can obtain the role. If the permission policy is too broad, the role becomes a high-value credential with excessive blast radius. The control problem is therefore two-dimensional: entry control and post-entry authority control.
Practitioners should also treat conditions as part of the trust boundary, not a decorative layer. Conditions such as source account, source ARN, external ID, or session tags can materially reduce abuse of assumed roles, but they do not replace permission scoping. Likewise, permissions should be written with resource-level constraints wherever AWS supports them, rather than relying on broad service-wide access. The same separation applies to human federation, workload identities, and automation because temporary credentials still inherit whatever authority the role allows. OWASP’s OWASP Non-Human Identity Top 10 is useful here because it frames the lifecycle and privilege risks that appear once a machine principal can assume or use cloud roles.
If you need a policy model for this distinction, the clean mental test is simple: ask first who may enter, then ask what they may do after entry. The role trust policy governs the first question; the permission policy governs the second. These controls tend to break down when teams copy a working role template across environments, because the trust boundary and action scope often drift apart unnoticed.
Where Teams Usually Get the Review Wrong
Tighter trust controls often increase operational friction, requiring organisations to balance access precision against deployment complexity. A common mistake is to approve a role because its trust policy looks narrow, then overlook that the attached permissions allow far more than the assumed workload needs. Another frequent error is the reverse: teams focus on least privilege in the permission policy but leave trust open to principals that should never be able to assume the role in the first place.
Another edge case is session duration and chained assumptions. Short-lived credentials reduce exposure, but they do not fix a role that can be assumed by the wrong account or a permission set that exposes sensitive resources. Best practice is evolving around explicit separation of trust review and permission review, because many audits still collapse both into a single “role access” checkbox. For teams managing many roles, the operational burden is less about writing one correct policy and more about keeping both policies aligned as services, accounts, and deployment paths change. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant because stale role assumptions and stale permissions tend to age differently.
Practitioner takeaway: the security quality of an AWS role is determined by the weaker of the two policies, so review trust for who can enter and permissions for what that entry can reach.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Separates role assumption approval from post-assumption privileges. |
| Recommendation — Review access paths and remove unnecessary privileges from assumed roles. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | Role trust and permissions map to distinct authorization decisions. |
| Recommendation — Enforce entry and action decisions separately at each policy boundary. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The question is about controlling who enters and what access they receive. |
| Recommendation — Apply access control review to both role trust and effective permissions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Assumed roles issue temporary machine credentials with direct access impact. |
| Recommendation — Limit role assumption and scope the resulting machine credential tightly. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Abuse of assumed roles is a valid-account access path after trust succeeds. |
| Recommendation — Hunt for abused role assumptions and investigate unexpected valid-account use. | ||
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between scanning raw IAM policy text and evaluating expanded permissions?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
