Setting up a Claude-specific AWS profile

28 Jan, 2026

Yesterday I wrote about Claude and security, and mentioned that using AWS's¹ permissions system to restrict Claude is effective and straightforward.

Some readers might want to implement this but not be familiar with the process for doing so. Here is an attempt at a walkthrough:s

Go to the AWS console.
Go to IAM > Users.
Create a user.
Go to IAM > Policies.
Create a new policy appropriate for Claude and save it.
Go back to the user you created, go to "Add permissions," and attach the policy to the user.²
Attach the policy to the user.
Generate an access key for the user.³
Put the AWS access key ID, AWS secret access key, and region in the configuration file(s) the AWS CLI reads from (often ~/.aws/config and ~/.aws/credentials). Call the profile "claude" or whatever you like.
Modify Claude's settings in settings.json to include: {"env": "AWS_PROFILE": "claude" },
Make sure that you don't have other env variables (e.g., AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY_ID) that will override those.
Modify Claude's allowlist in settings.json to have a single Bash("aws *") instead of many aws commands.
Run aws sts get-caller-identity from Claude to verify that it is using the correct profile when it uses the AWS CLI.

Further notes:

This is not a complete security approach for Claude. You still have to worry about getting the policy right, about exfiltration of data it pulls, and any number of other things. This answers the narrow question of how to effectively restrict the interactions Claude directly has with AWS.
It's easy to accidentally feed Claude the wrong env variables. (It turns out that lots can go wrong with globals!) Do double-check that Claude is in fact using the correct profile.
Keep an eye on the CLI requests Claude actually makes: they sometimes suggest ways to modify the policy.
I've often needed to nudge Claude to make AWS CLI requests itself when it tells me to do some straightforward information retrieval. Such encouragement is a good candidate for AGENTS.md or similar.
Don't forget about money when you're thinking about security. When you're restricting Claude's behavior, think about preventing costs both with respect to security and your AWS bill. Here, also, monitoring and observability are necessary parts of an approach.

Lots of platforms have fine-grained permissions. I'm discussing AWS for concreteness and because of the maturity of its permissions system.↩
AWS will warn you that it is a better practice to create a group, associate the policy to the group, and then add the user to the group. Feel free to do this.↩
In many contexts, the modern best practice is to use authentication mechanisms other than long-lived access keys. Some of these approaches are workable with Claude and worth exploring. For the environments where I'm using Claude, access keys offer a good combination of security and simplicity, but long-lived keys create security risk.↩