Fixed: AWS DevOps Agent UpdateAssociation AccessDenied After IAM Change

Problem

An IAM principal could see an AWS DevOps Agent association ARN in its policy but calls such as GetAssociation and UpdateAssociation still returned AccessDeniedException.

Root Cause

AWS changed authorization for association actions on September 10, 2026. These actions now authorize against both resources:

the specific association ARN
the parent Agent Space ARN

A policy scoped only to this pattern is no longer sufficient:

text

arn:aws:aidevops:us-east-1:111122223333:agentspace/*/association/*

The missing permission is not a second API action. It is coverage for the same action on the parent resource.

Fix

Allow the required actions on both ARN shapes:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DevOpsAgentAssociationAccess",
      "Effect": "Allow",
      "Action": [
        "aidevops:GetAssociation",
        "aidevops:UpdateAssociation",
        "aidevops:DisassociateService",
        "aidevops:ListWebhooks"
      ],
      "Resource": [
        "arn:aws:aidevops:us-east-1:111122223333:agentspace/SPACE_ID",
        "arn:aws:aidevops:us-east-1:111122223333:agentspace/SPACE_ID/association/*"
      ]
    }
  ]
}

Replace the account, Region, and Agent Space ID. Grant only the actions the operator actually needs; a read-only role should not receive UpdateAssociation or DisassociateService merely because they appear in the example.

If You Use Agent Space Tags

Associations do not carry the Agent Space tags. Put the tag condition on the statement covering the parent Agent Space and keep the association statement separate:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["aidevops:GetAssociation", "aidevops:ListWebhooks"],
      "Resource": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*/association/*"
    },
    {
      "Effect": "Allow",
      "Action": ["aidevops:GetAssociation", "aidevops:ListWebhooks"],
      "Resource": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/team": "platform"
        }
      }
    }
  ]
}

Verify the Fix

Reassume the role or refresh the session, then retry the smallest read operation first. Use CloudTrail and the IAM policy simulator to confirm the evaluated action and resources. If access still fails, check permission boundaries, service control policies, session policies, and explicit denies.

Do not fix the problem by granting aidevops:* on *. The dual-resource authorization pattern is precise and can remain least privilege.

What Fixed It

Adding the parent Agent Space ARN to the allowed resources resolved the error. For tag-based controls, splitting the parent and child resources into separate statements kept the tag condition valid and readable.