What is the difference between a trust policy and a resource policy?

How trust policies and resource policies split control planes

A trust policy answers a narrower question: which principals are allowed to assume a role. A resource policy answers a different question: which principals can act directly on the protected resource itself. That distinction matters because the first governs who can obtain role authority, while the second governs who can use the resource without first stepping through a role.

In practice, that means a trust policy is about role assumption and delegated authority, while a resource policy is about direct authorization on the target object. When you are troubleshooting access, ask whether the principal is trying to obtain temporary role credentials or is calling the resource with an identity that the resource policy already recognises.

The cleanest mental model is to separate “who may become this role” from “who may touch this bucket, topic, queue, key, or similar resource.” That separation is what makes cross-account access work in a controlled way, because the role can be assumable by one set of principals while the resource can still expose a different access path for direct use.

What changes operationally when access is role-based versus resource-based

Trust policies usually sit on the identity side of the boundary, so they shape whether a principal can obtain the role’s permissions at all. Resource policies sit on the asset side of the boundary, so they can grant access even when the caller does not first assume a role. The result is that two different policy layers can both be involved in the same access decision, but they answer different questions.

This is why misreading the policy type causes false assumptions during design reviews. A trust policy that is too permissive widens who can assume the role. A resource policy that is too permissive widens who can invoke the resource directly. Those are related but not identical exposure paths, and they should be reviewed separately.

There is also an important cross-account distinction. A trust policy typically controls whether an external principal can assume the role, while a resource policy can directly permit another account, service, or external principal to interact with the resource. For that reason, resource policies are often the mechanism that makes cross-account sharing practical, but they can also be the mechanism that bypasses an intended role boundary if they are too broad.

When the difference matters most in access design and review

The distinction matters most when you are checking least privilege, cross-account sharing, or service-to-service access paths. In those cases, it is not enough to know that “access works”, you need to know which policy granted it and whether that path matches the intended trust boundary. The same principal may be harmless in one policy layer and over-privileged in the other.

• A trust policy should be reviewed for who can assume the role, under what conditions, and whether unintended principals can chain into it.
• A resource policy should be reviewed for who can act on the object directly, especially where the resource itself is exposed to another account or service.
• If both exist, confirm that the effective access path is intentional, not duplicated by accident, because duplicate grants are a common source of overly broad access.

For teams working across AWS-style policy models, the practical value is often in avoiding policy confusion: a role can be correctly trusted but still be paired with a resource policy that grants broader direct access than the role was meant to allow. A good review checks both sides together, not one in isolation. NHIMG’s AWS IAM Policies and Roles Guide is useful when you want the broader evaluation logic around roles, trust and policy types.

Risk and Threat Considerations

Policy confusion creates real exposure because attackers and over-permissioned users both benefit from the broader of the two paths. If the trust policy is weak, an attacker may be able to assume a role they should never reach. If the resource policy is weak, they may bypass role assumption altogether and use the resource directly, including from another account where that exposure was not intended.

Failure mechanism: Broad trust relationships or permissive resource grants collapse the boundary between “can assume” and “can use”, which can turn a narrow delegation into broad cross-account access or unintended direct access.

Impact: The practical result is increased blast radius, harder access review, and a higher chance that sensitive data, administrative actions, or cryptographic material are reachable through an access path the owner did not mean to expose.

Practitioner Guidance

What to verify: Confirm whether a given access path depends on role assumption, direct resource access, or both. That distinction tells you which policy must be tightened first and which logs or evaluation traces you should inspect when access looks surprising.

Decision rule: If the caller needs to become a role before acting, focus on the trust policy. If the caller can reach the resource directly, focus on the resource policy. If both paths exist, treat the broader one as the effective exposure until proven otherwise.

Common mistake: Teams often review only the role trust relationship and miss the resource policy, or they do the reverse. The result is a mistaken belief that access is constrained when one policy layer still grants a broader route.

Practitioner takeaway: The key question is not just “who can access this”, but “through which policy boundary does that access happen”. Once you separate assumption from direct use, policy review becomes much more accurate and much harder to game.

Related resources from NHI Mgmt Group

• When does Zero Trust become more than a policy label for NHI governance?
• Should organisations align PAM and zero trust policy design?
• What is the difference between static access control and dynamic policy in Zero Trust?
• Why do zero-trust programmes depend on ingress policy in Kubernetes?