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

Who the policy protects, and what it governs

An IAM trust policy and an IAM permissions policy answer two different control questions in a role-based delegation model. The trust policy is the gatekeeper for role assumption, it defines which principal can enter the role boundary. The permissions policy is the action rulebook, it defines what the assumed identity can do once inside. That split is what keeps delegation precise instead of open-ended.

This distinction matters because the two policies operate at different points in the access path. A trust policy is evaluated before access is granted, so it limits who can obtain the role’s authority at all. A permissions policy is evaluated after assumption, so it limits the blast radius of that authority. In practice, secure design depends on both being correct, because either one alone leaves a gap.

Why the separation matters for delegation and least privilege

The cleanest way to think about the difference is “entry versus action.” Trust policy decides whether a user, service, workload, or other principal is allowed to assume the role. Permissions policy decides which API calls, resources, or operations that role may perform after assumption. For temporary access patterns, this separation is foundational to least privilege and avoids embedding broad power into the trust relationship itself.

That is why delegation should not be treated as a single permission decision. If the trust policy is too broad, the wrong principal can inherit the role regardless of how carefully the permissions policy is written. If the permissions policy is too broad, a properly trusted principal still gains more authority than intended. The effective security posture is the intersection of both policies, not the stronger of the two.

For readers who want the control model behind this, the role of trust relationships and permission boundaries is closely aligned with IAM governance guidance in the Ultimate Guide to NHIs and the lifecycle and access-governance emphasis in NHI Lifecycle Management Guide. Those resources are useful when the role is being used by non-human workloads, but the policy split itself applies to any IAM role model.

How practitioners should validate each policy in real environments

A useful review starts by asking whether the trust policy is narrower than the permissions policy. That is usually the right shape. The trust policy should enumerate only the principals that truly need to assume the role, while the permissions policy should only cover the minimum actions needed after assumption. When the two are merged mentally, teams often miss that a loosely trusted role with limited permissions can still be a serious exposure if it can be assumed by the wrong actor.

There is also a lifecycle issue: trust often changes more slowly than permissions. Teams update permissions during application changes, but leave trust rules untouched after integrations, migrations, or environment changes. That is where stale delegation accumulates. A good review therefore checks assumption paths, external principals, and cross-account or cross-service trust separately from resource permissions and action scope.

When the subject is workloads, service accounts, or other machine-driven access paths, the same distinction is especially important because role assumption can be automated and repeated at scale. The NIST Cybersecurity Framework 2.0 supports the broader governance view, while NIST Cybersecurity Framework 2.0 helps frame the trust side as an access-governance problem and the permissions side as a least-privilege problem. For identity-specific controls, AWS-style role delegation is also commonly assessed alongside NIST SP 800-53 Rev 5 Security and Privacy Controls, especially IA and AC controls.

Risk and Threat Considerations

Weak trust policies create an entry-path risk: if too many principals can assume a role, attackers who compromise any one of those principals may inherit the role’s authority. Weak permissions policies create an action-path risk: if the assumed role can do more than intended, compromise or misuse of that role becomes more damaging than the original access decision suggested.

Failure mechanism: An attacker or unintended principal abuses a permissive trust relationship to assume the role, then uses the role’s permissions to read data, modify resources, or pivot further into the environment. The failure often comes from treating assumption and authorization as one control instead of two separate checks.

Impact: The result is delegated privilege becoming excessive privilege. That can lead to unauthorized access, lateral movement, data exposure, or destructive action, even when the role’s direct permissions looked reasonable in isolation.

Practitioner Guidance

What to verify: Review the trust policy first for who can assume the role, then review the permissions policy for what the assumed role can do. If either policy names broad principals, wildcard trust, or broad action sets, treat the role as higher risk until the delegation path is narrowed.

Common mistake: Teams often harden the permissions policy and assume the role is safe, but a weak trust policy can still let the wrong principal step into that role. The reverse is also true: a tight trust policy does not compensate for overly broad permissions.

Practitioner takeaway: Secure delegation is achieved by constraining both the door and the room, not by overloading one policy to do the work of both.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• 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?