I investigated the IAM permissions of DevOps Agent as of July 2026

Hello, this is Takayama.

Previously, I compiled information about IAM permissions for DevOps Agent as of June 2026.

https://dev.classmethod.jp/articles/devops-agent-iam-permissions-2026-06/

About a month has passed since then, and AIDevOpsAgentAccessPolicy received updates in July as well, so I've compiled the content as of July 2026.

Summary First

• AIDevOpsAgentAccessPolicy was updated to v8 (2026/06/26) and v9 (2026/07/02), with v9 being the latest at this time
• From v7 onward, there have been zero deletions — additions only.
  • In addition to expansions for ACM, Bedrock, EC2 Capacity Manager, and Glue, BCM Data Exports, Cost and Usage Report, and Direct Connect were added as newly covered services
• Additional Permissions expanded from 5 services to 8 services.
  • CloudWatch Logs, DynamoDB, and AWS Support are new additions, while Direct Connect was removed from the table and moved to the managed policy itself
• The Glue table reference that was blocked as of June was resolved in v9, and Athena queries via DevOps Agent can now reach engine execution (scanning)
  • However, the final retrieval of query results still fails due to insufficient write permissions to the S3 bucket where results are stored

Checking It Out

Let's check the differences from the previous version regarding DevOps Agent's managed policy and addable permissions.

Checking AIDevOpsAgentAccessPolicy Updates

The content of AIDevOpsAgentAccessPolicy can be confirmed from the following documentation.

https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIDevOpsAgentAccessPolicy.html

At the time of writing, it is at v9 with the update from 2026/07/02.

Past versions of the policy can be checked with the following commands.

# Check list of policy versions
aws iam list-policy-versions \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy

# Check policy document for a specific version (example: v9)
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy \
  --version-id v9

The update details for each version are as follows. v1 through v7 are carried over from the previous article, while v8 and v9 are the new additions.

In both the v7-to-v8 and v8-to-v9 updates, there were no deletions of existing actions or reductions through wildcarding — only additions and expansions.

What personally caught my attention was the expansion around Glue.

With 14 actions added in v8 and glue:GetPartitions and glue:GetTables further added in v9, the read scope for Glue Data Catalog has expanded considerably.

This is also relevant to the Athena verification described later, so I'll go into more detail below.

One more point: BCM Data Exports, Cost and Usage Report (CUR), and Direct Connect, which were added as new services in v8 and v9, are all read-only (Get*/Describe*/List*), and it seems like the scenarios where DevOps Agent can be used for cost analysis and network connectivity investigations are expanding.

Checking Additional Permissions

With DevOps Agent, users can grant additional permissions to extend the accessible scope beyond the managed policy.

The list of addable permissions can be confirmed in the documentation.

https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security-limiting-agent-access-in-an-aws-account.html#understanding-permission-guardrails

At the time of the previous blog post (June 25, 2026), the following permissions were listed as addable.

At the time of writing (2026/07/31), the following permissions are listed as addable.

This has grown from 5 services previously to 8 services, with CloudWatch Logs, DynamoDB, and AWS Support being new additions.

On the other hand, AWS Direct Connect has been removed from Additional Permissions.

As mentioned earlier, since equivalent Describe-type 9 actions were added to the managed policy itself in v9, it appears to have moved from Additional Permissions (opt-in permissions) to default allowance.

Re-testing Athena Queries

In the previous verification, even when athena:StartQueryExecution was permitted via Additional Permissions, glue:GetTable and glue:GetDatabase required for query execution were blocked by guardrails, making it impossible to even reach the query execution itself.

Since Glue permissions were significantly expanded in v9, let's try the same verification again.

I set up an Athena table for querying CloudTrail logs for testing, and made the following request in the DevOps Agent chat.

Please use Athena to run a query against the CloudTrail logs table. First, check the available Glue databases and tables, and if you find a CloudTrail logs table, run a simple query to count recent events (e.g., equivalent to SELECT COUNT(*) FROM <table> LIMIT 10) and tell me the results.
If a permission error occurs, please share the exact error message indicating which IAM action was denied.

(AdministratorAccess policy has been granted as Additional Permissions for testing purposes)

Looking at the DevOps Agent processing log, it proceeded as follows.

1. Called glue.get_databases, succeeded. Detected default database
2. Called glue.get_tables, succeeded. Detected default.cloudtrail_logs table
3. Called athena.get_work_group, succeeded. Confirmed the workgroup's OutputLocation (result output destination)
4. Called athena.start_query_execution, succeeded. Issued SELECT COUNT(*) as event_count FROM default.cloudtrail_logs
5. Polled athena.get_query_execution 24 times
6. The query engine execution itself ultimately completed (approximately 68.5 seconds, approximately 6.25 GB scanned), but the status was FAILED

The Glue database reference and table reference that were blocked as of June both succeeded this time.

It appears that the behavior improved due to glue:GetTables and other permissions added in v9, however the query ultimately failed, and DevOps Agent returned the following error.

Access denied when writing output to url:
s3://athena-query-results-123456789012-ap-northeast-1/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.csv

Please ensure you are allowed to access the S3 bucket.
If specifying an expected bucket owner, confirm the bucket is owned by the expected account.
If you are encrypting query results with KMS key, please ensure you are allowed to access your KMS key

DevOps Agent's own analysis comment was as follows.

Since 6.25 GB of data was scanned, we can confirm that the CloudTrail logs table exists and the data can be read. The problem is only with the "write destination" for the results.

While it was possible to reach Athena query execution (scanning by the engine), s3:PutObject at the stage of writing results to S3 returned Access Denied, making it impossible to retrieve the final results.

Organizing the progress points between June and July yields the following.

While the Glue-side errors were resolved, errors around write permissions to the Athena query result output bucket still remain.
Since the Additional Permissions table does not include anything equivalent to s3:PutObject, the next update is something to look forward to.
(Given that it would be a mutable operation, adding PutObject permissions seems like it might be difficult)

Incidentally, with a recent update the DevOps Agent Sandbox feature has become available, making it possible to use tools within DevOps Agent to run queries.

The following blog post tries out investigations using DuckDB on DevOps Agent, so please check it out as well.

https://dev.classmethod.jp/articles/devops-agent-sandbox-preview/

Closing

This time, I checked the changes in DevOps Agent's investigation permissions as of July 2026.

AIDevOpsAgentAccessPolicy continued to be updated through v8 and v9, with new services such as BCM Data Exports, CUR, and Direct Connect now being covered, centered around the expansion of Glue. Additional Permissions also expanded to 8 services, and the scope of investigation has been steadily broadening with additions like DynamoDB and AWS Support case reference.

For Athena queries, the Glue-side guardrail that was a barrier as of June has been resolved, and it is now possible to reach query engine execution.

On the other hand, the state where errors occur due to insufficient permissions for the S3 bucket where results are written still remains, so if you want to run queries with DevOps Agent itself, using the Sandbox feature might be a good option.

Since DevOps Agent permissions are continuing to be updated on a monthly basis, I'd like to keep tracking this area at regular intervals going forward.

That's all from Takayama (@nyan_kotaroo).