How to Find and Fix Over-Permissive IAM Roles in AWS (2026 Guide)

Why are over-permissive IAM roles so dangerous?

Because IAM is the real perimeter in the cloud. A misconfigured security group exposes one service; an over-permissive role exposes everything that role can touch. When an attacker phishes a credential, exploits an SSRF on an EC2 instance, or pops a leaked access key, the blast radius is defined entirely by what that identity is allowed to do.

The problem is that permissions only ever ratchet up. Someone grants s3:* to “unblock” a deploy, or attaches AdministratorAccess “just for now,” and it’s never walked back. Over months, most of a role’s permissions go unused — but every one of them is still available to an attacker who lands on it.

How do I find over-permissive roles in the console?

1. Open IAM → Access Analyzer and enable an unused access analyzer (free). It flags unused roles, unused permissions, and unused access keys across the account — the fastest way to see where privilege has drifted.
2. In IAM → Policies, filter to customer-managed policies and open each one’s JSON. Anything with "Action": "*" or "Resource": "*" is a wildcard to justify or remove.
3. Check who holds admin: open the AWS-managed AdministratorAccess policy and review its Entities attached tab. Every human and role there can do anything in the account.

Caveat: this is one account, reviewed by hand, once. With multiple accounts — most organizations — you repeat it forever, and drift reappears the week after you finish. That’s the gap automation fills.

How do I check roles with the AWS CLI?

Two questions matter: which policies grant wildcards, and which permissions a role has actually used.

# who is attached to AdministratorAccess?
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# read a customer-managed policy document
aws iam get-policy-version \
  --policy-arn arn:aws:iam::ACCOUNT_ID:policy/POLICY_NAME \
  --version-id v1

# which services has this role actually used? (least-privilege evidence)
aws iam generate-service-last-accessed-details --arn ROLE_ARN
aws iam get-service-last-accessed-details --job-id JOB_ID

If the service-last-accessed report shows a role has touched three services in the last year but its policy grants twenty, you have your list to trim. Treat any policy statement with "Action": "*" and "Resource": "*" together as effectively admin, regardless of what the role was named for.

How do I fix an over-permissive role?

In order of preference:

1. Scope actions and resources. Replace the wildcard with the specific actions and resource ARNs the workload needs:

   {
     "Effect": "Allow",
     "Action": ["s3:GetObject", "s3:PutObject"],
     "Resource": "arn:aws:s3:::app-uploads/*"
   }

   not "Action": "s3:*" on "Resource": "*".
2. Generate a policy from real usage. IAM Access Analyzer can build a least-privilege policy from the role’s CloudTrail history, so you scope to what was actually called instead of guessing. Review it, then apply it as a new version.
3. Add guardrails you can’t accidentally exceed. Attach a permissions boundary to roles so even a broad inline policy can’t grant more than the boundary allows, and prefer short-lived role sessions over long-lived access keys.

Roll changes out behind a test — over-tightening a production role breaks deploys. Trim, deploy to staging, watch for AccessDenied in CloudTrail, then promote.

How do I keep roles least-privilege over time?

Point-in-time cleanups decay as fast as you finish them. Three durable controls:

• Preventive: a Service Control Policy (SCP) in AWS Organizations that denies attaching AdministratorAccess or creating "*":"*" policies outside a break-glass admin role.
• Detective: continuous scanning. A CSPM tool checks every role in every account on a schedule and flags new wildcards the day they appear — including the ones a teammate adds next quarter to unblock a deploy.
• Pipeline: scan Terraform/CloudFormation before it applies. Catching "Action": "*" in a pull request is cheaper than catching it after an incident.

Sovereign Observer does the detective and pipeline layers out of the box, and goes one step further: it shows which over-permissive roles are actually reachable — chained from internet exposure through to your data in an attack path — so you fix the role that matters first, not the alphabetical one.