What is the difference between an IAM trust policy and an IAM permissions policy?

What each policy controls in an IAM role

An IAM trust policy and an IAM permissions policy solve two different problems in the same delegation flow. The trust policy is the gatekeeper for role assumption, while the permissions policy is the operating envelope after assumption. That distinction matters because a role can be perfectly trusted by the right principal and still be overly dangerous if its permissions are too broad.

In practice, the trust policy is evaluated before credentials for the role are issued. It is about who can step into the role, under what conditions, and sometimes from which account, service, or workload. The permissions policy is evaluated after the session exists, and it defines the allowed actions on AWS resources once the role is already active.

For a deeper AWS-specific treatment of role trust and permission evaluation, see AWS IAM Policies and Roles Guide.

How the two policies work together during access delegation

The clean way to think about the split is entry versus action scope. The trust policy decides whether the caller may assume the role at all. The permissions policy then decides what that session can do, such as read data, start infrastructure, invoke APIs, or administer related IAM objects. If either side is misconfigured, the delegation model breaks in a different way.

This is why trust and permissions cannot be treated as interchangeable. A tightly written permissions policy does not help if an untrusted principal can assume the role. Likewise, a restrictive trust policy does not protect you if the role itself has broad permissions that become available to any authorized session. Secure delegation depends on both controls being aligned to the same business purpose.

When you are reviewing AWS role assumption paths, the most useful check is whether the trust relationship and the attached permissions describe the same operational intent. If they do not, the role is usually either overexposed, under-scoped, or both.

Why the distinction matters in audits, reviews, and incident response

Role confusion is common because both documents are called “policies,” but they are evaluated at different stages and for different questions. During design review, the trust policy tells you whether the assumption path is legitimate. During entitlement review, the permissions policy tells you whether the assumed identity has more authority than it should. During incident response, both matter because abuse may begin with improper role assumption and then continue through excessive permissions.

The distinction is especially important in cross-account access, workload federation, and automation pipelines. In those cases, the trust policy often carries the strongest security decisions, because it limits which external or non-interactive principals may obtain the role in the first place. The permissions policy then becomes the blast-radius limiter for whatever that role can do after access has been granted.

For organisations that want a structured way to review role trust, How to review AWS cross-account trust policies for confused deputy is a useful companion, because it focuses on the trust side of delegated access. For broader policy evaluation logic and least-privilege analysis, AWS IAM Policies and Roles Guide remains the more complete reference.

Risk and Threat Considerations

The main risk is assuming that a well-written permissions policy can compensate for a weak trust policy, or vice versa. In role-based delegation, attackers usually need only one side to fail: an overly broad trust relationship gives them a foothold, and an overly broad permissions policy turns that foothold into meaningful access.

Failure mechanism: A mis-scoped trust policy may allow unintended principals to assume the role, while an excessive permissions policy may let an authorized session perform actions that were never intended for that delegation path. In cross-account or automated workflows, that combination can create a fast path from initial access to privilege abuse.

Impact: The result can be unauthorized resource changes, data access, lateral movement, or rapid blast-radius expansion. In real environments, the trust side often controls how access is obtained, while the permissions side controls how much damage that access can do.

Practitioner Guidance

What to verify: Check the trust policy first when you are validating who can assume the role, then inspect the permissions policy to confirm the session only has the actions required for that function. If either policy is broader than the role’s stated purpose, treat the role as unsafe until corrected.

Decision rule: If the risk is “who can get in,” focus on trust. If the risk is “what they can do once in,” focus on permissions. If both are unclear, assume the delegation model is incomplete and review the role as a single control pair rather than as two separate documents.

Practitioner takeaway: The trust policy protects the door, but the permissions policy defines the room, and secure delegation only exists when both are intentionally narrow and consistent.

Related resources from NHI Mgmt Group

• Guide: Permissions Policy, COOP, COEP and CORP Guide
• How should IAM teams handle newly released cloud permissions that can change trust boundaries?
• What is the difference between scanning raw IAM policy text and evaluating expanded permissions?
• How should security teams simplify AWS IAM policy review when permissions are spread across users, groups, roles, and policy sources?
• What breaks when cloud permissions can change IAM policy or identity mappings?