Trust Policies

Understand who an AWS IAM role is willing to trust.

An IAM role has two security dimensions: what can the role do, and who can become the role. The role's permissions answer the first question. The role trust policy helps answer the second. Securitain makes external trust easier to investigate by connecting the role, its principals and its privilege context.

Where to find Trust Policies

The current Trust Policies view focuses on roles that Securitain represents as having external trust.

Role permission vs role trust

Principal
   ↓
Role Trust Policy
   ↓
AWS Role
   ↓
Role Permissions
   ↓
AWS Resources

External principals

A trust policy can refer to principals outside the local AWS account. Examples include:

• another AWS account
• a role in another account
• an external federated principal
• a broad wildcard principal

The exact trust semantics depend on the principal type and conditions.

Current Trust Policies view

The current product can show context such as:

• role name and ARN
• AWS account
• severity
• whether the role is admin-capable
• number of external principals
• all represented principals
• whether an Allow trust statement contains conditions
• last-used context where available

The view also exposes four summary cards: Roles with External Trust, External Principals, Admin Roles Exposed, and No Conditions.

Full-account trust

A common trust form is:

arn:aws:iam::<external-account-id>:root
→ Full account

This does not mean the external account's root user must personally log in. In an IAM principal context, this can establish trust to the external AWS account as a principal boundary, after which identity-side authorization inside that account can matter. This deserves review.

Full account does not automatically mean compromise

A broad account trust is not automatically exploitable. Successful role assumption can still depend on caller-side identity permission, trust-policy conditions, External ID where applicable, MFA or context conditions, organizational controls, and session/request context.

Specific external role

A more targeted relationship can look like:

arn:aws:iam::111122223333:role/ApprovedVendorRole
        ↓
CustomerSupportRole

Wildcard principals

A trust policy can contain a broad principal such as Principal: "*". This deserves urgent investigation.

Conditions

Trust conditions can constrain when role assumption is allowed. Examples include:

• External ID
• principal ARN
• AWS Organization membership
• MFA
• source identity or session context
• OIDC or SAML token claims

The correct condition depends on the trust pattern.

“No Conditions” in the current view

The current Trust Policies UI can label an externally trusted role as No conditions when the represented Allow trust statements do not include a condition block. This is a useful triage signal. It is not a full trust-policy quality score.

Administrative roles with external trust

External trust becomes more consequential when the target role is powerful:

External Principal
        ↓
Trust Policy
        ↓
Administrator Role
        ↓
High Consequence

Use Effective Permissions, IAM Blast Radius and Cross-Account Access to understand deeper consequence.

Trust Policies vs Cross-Account Access

Trust Policies vs Federation

Federation trust often uses Principal: Federated: ... rather than another AWS account principal. Use Federation, OIDC & SAML for identity-provider-specific analysis. Trust Policies remains useful for understanding the role-level trust structure.

Trust Policies vs Resource Policies

Example: vendor access

Vendor AWS Account
       ↓
Customer Support Role
       ↓
Limited Operational Access

Investigate: Is the external principal expected? Is the trust account-wide or role-specific? Are appropriate conditions present? Is an External ID appropriate? What can the target role do? Is the role still used? Is the vendor relationship still active?

Example: unexpected admin trust

1. 1

   Identify external account ownership

   Do not assume malicious intent before establishing ownership.

2. 2

   Review the trust principal

   Is it full account, specific role, federated provider or wildcard?

3. 3

   Review conditions

   Understand how trust is constrained.

4. 4

   Review target permissions

   Use Effective Permissions.

5. 5

   Review blast radius

   Understand consequence using IAM Blast Radius.

6. 6

   Review last-used context

   If available.

7. 7

   Confirm business purpose

   Then remediate or govern the trust.

Last-used context

The current view can include role last-used information where AWS provides it. Use this as supporting evidence. Do not interpret old or absent last-used data as conclusive proof that the relationship is unnecessary.

Evidence and limitations

Trust-policy analysis depends on:

• collected role trust documents
• principal parsing and account context
• supported condition context
• scan freshness

Related guides