You can stop that.
AWS CLI-style profiles make switching between accounts fast, but without guardrails they open the door to human error. A simple typo or wrong export can route commands to the wrong environment. The fix isn’t more reminders. The fix is to structure access so dangerous profiles can’t be used where they shouldn’t.
The AWS CLI supports named profiles in ~/.aws/config and ~/.aws/credentials. By default, these profiles are equal in power. You type aws --profile prod and it runs. You type aws --profile dev and it runs. That flat world is fine for low-risk accounts but it doesn’t scale when production safety matters.
Restricted access means baking rules into the way profiles are managed. This can be done by separating credentials with OS-level permissions, locking down environment variables, and using role-based IAM policies that block unwanted actions at the source.
A strong approach:
- Store sensitive profiles in a protected credentials file readable only by a specific system user.
- Limit which profiles are available in certain shells or scripts by not exporting them to the environment.
- Use IAM conditions like
aws:SourceIp and aws:username to refuse commands even if a profile is somehow in use. - Audit session tokens and short-lived credentials to make persistence of risky access impossible.
Teams moving fast need speed without danger. Automating setup for restricted profiles ensures no one fat-fingers a delete-table in production. A clean profile isolation layer means safe defaults and no trust in memory alone.
You don’t have to wire this by hand for every workstation. There are tools now that give you AWS CLI-style profiles with built-in, enforced restrictions. With the right setup, policy, and enforcement in one place, you can see it live in minutes with hoop.dev.