I'm evaluating ways to let tools such as Claude Code, Codex, OpenCode, or Cursor work with our AWS environments 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 an AI agent's blast radius to be much smaller—ideally read-only, even when the developer has broader permissions. Are teams creating dedicated read-only IAM roles for agents? If so, how do you reliably force the agent to use that role instead of accidentally inheriting the developer's active credentials? I'm also interested in approaches involving infrastructure as code, sandboxing, containers, separate users, managed workspaces, or isolated AWS accounts.
5 Answers
Run the agent inside a sandbox, such as bubblewrap or a container, where it cannot see the developer’s normal AWS credential files or environment variables. When direct account access is needed, manually assume a dedicated read-only role and provide only those temporary credentials to the isolated session. Keep all write and apply operations in the infrastructure pipeline.
Create a dedicated read-only IAM role in each account with only the services and resources the agent needs to inspect. A separate CLI role can assume those roles. The important part is isolating the agent from any writable profile on the same machine; otherwise it may discover or inherit credentials with more authority. A separate OS user, container, sandbox, or managed workstation can help enforce that separation.
For high-risk experimentation, a separate AWS account provides the cleanest isolation. Give the agent temporary IAM access there, monitor spending closely, and revoke the role after the test. It can be inconvenient when the experiment depends on a tightly connected existing environment, so account-level isolation may be more practical for independent prototypes than for full end-to-end testing.
A separate account would be safer, but reproducing all of our connected resources there would be too expensive and time-consuming for routine testing. I’m leaning toward sandboxing plus a narrowly scoped read-only role for access to the existing environment.
A strong boundary is to keep agents away from AWS entirely. Let them read and modify Terraform, then require changes to go through merge requests and review. A controlled CI system such as Atlantis can perform the plan and apply using its own AWS role, so the agent never receives deployment credentials.
That makes sense for normal deployments. The harder case is when developers need to test something interactively—like a new managed-service version—before investing in the Terraform changes. I’d still need a safe way to provide temporary access for those experiments.
Keep powerful roles off developer laptops altogether. Use read-only credentials locally, and require administrative or write-capable work to happen inside centrally managed workspaces where the approved tools, credentials, and network access are controlled by IT. This reduces the chance of an agent making a high-impact change even if it is prompted incorrectly.
That credential-isolation issue is exactly what concerns me. Telling people to select the read-only profile is useful, but it doesn’t prove the agent cannot access a writable profile if both are available to the same user.