[cchu-ld]

setup does not change a role that has no ldcli:managed tag. Before this change, the plan did not read the trust policy of that role. If the policy allowed only agent spaces in another region, setup made an agent space and then failed with Invalid STS role configuration. The new agent space then had no account association, no operator app, and no MCP server.

The plan now reads the trust policy of each unmanaged role that the run uses. The agent space role must allow sts:AssumeRole if the run associates the account. The operator app role must allow sts:AssumeRole and sts:TagSession if the run turns on or changes the operator app. If a policy does not let aidevops.amazonaws.com do this for an agent space in the current region, setup stops before it changes AWS. The error names the role and the fix.

The check stops the plan only if the policy clearly blocks the agent. If setup cannot read the policy, or the policy uses a condition operator that the check does not know, the plan continues. The check reads only the aws:SourceArn condition.

To test the change, run go test ./internal/awsdevops/. I found the problem in a development account. Its DevOpsAgentRole-AgentSpace role trusted only arn:aws:aidevops:us-east-1:..., and setup ran in us-west-2.

🤖 Generated with Claude Code

---

Note

Overview
aws-devops-agent setup now validates IAM trust policies during planning before any AWS changes, fixing a failure mode where setup could create an agent space and then die on account association with Invalid STS role configuration.

For unmanaged roles (no ldcli:managed tag) that the run still depends on, the plan reads each role’s assume-role policy and checks that aidevops.amazonaws.com can call the needed STS actions for agent spaces in the current region—sts:AssumeRole on the agent-space role when associating the account, and sts:AssumeRole + sts:TagSession on the operator-app role when enabling or changing the app. If the policy clearly blocks that (e.g. aws:SourceArn pinned to another region), setup stops with a message that names the role and how to fix it (broaden the trust or add the managed tag so ldcli updates the role).

Validation is conservative: unreadable policies, unknown condition operators, or roles not used by this run do not block the plan. New logic lives in trust.go; tests cover region mismatch, missing TagSession, and skipped checks when association/app steps don’t need a role.

README documents this pre-flight trust check for customer-owned roles.

^{Reviewed by Cursor Bugbot for commit 5832954. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cchu-ld]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5832954. Configure here.}

[cursor]

ArnEquals wildcards treated as exact

Medium Severity

conditionMatches treats ArnEquals as a literal string match. IAM treats ArnEquals and ArnLike as the same operator, and both honor * and ?. An unmanaged role that already allows arn:aws:aidevops:*:<account>:agentspace/* through ArnEquals is valid, but setup still stops before it changes AWS.

 

^{Reviewed by Cursor Bugbot for commit 5832954. Configure here.}