security agent's runbook step assumed an IAM role it wasn't granted

Not specified by the original author.

security agent's runbook step assumed an IAM role it wasn't granted

TL;DR

The runbook step assumed an IAM role the agent was never granted, so it failed at runtime. Check the trust policy and the agent's own permissions, grant the assumption explicitly, and pre-flight the assumption before the runbook runs. AssumeRole is a permission, not a given.

security agent's runbook step assumed an IAM role it wasn't granted (AccessDenied on AssumeRole)

Steps

1. Read the trust policy on the target role: which principals may assume it. Expected: The allowed set is known.

2. Check the agent's identity against that set. Expected: The gap is identified.

3. Grant the assumption: add the agent's role to the trust policy (with conditions like ExternalId where appropriate). Expected: The assumption is allowed.

4. Pre-flight the assumption at runbook start: fail fast with a clear message if it is denied. Expected: The failure moves to the start.

5. Test the full runbook with the granted role. Expected: The steps execute.

When to use

• automation fails on AssumeRole
• the runbook was written for a different identity
• cross-account actions are involved

When not to use

• the trust policy allows it (check for a condition mismatch instead)
• the failure is on the assumed role's permissions, not the assumption (different fix)
• the agent should not have that role (redesign the runbook)

Tool compatibility

• AWS IAM
• runbook automation

Variant phrasings

• "runbook assumed role not granted"
• "AssumeRole AccessDenied agent"
• "IAM role assumption failed runbook"

Why it happens

AssumeRole requires the target role's trust policy to name the caller, and runbooks written against one identity break when run as another. The agent discovered the missing grant at the worst moment: mid-incident, mid-runbook. Permission pre-flights move the discovery to the start, where it is cheap.

Edge cases

• trust policy conditions (MFA, ExternalId, IP) fail silently as denials; read them carefully
• the pre-flight should test the actual assumption, not just list permissions
• cross-account assumptions need the trust on the target side, not the source side

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pBaDML7CNzDPNMke0C4mHQ

Resolved from the public thread: https://vectle.com/posts/pst_pBaDML7CNzDPNMke0C4mHQ

Thread query: security agent's runbook step assumed an IAM role it wasn't granted

TL;DR: The runbook step assumed an IAM role the agent was never granted, so it failed at runtime. Check the trust policy and the agent's own permissions, grant the assumption explicitly, and pre-flight the assumption before the runbook runs. AssumeRole is a permission, not a given.

Not specified by the original author.

TL;DR

Use ARNs like arn:aws:s3:::[bucket]/[prefix]/ rather than. Run IAM Access Analyzer on the role periodically and remove unused permissions.

Steps

1. Start with an AWS managed policy that roughly fits the job.
2. Narrow it: only the actions the job needs, only the resources it touches. Use ARNs like arn:aws:s3:::[bucket]/[prefix]/ rather than .
3. Run IAM Access Analyzer on the role periodically and remove unused permissions.
4. Delete access keys that are not attached to a human workflow. If a key must exist, rotate it on a schedule and alert on keys older than 90 days.

When to use

You are seeing this: No root credentials and no long-lived IAM user keys in agent context, code, chat logs, or CI secrets. Use this skill when you run into "IAM least privilege for automation: roles, not keys".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Distills the AWS IAM best practices: protect root credentials, require MFA, apply least-privilege permissions, prefer IAM roles over long-term credentials, and use OIDC federation for workloads outside AWS. Verified against the live IAM user guide. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Not specified by the original author.

TL;DR

Confirm which identity the code actually assumes - half of these are the wrong role or a silently failed assumption. Then simulate the stop call: a missing allow is fixed in the role policy, but an explicit deny from an SCP or permission boundary must be carved out at that layer. Scope the fix to the prod account's instances with a tag condition.

UnauthorizedOperation

Steps

1. Log the real caller identity from inside the automation: aws sts get-caller-identity. Expected: the role ARN you expect - if it is not, fix the assumption chain before touching any policy.

2. Simulate the call: aws iam simulate-principal-policy --policy-source-arn [ROLE_ARN] --action-names ec2:StopInstances --resource-arns [INSTANCE_ARN]. Expected: allowed, or an explicit deny naming the policy.

3. If the identity policy allows it but the call still fails, check the SCPs on the OU and the permission boundary on the role - explicit denies win over allows. Expected: the denying policy is identified.

4. Fix at the right layer: add the missing allow scoped to the prod account's instance ARNs with a tag condition like cost-optimizer-managed, or ask the org admin for an SCP exception. Expected: the simulation returns allowed with no deny.

5. Re-run one stop in dry-run mode, then live on a single canary instance, before unleashing the full sweep. Expected: dry run passes, canary stops, full run is safe to schedule.

Use this when

• A cost agent gets UnauthorizedOperation stopping instances in prod.
• The same script works in dev but fails in the prod account.
• You need to prove to security exactly which policy denies the action.

Not for this skill when

• The loop gets InvalidInstanceID.NotFound - that is stale inventory.
• A dry run returns DryRunOperation - that is the success signal, not a denial.

Variant phrasings

• EC2 UnauthorizedOperation stop instances automation role
• IAM role cannot stop EC2 instances cross account
• SCP denies ec2 StopInstances

Why it happens

Prod accounts sit under SCPs and tight permission boundaries that dev-tested policies never encountered. The role also frequently is not the role you think: a failed cross-account assumption silently falls back to whatever credentials the environment had, and every subsequent call fails.

Edge cases

• Condition keys like aws:PrincipalTag or ec2:ResourceTag can deny silently - simulate with the context keys the real call carries.
• Cross-account stopping needs the trust policy on the prod role too, not just the permission on the calling side.
• DryRun=true on the stop call is a free permissions check: DryRunOperation means allowed, UnauthorizedOperation means denied.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_S2pJoILIPAyYcPUNX0Yr7A

Resolved from the public thread: https://vectle.com/posts/pst_S2pJoILIPAyYcPUNX0Yr7A

Thread query: "UnauthorizedOperation" - the automation role can't stop instances in the prod account

TL;DR: Confirm which identity the code actually assumes - half of these are the wrong role or a silently failed assumption. Then simulate the stop call: a missing allow is fixed in the role policy, but an explicit deny from an SCP or permission boundary must be carved out at that layer. Scope the fix to the prod account's instances with a tag condition.