{"id":82464,"date":"2026-10-19T14:30:54","date_gmt":"2026-10-19T09:00:54","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=82464"},"modified":"2026-10-27T23:05:09","modified_gmt":"2026-10-27T17:35:09","slug":"aws-devops-agent-a-hands-on-guide-to-setup-iam-permissions-and-security","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/aws-devops-agent-a-hands-on-guide-to-setup-iam-permissions-and-security\/","title":{"rendered":"AWS DevOps Agent: A Hands-On Guide to Setup, IAM Permissions, and Security"},"content":{"rendered":"

Introduction<\/h2>\n

AWS DevOps Agent is Amazon’s agentic AI service for cloud operations \u2014 it can investigate incidents, analyze security posture, answer questions about your infrastructure, and take limited remediation actions, all from a chat interface inside the AWS console. What makes it interesting from an engineering standpoint isn’t
\njust the chat UI \u2014 it’s how AWS scoped its permissions. This post walks through setting up an Agent Space end to end, breaks down exactly what access the agent is (and isn’t) granted, and shows a few concrete use cases \u2014 including one you can try yourself with the CLI.<\/p>\n

 <\/p>\n

1. What Is an Agent Space?<\/h2>\n

An Agent Space is the container that defines what a DevOps Agent instance can see and do. Every Agent Space is tied to an IAM role in your account, and that role is what actually gates the agent’s reach \u2014 the chat interface is just the front end. Before creating one, it helps to think of an Agent Space as answering three questions:<\/p>\n

\u2022 Scope<\/strong> \u2014 which AWS account(s) and regions can this agent look at?
\n\u2022 Capability<\/strong> \u2014 can it only read\/investigate, or can it also act (create tickets, rotate secrets, etc.)?
\n\u2022 Identity<\/strong> \u2014 which IAM role does it assume, and what does that role’s policy actually allow?<\/p>\n

2. Step-by-Step Setup<\/h2>\n

Step 1 \u2014 Name the Agent Space and choose a response language<\/strong><\/span>
\nFrom the AWS DevOps Agent console, go to Agent Spaces \u2192 Create Agent Space. Give it a name (e.g. poc-agent-space), an optional description, and pick the language the agent should use when it writes findings and investigation output.<\/p>\n

 <\/p>\n

\".\"<\/p>\n

 <\/p>\n

Step 2 \u2014 Grant primary-account resource access<\/strong><\/span>
\nThis is the important part. You choose how the agent gets an IAM role in this account:<\/p>\n

\u2022 Auto-create a new DevOps Agent role<\/strong> \u2014 AWS attaches its own predefined, least-privilege managed policy (this is the default, and what we used here).
\n\u2022 Assign an existing role<\/strong> \u2014 bring a role you’ve already scoped down yourself; DevOps Agent verifies it before use.
\n\u2022 Create a role from a policy template<\/strong> \u2014 generate a starting policy you can edit further in the IAM console before attaching.
\nIn this walkthrough, AWS auto-created a role named DevOpsAgentRole-AgentSpace-8qqxm4yu for the agent’s backend\/investigation role.<\/p>\n

Step 3 \u2014 Tag the Agent Space (optional)<\/strong>
\n<\/span>Tags are for organizing and tracking Agent Space instances only \u2014 they don’t affect permissions. You can attach up to 50 key-value pairs.<\/p>\n

Step 4 \u2014 Enable the web app and choose its role<\/span><\/strong>
\nSeparately from the investigation role, DevOps Agent creates a second role that lets a signed-in IAM user in the console interact with the agent through the web chat UI. Same three options apply \u2014 auto-create, assign existing, or template. Here it auto-created DevOpsAgentRole-WebappAdmin-10xvlbbq.\".\"<\/p>\n

\".\"

.<\/p><\/div>\n

Step 5 \u2014 Review and create
\n<\/strong><\/span>The Advanced configuration section (collapsed by default) exposes any further networking or data-processing overrides. AWS DevOps Agent notes that it may transmit data to any AWS region globally for processing \u2014 worth flagging to your security\/compliance reviewers before you click Create.<\/p>\n

\".\"

.<\/p><\/div>\n

 <\/p>\n

3. Least-Privilege Access, Verified<\/h2>\n

It’s easy to accept an auto-created role at face value. It’s more useful to actually open it in IAM and read what it grants \u2014 so here’s what each of the two roles really contains.<\/p>\n

3.1 \u2014 The investigation role (AIDevOpsAgentAccessPolicy)
\n<\/strong><\/span><\/p>\n

\".\"

.<\/p><\/div>\n

This role has three policies attached, and the pattern across all of them is the same: read by default, write only where it’s unavoidable and tightly boxed in.<\/p>\n

\u2022 AIDevOpsAgentAccessPolicy (AWS managed)<\/strong> \u2014 hundreds of Describe*\/Get*\/List* actions across EC2, IAM, S3, Lambda, CloudWatch, GuardDuty, Security Hub, RDS, EKS, and more. This is what lets the agent “see” your environment. Only two write-capable actions exist in the entire policy: cloudtrail:StartQuery and support:CreateCase \u2014 both needed purely to run investigations and open AWS Support cases, not to modify infrastructure.
\n\u2022 AIDevOpsAllowSecretsManagerActionsPolicy<\/strong> \u2014 grants secretsmanager:GetSecretValue, but the Resource is scoped to a single secret path: arn:aws:secretsmanager:ap-south- 1:3xxxxxxxxx:secret:aidevops\/<agent-space-id>\/*. It cannot read any other secret in the account.\u2022 AIDevOpsCreateServiceLinkedRolePolicy \u2014 allows iam:CreateServiceLinkedRole, but only for one exact ARN (the Resource Explorer service-linked role). It cannot create arbitrary IAM roles.<\/p>\n

{\r\n\"Sid\": \"AIOPSServiceWriteAccess\",\r\n\"Effect\": \"Allow\",\r\n\"Action\": [\r\n\"cloudtrail:StartQuery\",\r\n\"support:CreateCase\"\r\n],\r\n\"Resource\": \"*\"\r\n}<\/pre>\n
3.2 \u2014 The web app \/ operator role (AIDevOpsOperatorAppAccessPolicy)<\/strong><\/span>\".\"<\/p>\n
\".\"
.<\/p><\/div>\n
This role is where the agent is allowed to take action \u2014 creating chats, backlog tasks, triggers, and knowledge items. But every one of those aidevops:* write actions is scoped with a condition, not a blanket allow:<\/p>\n
\"Resource\": \"arn:aws:aidevops:*:*:agentspace\/${aws:PrincipalTag\/AgentSpaceId}\",<\/span>\r\n\"Condition\": {<\/span>\r\n\"StringEquals\": {<\/span>\r\n\"aws:ResourceAccount\": \"${aws:PrincipalAccount}\"<\/span>\r\n}<\/span>\r\n\r\n<\/span><\/pre>\n
The ${aws:PrincipalTag\/AgentSpaceId} variable means this role can only touch the one Agent Space whose ID is stamped on the caller’s session tag \u2014 not any other Agent Space in the account, even ones created later withthe same policy. The secretsmanager:CreateSecret and iam-adjacent grants here are similarly boxed to the current account via aws:ResourceAccount.<\/p>\n
\".\"
.<\/p><\/div>\n
4. Use Cases<\/h2>\n
4.1 \u2014 Automated security gap analysis (from the console)
\n<\/span><\/strong>The most direct use case: ask the agent, in plain language, to review your account’s security posture.<\/span><\/span><\/p>\n
\".\"
.<\/p><\/div>\n
Typing \u201ccan you let me know the security gap in my account\u201d and confirming \u201cOpen a security investigation\u201d causes the agent to spin up a tracked investigation object \u2014 visible in a side panel with a Summary, Investigation timeline, Agent tasks, and Findings & evidence sections. Behind the scenes this is powered entirely by the read-only Describe*\/Get*\/List* actions from AIDevOpsAgentAccessPolicy: it pulls IAM configuration, checks for exposed resources, reviews encryption and monitoring settings, and flags network exposure \u2014 all without ever needing a write permission. The investigation here is scoped to IAM misconfigurations, exposed resources, encryption gaps, missing monitoring, and network exposure, exactly the categories you’d expect from a Security Hub-style review.<\/p>\n
4.2 \u2014 Incident timeline reconstruction<\/strong><\/span><\/p>\n
When something breaks, the agent can correlate CloudTrail and CloudWatch Logs to build a timeline \u2014 \u201cwho changed the security group on i-0123… in the last 24 hours, and what happened right after?\u201d This relies on cloudtrail:LookupEvents, cloudtrail:StartQuery, and logs:FilterLogEvents\/GetLogEvents, all already granted read-side. Equivalent CLI calls:<\/p>\n
# Find who touched a security group recently\r\naws cloudtrail lookup-events \r\n--lookup-attributes\r\nAttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \r\n--start-time 2026-09-06T00:00:00Z\r\n# Pull matching application log lines around the same window\r\naws logs filter-log-events \r\n--log-group-name \/app\/production \r\n--start-time 1725580800000 --end-time 1725667200000 \r\n--filter-pattern \"ERROR\"\r\n\r\n<\/pre>\n
 <\/p>\n
5. Best Practices Checklist<\/h2>\n
1. Keep the investigation role and the web-app\/operator role separate \u2014 never merge them into one.
\n2. Scope any custom write action to a specific resource ARN or a condition key (aws:ResourceAccount, principal tags) \u2014 never Resource: “*” for a write.
\n3. Re-run Access Analyzer’s policy generation against real CloudTrail data every quarter and prune unused actions.
\n4. Restrict Secrets Manager access to a path prefix scoped to the Agent Space ID, not the whole secrets namespace.
\n5. Review the \u201cmay transmit data to any AWS region globally\u201d notice with your compliance team before enabling the web app in regulated environments.<\/p>\n
 <\/p>\n
Conclusion<\/h2>\n
The AWS DevOps Agent setup flow looks like a simple three-screen wizard, but the IAM design behind it is the part worth studying: a near-total read footprint for visibility, a two-action write allowance for the agentitself, and every operator-facing write action locked to one Agent Space via a session tag condition. Whether or not you use AWS DevOps Agent specifically, that read-broad\/write-narrow\/condition-scoped pattern is a solid template for any agentic tool you give account access to.<\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction AWS DevOps Agent is Amazon’s agentic AI service for cloud operations \u2014 it can investigate incidents, analyze security posture, answer questions about your infrastructure, and take limited remediation actions, all from a chat interface inside the AWS console. What makes it interesting from an engineering standpoint isn’t just the chat UI \u2014 it’s how […]<\/p>\n","protected":false},"author":2010,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":5,"footnotes":""},"categories":[2348],"tags":[7765,8935],"class_list":["post-82464","post","type-post","status-publish","format-standard","hentry","category-devops-technology","tag-agent","tag-devopsagent"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t