A trust policy is the half of IAM role configuration that looks deceptively like a normal permissions policy but plays a completely different role: it does not grant the role any AWS permissions at all, it decides who — which account, which specific role or user, which AWS service, or which federated identity provider — is allowed to assume the role in the first place. IAM Trust Policy Generator builds exactly that shape of statement, gets the principal syntax right for each of the four common trust scenarios, and implements the real branching AWS requires between them.
Pick a principal type and the form adapts. An AWS account produces a root-account principal (arn:aws:iam::ACCOUNT:root) meaning any sufficiently-permissioned identity in that account can assume the role — the common shape for delegating within an organization or to a trusted partner account at the account level. A specific IAM role or user ARN narrows that down to exactly one identity. An AWS service — picked from a short preset list covering Lambda, EC2, ECS tasks, EKS, Glue, Step Functions and CodeBuild, or typed freely for any other service principal — is what lets a Lambda function or an EC2 instance profile assume the role on your behalf, the standard mechanism behind service roles. A Federated provider ARN, for SAML or OIDC identity providers, covers workforce SSO and things like GitHub Actions' OIDC-based AWS access.
The Federated case is where this tool does real conditional work rather than a cosmetic label swap: AWS requires a different STS action depending on how the federated caller authenticates. Choosing SAML sets the statement's action to sts:AssumeRoleWithSAML; choosing OIDC sets it to sts:AssumeRoleWithWebIdentity. Every other principal type — account, specific ARN, or AWS service — uses the ordinary sts:AssumeRole. That branching is implemented in the action-selection logic itself and covered by this page's self-tests, not asserted only in prose.
Two optional conditions cover the trust-policy hardening patterns that come up constantly in real deployments. An External ID adds a StringEquals condition on sts:ExternalId — the standard mitigation AWS documents for third-party cross-account access, preventing a confused-deputy attack where a third party is tricked into assuming a role on your behalf using someone else's credentials, because the exact agreed-upon external ID string must be present on every assume-role call. A Require MFA switch adds a Bool condition on aws:MultiFactorAuthPresent, so STS refuses the assume-role call unless the calling principal authenticated with multi-factor authentication. Both conditions can be combined in the same statement.
The most consequential structural detail this tool gets right by construction is the absence of a Resource field. Trust policies attach to a role and describe who may assume that specific role — the role is the implicit resource, and AWS trust policy statements use Principal in its place. Because the shared statement-building logic this page uses (the same engine behind the other policy tools here) defaults to filling in Resource: "*" for any statement that does not specify one, this generator explicitly strips that field back out after building the statement, so the JSON you copy never contains a stray Resource key that does not belong in a trust policy.
As with the other tools here, validation is structural rather than exhaustive: it confirms Version, a non-empty Statement array, a recognized Effect, an Action, and — since trust policies lack Resource — a Principal. It does not verify that an account ID, role ARN, or SAML provider ARN you typed actually exists in AWS. Everything runs client-side; account IDs and ARNs you enter are never uploaded.