how to give an agent least-privilege cloud access

TL;DR

Give the agent a dedicated IAM role with exactly the actions its job needs, scoped to the exact resources, with short session durations and no long-lived keys. Start from an explicit deny-all and add Allows one at a time; simulate each addition before granting it. An agent with PowerUserAccess is not least privilege, it is a shortcut.

Error / query

how to give an agent least-privilege cloud access

Use this skill when

• an agent needs AWS, GCP, or Azure API access for ops work
• you are writing the IAM policy for an automation role
• a security review flagged an over-broad agent role
• an agent moves from staging to production and needs its access re-scoped

Not for this skill when

• the agent only needs Kubernetes APIs (scope RBAC instead)
• you want the agent to share a human's credentials (never do this)
• the goal is to bypass permission boundaries for convenience (do not do this)

Steps

Step 1: Create a dedicated role for the agent, nothing shared

aws iam create-role --role-name sre-agent-prod --assume-role-policy-document file://trust-policy.json
aws iam get-role --role-name sre-agent-prod --query "Role.Arn"

Expected: the role ARN returned. The trust policy should allow assumption only from the agent's known identity (the workload identity or instance profile), never from arbitrary principals.

Step 2: Write the policy with explicit actions and resource ARNs

aws iam create-policy --policy-name sre-agent-prod-policy --policy-document file://agent-policy.json
aws iam attach-role-policy --role-name sre-agent-prod --policy-arn [POLICY_ARN]

Expected: policy created and attached. The document lists exact actions (ec2:DescribeInstances, not ec2:) on exact ARNs (the prod VPC's instances, not ""); start read-only and add write actions only with a written justification.

Step 3: Simulate the policy before the agent uses it

aws iam simulate-principal-policy --policy-source-arn [AGENT_ROLE_ARN] --action-names ec2:TerminateInstances s3:GetObject --resource-arns "*"

Expected: allowed only for the intended actions, denied for everything else. If TerminateInstances comes back allowed and the agent's job is read-only monitoring, the policy is wrong; fix it now, not after an incident.

Step 4: Use short-lived sessions, never static keys

aws sts assume-role --role-arn [AGENT_ROLE_ARN] --role-session-name sre-agent --duration-seconds 900

Expected: temporary credentials with a 15-minute expiry. No access keys stored in the agent's config, env files, or working directory; the agent re-assumes as needed and a leaked session dies on its own.

Step 5: Review actual usage and trim quarterly

aws iam generate-service-last-accessed-details --arn [AGENT_ROLE_ARN]
aws iam get-service-last-accessed-details --job-id [JOB_ID] --query "ServicesLastAccessed[].[ServiceName,LastAuthenticated]"

Expected: a per-service last-used timestamp. Anything unused in 90 days gets removed from the policy; least privilege is a maintenance habit, not a one-time setup.

Variant phrasings

"iam role for ai agent best practices"

Dedicated role, exact actions, exact resources, conditions on source identity, short sessions, quarterly trimming. The checklist above is the practice.

"agent needs s3 access but nothing else"

Allow s3:GetObject and s3:ListBucket on the one bucket ARN, add a condition tying it to the agent's role session, deny everything else by default.

"scope down an existing over-broad agent role"

Run step 5 to find what it actually uses, write the tight policy from that evidence, simulate, then swap the policy and watch for denied calls for a week before deleting the old one.

Why it happens

Agents get over-broad access because "just give it admin so it stops erroring" is faster than thinking through the permission set, and agents are very good at hitting permission errors that tempt the shortcut. But an agent's error rate on choosing the right action is nonzero forever, so the blast radius must be bounded by policy, not by hope. Least privilege converts each agent mistake from "catastrophic" to "a denied API call in the log".

Edge cases and pitfalls

• Resource-level permissions do not exist for every action; when an action only supports "*", add a condition (like aws:RequestedRegion or a resource tag) to narrow it.
• Permission boundaries on the role cap what its policies can ever grant; use one so a future policy edit cannot accidentally widen access.
• Cross-account roles need the trust policy reviewed as carefully as the permission policy; a loose trust policy voids everything else.
• Agents that call sts:AssumeRole chaining can extend sessions; set the role's max session duration low and monitor for chaining.
• Do not put the agent role's ARN in prompts or tickets more broadly than needed; it is not a secret, but obscurity still helps against confused-deputy mistakes.

Provenance

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