AWS

Trustle reads IAM users, groups, roles, and policies, Identity Center users, groups, permission sets, and account assignments, Organizations accounts, AgentCore agents, and CloudTrail events from AWS. Trustle can add and remove group members, assign and remove permission sets and policies, create, suspend, and delete users, grant IAM roles, and let AgentCore agents sign in to Trustle.

Prerequisites

• An AWS account with permission to create IAM roles and policies. If you use AWS Organizations, use the management account. Only the management account can read the Organizations and Identity Center data.
• The region where AWS IAM Identity Center runs, if you use Identity Center.
• An identity provider connected in Trustle, for example Okta or Microsoft Entra ID. Trustle hides Cloud Providers until one is connected.

Trustle never receives an access key. Trustle assumes a role in your account and gets temporary credentials that expire after 1 hour.

Configure AWS

Step 1: Get the values from Trustle

1. In Trustle, go to Connections.
2. Under Cloud Providers, find AWS and click Connect.
3. Trustle shows Your Configuration Values.
4. Copy each value. Keep this Trustle tab open. You return to it in Connect in Trustle.

Value from Trustle	Where it goes in AWS
External ID	The trust policy in Step 3, <EXTERNAL_ID>
Trustle Bridge Role ARN	The trust policy in Step 3, <TRUSTLE_BRIDGE_ROLE_ARN>

Step 2: Create the permissions policy

1. In the IAM console, go to Policies. Click Create policy.

2. Select the JSON tab. Replace the default policy with this policy:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "TrustleReadAccess",
         "Effect": "Allow",
         "Action": [
           "bedrock-agentcore:GetAgentRuntime",
           "bedrock-agentcore:ListAgentRuntimes",
           "bedrock-agentcore:ListWorkloadIdentities",
           "cloudtrail:LookupEvents",
           "iam:GetAccessKeyLastUsed",
           "iam:GetGroup",
           "iam:GetGroupPolicy",
           "iam:GetLoginProfile",
           "iam:GetOutboundWebIdentityFederationInfo",
           "iam:GetPolicy",
           "iam:GetPolicyVersion",
           "iam:GetUser",
           "iam:GetUserPolicy",
           "iam:ListAccessKeys",
           "iam:ListAccountAliases",
           "iam:ListAttachedGroupPolicies",
           "iam:ListAttachedUserPolicies",
           "iam:ListGroupPolicies",
           "iam:ListGroups",
           "iam:ListGroupsForUser",
           "iam:ListMFADevices",
           "iam:ListPolicies",
           "iam:ListPolicyVersions",
           "iam:ListRoles",
           "iam:ListSSHPublicKeys",
           "iam:ListServiceSpecificCredentials",
           "iam:ListSigningCertificates",
           "iam:ListUserPolicies",
           "iam:ListUsers",
           "identitystore:DescribeGroup",
           "identitystore:DescribeGroupMembership",
           "identitystore:DescribeUser",
           "identitystore:GetGroupId",
           "identitystore:GetGroupMembershipId",
           "identitystore:GetUserId",
           "identitystore:IsMemberInGroups",
           "identitystore:ListGroupMemberships",
           "identitystore:ListGroupMembershipsForMember",
           "identitystore:ListGroups",
           "identitystore:ListUsers",
           "organizations:DescribeAccount",
           "organizations:DescribeOrganization",
           "organizations:ListAccounts",
           "organizations:ListAccountsForParent",
           "organizations:ListOrganizationalUnitsForParent",
           "organizations:ListRoots",
           "sso:DescribeAccountAssignmentCreationStatus",
           "sso:DescribeAccountAssignmentDeletionStatus",
           "sso:DescribePermissionSet",
           "sso:GetInlinePolicyForPermissionSet",
           "sso:ListAccountAssignments",
           "sso:ListAccountAssignmentsForPrincipal",
           "sso:ListAccountsForProvisionedPermissionSet",
           "sso:ListCustomerManagedPolicyReferencesInPermissionSet",
           "sso:ListInstances",
           "sso:ListManagedPoliciesInPermissionSet",
           "sso:ListPermissionSets",
           "sso:ListPermissionSetsProvisionedToAccount"
         ],
         "Resource": "*"
       },
       {
         "Sid": "TrustleProvisionAccess",
         "Effect": "Allow",
         "Action": [
           "iam:AddUserToGroup",
           "iam:AttachUserPolicy",
           "iam:CreateUser",
           "iam:DeactivateMFADevice",
           "iam:DeleteAccessKey",
           "iam:DeleteLoginProfile",
           "iam:DeleteSSHPublicKey",
           "iam:DeleteServiceSpecificCredential",
           "iam:DeleteSigningCertificate",
           "iam:DeleteUser",
           "iam:DeleteUserPolicy",
           "iam:DeleteVirtualMFADevice",
           "iam:DetachUserPolicy",
           "iam:RemoveUserFromGroup",
           "iam:TagUser",
           "identitystore:CreateGroup",
           "identitystore:CreateGroupMembership",
           "identitystore:CreateUser",
           "identitystore:DeleteGroup",
           "identitystore:DeleteGroupMembership",
           "identitystore:DeleteUser",
           "identitystore:UpdateUser",
           "sso:CreateAccountAssignment",
           "sso:DeleteAccountAssignment"
         ],
         "Resource": "*"
       },
       {
         "Sid": "TrustleManagementAccountSSOProvisioning",
         "Effect": "Allow",
         "Action": [
           "iam:AttachRolePolicy",
           "iam:CreateRole",
           "iam:DeleteRole",
           "iam:DeleteRolePolicy",
           "iam:DetachRolePolicy",
           "iam:PutRolePolicy",
           "iam:UpdateAssumeRolePolicy",
           "iam:UpdateRole",
           "iam:UpdateRoleDescription"
         ],
         "Resource": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"
       },
       {
         "Sid": "TrustleAccessToSSOProvisionedRoles",
         "Effect": "Allow",
         "Action": [
           "iam:GetRole",
           "iam:ListAttachedRolePolicies",
           "iam:ListRolePolicies"
         ],
         "Resource": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"
       },
       {
         "Sid": "TrustleGrantableRoleTrust",
         "Effect": "Allow",
         "Action": [
           "iam:GetRole",
           "iam:UpdateAssumeRolePolicy"
         ],
         "Resource": "arn:aws:iam::*:role/trustle-grantable/*"
       },
       {
         "Sid": "TrustleAgentSignInEnable",
         "Effect": "Allow",
         "Action": [
           "iam:EnableOutboundWebIdentityFederation"
         ],
         "Resource": "*"
       },
       {
         "Sid": "TrustleAgentTokenMintAttach",
         "Effect": "Allow",
         "Action": [
           "iam:AttachRolePolicy",
           "iam:DetachRolePolicy"
         ],
         "Resource": "arn:aws:iam::*:role/*",
         "Condition": {
           "ArnLike": {
             "iam:PolicyARN": "arn:aws:iam::*:policy/TrustleAgentTokenMint"
           }
         }
       },
       {
         "Sid": "TrustleAgentSignInRoleRead",
         "Effect": "Allow",
         "Action": [
           "iam:ListAttachedRolePolicies"
         ],
         "Resource": "arn:aws:iam::*:role/*"
       },
       {
         "Sid": "TrustleSAMLProviderAccess",
         "Effect": "Allow",
         "Action": [
           "iam:GetSAMLProvider"
         ],
         "Resource": "arn:aws:iam::*:saml-provider/*"
       },
       {
         "Sid": "TrustleAssumeRoleInMemberAccounts",
         "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
       }
     ]
   }

3. Click Next.

4. Enter the name TrustleIntegrationPermissions. Click Create policy.

Caution

The Step 2: Permissions Policy in the Trustle wizard does not have five actions that this policy has: iam:GetGroupPolicy, iam:DeleteVirtualMFADevice, identitystore:CreateUser, identitystore:UpdateUser, and sso:ListCustomerManagedPolicyReferencesInPermissionSet. Without them, Trustle cannot read inline group policies or customer managed policy references, delete virtual MFA devices, or create and suspend Identity Center users. Use the policy on this page.

Each statement does one job:

Permission	Required	What Trustle does with it
TrustleReadAccess	Yes	Imports IAM, Identity Center, and Organizations data. Reads credential metadata, such as MFA devices and access keys, to find dormant accounts. Reads CloudTrail events to find permissions that nobody uses. Verify Access uses iam:ListUsers.
TrustleProvisionAccess	Optional	Creates, suspends, and deletes users, changes group members, attaches and detaches user policies, and assigns permission sets. Before Trustle deletes an IAM user, it deletes the user’s keys, MFA devices, and inline policies. Without it, the connection is read-only.
TrustleManagementAccountSSOProvisioning	Optional	Assigns a permission set in the management account. Identity Center then creates the AWSReservedSSO_* role with the credentials of the caller. Applies only to roles under aws-reserved/sso.amazonaws.com/.
TrustleAccessToSSOProvisionedRoles	Optional	Reads the roles that Identity Center creates, to show the full path from a permission set to IAM. Without it, that path is incomplete.
TrustleGrantableRoleTrust	Optional	Grants and revokes IAM roles under the path /trustle-grantable/. See Step 5.
TrustleAgentSignInEnable	Optional	Turns on outbound web identity federation when you enable an AgentCore agent. Trustle never turns it off.
TrustleAgentTokenMintAttach	Optional	Attaches and detaches TrustleAgentTokenMint on the execution role of an agent. The condition limits the statement to that one policy.
TrustleAgentSignInRoleRead	Optional	Reads which policies a role has, so an attach or detach does not fail when the policy is already in place.
TrustleSAMLProviderAccess	Optional	Reads the SAML provider that Identity Center creates.
TrustleAssumeRoleInMemberAccounts	Optional	Reads IAM data in each member account of your organization through OrganizationAccountAccessRole. AWS creates this role when it creates an account in the organization. Trustle cannot use a role with a different name. Without it, Trustle reads only the management account.

Without Identity Center, you can delete the identitystore:* and sso:* actions and the two SSO statements. Without AWS Organizations, you can delete TrustleAssumeRoleInMemberAccounts.

AgentCore actions

Three actions in TrustleReadAccess read your Amazon Bedrock AgentCore agents. They cannot invoke, change, or deploy an agent.

Permission	Required	What Trustle does with it
bedrock-agentcore:ListWorkloadIdentities	Optional	Shows each workload identity as a principal, so an agent can hold entitlements. Without it, Trustle shows no agents.
bedrock-agentcore:ListAgentRuntimes	Optional	Records each agent runtime. Without it, Trustle shows no agents.
bedrock-agentcore:GetAgentRuntime	Optional	Reads the execution role of each runtime. Trustle keeps only the execution role ARN and the workload identity ARN. Without it, Trustle refuses role grants to agents.

The IAM action prefix is bedrock-agentcore, not bedrock-agentcore-control. Trustle discovers agents only in the management account and only in the connection’s region.

Step 3: Create the integration role

1. In the IAM console, go to Roles. Click Create role.

2. For Trusted entity type, select Custom trust policy.

3. Paste this trust policy. Replace <TRUSTLE_BRIDGE_ROLE_ARN> and <EXTERNAL_ID> with the values from Step 1.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "<TRUSTLE_BRIDGE_ROLE_ARN>"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "<EXTERNAL_ID>"
           }
         }
       }
     ]
   }

4. Click Next.

5. Search for TrustleIntegrationPermissions. Select it and click Next.

6. Enter the role name TrustleIntegration.

7. For Maximum session duration, select 1 hour.

8. Click Create role.

Only Trustle’s bridge role can assume this role, and only with your External ID. The External ID stops another Trustle customer from using your role.

Step 4: Create the agent token policy (optional)

Do this step only if you run agents on Amazon Bedrock AgentCore. The policy lets an agent sign in to Trustle with a token that AWS issues to it. The agent keeps no Trustle secret.

1. In the IAM console, go to Policies. Click Create policy.

2. Select the JSON tab. Paste this policy:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "TrustleAgentTokenMint",
         "Effect": "Allow",
         "Action": "sts:GetWebIdentityToken",
         "Resource": "*",
         "Condition": {
           "ForAllValues:StringEquals": {
             "sts:IdentityTokenAudience": ["https://mcp.trustle.io/mcp"]
           },
           "Null": {
             "sts:IdentityTokenAudience": "false"
           },
           "StringEquals": {
             "sts:SigningAlgorithm": "RS256"
           }
         }
       }
     ]
   }

3. Click Next.

4. Enter the name TrustleAgentTokenMint exactly. Do not set a path.

5. Click Create policy. Do not attach the policy to a role.

The Trustle wizard shows the same policy as Step 3 (only if you run agents on AWS Bedrock AgentCore): Agent Token Policy, with the audience for your Trustle environment.

When you enable an agent in Trustle, Trustle turns on outbound web identity federation for the account and attaches TrustleAgentTokenMint to the agent’s execution role. When the agent loses access, Trustle detaches the policy. Federation stays on, because other agents can use it.

Note

You create this policy, not Trustle. The integration role can attach only a policy with this name, and the policy allows only a token for Trustle. Trustle refuses to attach it to its own integration role or to a role in a different account.

You can also create the policy with the AWS CLI. Save the JSON as trustle-agent-token-mint.json, then run:

aws iam create-policy \
  --policy-name "TrustleAgentTokenMint" \
  --policy-document file://trustle-agent-token-mint.json

Step 5: Make roles grantable (optional)

Do this step only if you want Trustle to grant IAM roles. To grant a role, Trustle adds one statement to the role’s trust policy. The statement lets the grantee call sts:AssumeRole. To revoke, Trustle removes that statement and changes no other statement. Each Trustle statement has a Sid that starts with Trustle.

The grantee is an IAM user or the execution role of an AgentCore agent. Identity Center users cannot get a role grant.

1. Create each grantable role under the IAM path /trustle-grantable/. IAM cannot change the path of an existing role.

   aws iam create-role \
     --role-name "ReadOnlyAudit" \
     --path "/trustle-grantable/" \
     --assume-role-policy-document file://base-trust-policy.json

2. Give each role a narrow base statement. A trust policy needs at least one statement, so Trustle refuses to revoke its statement when it is the last one. Use a statement that trusts one admin role, or a break-glass statement such as this one:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "BreakGlassOnly",
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::<account-id>:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "aws:PrincipalTag/trustle-grantable-break-glass": "true"
           }
         }
       }
     ]
   }

3. For a role in a member account, make sure OrganizationAccountAccessRole in that account allows iam:GetRole and iam:UpdateAssumeRolePolicy on the role.

4. For a grantee in a different account from the role, attach a policy to the grantee that allows sts:AssumeRole on the role. Trustle does not add this policy.

Trustle can change the trust policy of every role under /trustle-grantable/. Put only roles that Trustle may grant there.

Caution

Do not use a base statement without a condition that trusts the account root, the account ID, or *. That statement lets every principal in the account assume the role, the grantee too. Trustle does not evaluate conditions. It treats a statement with a Condition as your restriction.

Step 6: Collect the values for Trustle

Trustle field	Where to find it in AWS	Example
AWS Account ID	The account menu in the upper-right corner of the console, or aws sts get-caller-identity --query Account --output text	123456789012
IAM Role ARN	IAM → Roles → TrustleIntegration → ARN	arn:aws:iam::123456789012:role/TrustleIntegration
Region	The region of IAM Identity Center. Without Identity Center, your main region.	us-east-1

Connect in Trustle

1. Return to the Trustle tab from Step 1. Click Continue.
2. Enter the values from Step 6. Trustle fills in IAM Role ARN from the account ID. Change it if your role has a different name.
3. Click Verify Access.
4. After the check passes, click Create Connection. Trustle names the connection AWS Account <account-id>.

Note

Verify Access checks that Trustle can assume the role and list one IAM user. It does not check every permission. Do the steps in Verify after the first sync.

To let an AgentCore agent sign in to Trustle, enable the agent in Trustle after the first sync. Trustle then makes the changes that Step 4 describes. If one change fails, Trustle does not enable the agent and shows the cause.

Update an existing connection

A connection that is older than the agent sign-in and role grant statements does not have them. The AWS connection page shows Trustle Can Set Up Agents with Yes or No. When the value is No, a banner lists the statements to add and the policy to create.

1. Add the missing statements from Step 2 to TrustleIntegrationPermissions.
2. If you run AgentCore agents, do Step 4.
3. On the connection page, click Check Again.

You do not need to connect the account again. The next sync uses the new permissions.

Verify

1. On the Connections page, open the AWS connection.
2. Wait for the first sync to finish.
3. Check that the user count matches the IAM users plus the Identity Center users in AWS.
4. If you use AWS Organizations, check that Trustle shows your member accounts.
5. If you run AgentCore agents, check that they show as principals.

To check the role from the AWS CLI:

aws iam get-role --role-name "TrustleIntegration"
aws iam list-attached-role-policies --role-name "TrustleIntegration"
aws iam get-policy --policy-arn "arn:aws:iam::<account-id>:policy/TrustleAgentTokenMint"

The last command applies only to AgentCore. Before you enable an agent, the policy has zero attachments.

If something is missing, see Troubleshooting.

Security notes

Note

• Trustle stores no AWS keys. Each session uses temporary STS credentials that expire after 1 hour.
• The External ID condition stops another Trustle customer from using your role.
• Grant only the statements for the features you use. Without TrustleProvisionAccess, Trustle cannot change your account.
• Trustle changes trust policies only for roles under /trustle-grantable/, and only its own statements.
• Trustle can attach only TrustleAgentTokenMint, which you create. It allows only a token for Trustle.
• CloudTrail logs every call that Trustle makes.
• To revoke all access at once, delete the TrustleIntegration role.

Troubleshooting

Verify Access fails

• Trust policy: the Principal must be the Trustle Bridge Role ARN, and sts:ExternalId must be the External ID from Step 1.
• IAM Role ARN: it must contain the same 12-digit ID as AWS Account ID.
• Permissions policy: TrustleIntegrationPermissions must be attached to the role. The check calls iam:ListUsers.

Verify Access passes, but Identity Center users are missing

• Region: it must be the region of IAM Identity Center. Trustle looks for Identity Center only in that region. If it finds none, it skips Identity Center without an error.
• Account: create the role in the management account.
• Permissions: the policy needs the identitystore:* and sso:* actions from Step 2.

Member accounts or Organizations data are missing

• Create the role in the management account, not in a member account.
• Keep the TrustleAssumeRoleInMemberAccounts statement.
• Make sure OrganizationAccountAccessRole exists in each member account and trusts the management account. AWS does not create it in an account that you invite to the organization.

Usage data is missing for some regions

Trustle reads CloudTrail events only in the connection’s region, for the last 30 days. A permission that someone uses only in another region shows as unused.

No AgentCore agents show

• The policy needs bedrock-agentcore:ListWorkloadIdentities and bedrock-agentcore:ListAgentRuntimes.
• The agents must run in the management account, in the connection’s region.

Trustle shows the agents after the next sync.

The connection page says “Trustle Cannot Set Up AWS Agents Yet”

The role does not have the agent sign-in statements, or TrustleAgentTokenMint does not exist. Add what the banner shows. Then click Check Again. See Update an existing connection.

Trustle cannot enable an agent

Trustle shows the cause. Check that:

• A policy named exactly TrustleAgentTokenMint exists, with no path.
• The role has the TrustleAgentSignInEnable, TrustleAgentTokenMintAttach, and TrustleAgentSignInRoleRead statements.
• The agent has its own execution role, not TrustleIntegration.

Trustle cannot suspend or create an Identity Center user

• Add identitystore:UpdateUser and identitystore:CreateUser from Step 2.
• Trustle cannot suspend a user that SCIM provisions from your identity provider. Suspend the user in the identity provider.

Trustle refuses a role grant

• The role must be under the IAM path /trustle-grantable/.
• For a grant to an agent, the policy needs bedrock-agentcore:GetAgentRuntime.
• For a role in a member account, OrganizationAccountAccessRole must allow iam:GetRole and iam:UpdateAssumeRolePolicy on the role.

A grantee cannot assume a role in a different account

Attach a policy to the grantee that allows sts:AssumeRole on the role. See Step 5.

Trustle refuses to revoke a role grant

The Trustle statement is the last statement in the trust policy. Add a narrow base statement, as Step 5 describes. Then revoke again.

None of these fixes work

Email support@trustle.com. Include the error message, the connection name, and the AWS Account ID and the IAM Role ARN. Never send a secret, key, or token.