IAM Trust Policy Auditor

A trust policy — stored on a role as its AssumeRolePolicyDocument — is the resource-based policy that answers one question: who is allowed to assume this role? It is separate from the role’s permission policies (which say what the role can do once assumed). A trust policy statement has a Principal (who is trusted), an Action (almost always sts:AssumeRole, sts:AssumeRoleWithSAML or sts:AssumeRoleWithWebIdentity) and an optional Condition. Getting the Principal or Condition wrong is how roles get handed to the wrong people, so the trust policy is one of the highest-leverage things to audit in an AWS account.

The confused deputy is a third party (the "deputy") that is tricked into misusing authority it legitimately holds. In AWS, a SaaS vendor often asks you to create a role trusting the vendor’s AWS account so it can manage resources for you. If the trust policy only names the vendor’s account, another of the vendor’s customers could ask the vendor to assume a role in YOUR account — the vendor is the confused deputy. The fix AWS designed for this is sts:ExternalId: the vendor gives you a unique ID, you put it in a Condition (StringEquals on sts:ExternalId), and the vendor must pass that exact ID when assuming the role. Because each customer’s ID is different, the vendor can no longer be tricked into assuming your role on someone else’s behalf.

A trust policy Principal of "*" means every principal is trusted to assume the role; {"AWS":"*"} means every AWS account in the world is trusted. Combined with sts:AssumeRole, that is a public handover of the role: any attacker with any AWS account can call AssumeRole and receive temporary credentials carrying all of the role’s permissions. It is one of the few genuinely critical misconfigurations because it requires no other flaw to exploit — the trust is open by design. A wildcard principal is only ever acceptable when paired with a strongly restrictive Condition, and even then naming the principals explicitly is far safer.

Federated trust (AssumeRoleWithSAML or AssumeRoleWithWebIdentity) trusts an identity provider, not a specific user — so without a Condition it trusts everyone the provider can issue a token for. For SAML, add a StringEquals condition on saml:aud (the audience, e.g. https://signin.aws.amazon.com/saml). For OIDC/web identity, pin both the audience and the subject: the provider’s :aud (often sts.amazonaws.com) and its :sub. For GitHub Actions, for example, the :sub should match the exact repository and ref (repo:org/name:ref:refs/heads/main), otherwise any repository under that OIDC provider — including forks or unrelated repos — could assume the role.

No. The entire audit runs client-side in your browser with JavaScript — the policy JSON is parsed and analysed locally, there are zero network calls, and nothing is uploaded, logged or stored on a server. That is why it is safe to paste a real production AssumeRolePolicyDocument. The analysis is a heuristic read of the trust-policy text only: it cannot see the role’s own account id, its permission policies, service control policies or runtime session context, so treat it as a fast first pass and confirm serious findings with AWS IAM Access Analyzer external-access findings.