How do you audit who holds the AWS IAM role trust policy?

What an AWS IAM role trust policy actually governs

An aws iam role trust policy answers a narrow but critical question: who, or what, is allowed to request the role through STS. It does not grant permissions inside the role; it defines the trust boundary for assumption. That is why an audit starts with the trusted principals, then checks whether the conditions attached to that trust still make sense.

The strongest reviews treat the trust policy as an access control list for role assumption. In practice, that means reading the principals line by line, then asking whether each entry is still required, whether it is broader than intended, and whether the conditions constrain the request enough for the environment the role protects.

For a structured overview of how AWS roles fit into broader cloud identity design, NHIMG’s AWS IAM Policies and Roles Guide covers role trust, chaining and permission boundaries in the same model.

How to audit the trusted principals and conditions

Start by listing every principal that can assume the role: AWS accounts, IAM roles, federated identities, and service principals. Then compare that list with the role’s actual usage history. A trust statement that once supported a deployment pipeline, vendor integration, or cross-account workflow may now be stale, duplicated elsewhere, or broader than the current business need.

Conditions are the part that often turns a generic trust relationship into a defensible one. Check whether the policy uses external IDs, source account or source ARN conditions, session tags, MFA requirements, or other constraints that reduce confused deputy risk and limit who can assume the role under which circumstances. If the trust policy allows assumption without meaningful constraints, it is usually a candidate for tightening.

For cloud trust reviews that combine role assumption, cross-account access and identity analysis, NHIMG’s Cloud IAM Review Checklist is a useful companion reference.

The same review should also look for unused trust paths. A role may still be trusted by a principal that has not assumed it in months, or by a service principal that is no longer part of the architecture. Those are common indicators that the trust policy has drifted away from operational reality.

What to look for when trust is broader than intended

Overly broad trust usually shows up in a few repeat patterns: trusting an entire account when only one role is needed, allowing federated access without enough scoping, or permitting a service principal to assume a role even though the service is not tightly bound to the workload that should use it. In each case, the problem is not just excess reach, it is weak accountability for who can cross the trust boundary.

Cross-account trust deserves special attention because it often survives long after the original integration rationale has faded. If the role can be assumed by an external account, verify why that account still needs access, whether the trust is scoped to the minimum role or workload, and whether the external party can be replaced with a narrower trust pattern. A trust relationship that cannot be explained clearly is often a trust relationship that should be removed.

For role trust patterns, chaining and role assumption analysis, NHIMG’s Top 10 AWS IAM Mistakes is especially relevant because it highlights weak trust policies and other common AWS IAM failure modes.

When the role protects sensitive cloud access, compare the trust policy against actual production usage, not just infrastructure diagrams. The audit is stronger when you can prove the principal still needs the role, that the condition set still fits the workflow, and that removing the trust would not break a legitimate dependency.

Practitioner Guidance

What to verify: Confirm that each trusted principal maps to a current business owner, current system owner, or current integration. If nobody can explain why the trust exists, treat that as a finding rather than a documentation gap.

Decision rule: If the role can be assumed without a narrow condition set, tighten the trust before you worry about the downstream permissions attached to the role. Trust policy weakness is exposure at the entry point.

What good looks like: A well-audited trust policy has a small, explainable principal list, conditions that limit assumption to the intended workload or account, and a usage record that matches the intended design. If the policy is older than the integration it protects, revalidate it.

Practitioner takeaway: The most useful audit question is not just who is listed, but whether each listed principal still deserves to be trusted to cross the role boundary at all.

Related resources from NHI Mgmt Group

• How do you prevent the confused deputy problem in AWS IAM role trust policies?
• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• What are the signs that an AWS role trust policy is likely misconfigured?
• What is the difference between an AWS role trust policy and a permission policy?