I'm evaluating ways to let tools such as Claude Code, Codex, OpenCode, or Cursor work with AWS without giving them the same permissions as the developer running them. Our developers currently have limited write access in development and nonproduction accounts, but I want AI agents to have a much smaller blast radius—ideally read-only access, even when the user's normal AWS role can make changes.
Are teams creating dedicated read-only roles for agents? If so, how do you reliably force the agent to use that role instead of credentials with write access? I'm also interested in practical controls such as sandboxing, separate users or containers, managed workspaces, and keeping deployments behind an infrastructure-as-code approval workflow.
5 Answers
Create a separate read-only role in each account with access limited to the services and resources the agent actually needs. A separate bootstrap role can assume those roles, but be careful: if write-capable profiles or credentials remain available on the same host, the agent may discover and use them. Isolation by OS user, container, sandbox, or managed workspace is important; simply pointing the tool at a different AWS config is not a dependable enforcement mechanism.
Keep privileged roles off local machines entirely. Developers can use read-only credentials locally, while administrative or write operations require an AWS-managed workspace with centrally controlled software and access. Allow AI tools only in the restricted environment, where the organization controls which credentials and executables are available.
For experimentation, a separate AWS account can provide a clean boundary, with aggressive budget monitoring and short-lived agent roles that are revoked after testing. It is less practical when the test depends on a large existing environment, so in that case a sandboxed session plus read-only roles and an approval-based deployment pipeline is usually more realistic.
A strong boundary is to keep agents away from AWS entirely. Give them access to the Terraform repository, let them propose changes, and require a reviewed merge request before Atlantis or another CI system runs the plan and apply. This makes the agent useful for infrastructure work while ensuring deployments happen through a controlled pipeline rather than from a developer laptop.
That handles deployments well, but developers may still need a safe way to test a new service or configuration interactively before committing it to Terraform.
Run the agent inside a sandbox, such as bubblewrap or a locked-down container, so it cannot see the developer's active AWS credentials. When direct account inspection is needed, assume a dedicated read-only role and inject only those temporary credentials into the sandbox session. Keep all changes limited to infrastructure code and prevent the agent from running apply commands.
That is the concern I have too. A configuration convention alone cannot prove that every tool or user session is using the restricted role.