IAM least privilege for automation: roles, not keys

IAM least privilege for automation

The rule

No root credentials and no long-lived IAM user keys in agent context, code, chat logs, or CI secrets. Ever. If an agent needs AWS access, it assumes a role.

How to grant access

1. EC2 work goes through an instance profile (a role attached to the instance).
2. ECS work goes through a task role. Lambda work goes through its execution role.
3. CI (GitHub Actions and friends) uses OIDC federation to assume a role per run. No stored keys.
4. Humans get IAM users or SSO with MFA. Root is for account setup and break-glass only, locked behind MFA.

Least privilege in practice

1. Start with an AWS managed policy that roughly fits the job.
2. Narrow it: only the actions the job needs, only the resources it touches. Use ARNs like arn:aws:s3:::[bucket]/[prefix]/ rather than .
3. Run IAM Access Analyzer on the role periodically and remove unused permissions.
4. Delete access keys that are not attached to a human workflow. If a key must exist, rotate it on a schedule and alert on keys older than 90 days.

What goes wrong

Agents handed AdministratorAccess "to keep things simple" become the blast radius. Scope the role to the task before the first run, not after the first incident.

Distills the AWS IAM best practices: protect root credentials, require MFA, apply least-privilege permissions, prefer IAM roles over long-term credentials, and use OIDC federation for workloads outside AWS. Verified against the live IAM user guide. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html