Originally published at shieldly.io/blog.

"Least privilege" — granting an identity only the permissions it needs and nothing more — is the most repeated advice in AWS security and the least often followed. Not because teams disagree with it, but because manually scoping every policy is tedious, and an over-broad policy "just works." Here is a practical workflow for getting there without grinding your team to a halt.

Start From Zero, Not From Star

The most common mistake is to begin with a broad grant and plan to tighten it "later." Later never comes. Start with an empty policy and add only the specific actions a workload fails without. It is far easier to add a missing permission than to discover which of a hundred granted permissions are actually unused.

Scope Three Things: Actions, Resources, Conditions

• Actions. Replace service wildcards like s3:* with the exact operations needed — s3:GetObject, s3:PutObject. Avoid iam:* entirely outside of break-glass admin roles.
• Resources. Replace Resource: "*" with explicit ARNs. A policy that needs one bucket should name that bucket, not all of S3.
• Conditions. Add condition keys to constrain when and from where a permission applies — aws:SourceIp, aws:PrincipalOrgID, aws:SecureTransport, or s3:prefix.

Before and After

The over-permissive version — broad and easy, but a blank cheque:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

The least-privilege version — scoped to the actions, the bucket, and TLS only:

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

Be Careful With AWS Managed Policies

AWS managed policies are convenient but deliberately broad — they are designed to fit many use cases, not yours. Attaching AmazonS3FullAccess to grant read access to one bucket hands over delete and policy-write permissions across every bucket in the account. Prefer customer-managed policies you can scope precisely, and reserve managed policies for cases where their breadth is genuinely required.

Use the Right AWS Signals

• Last-accessed data. IAM Access Advisor shows which services a role has actually used. Permissions for services that have never been touched are safe candidates to remove.
• IAM Access Analyzer. Generates least-privilege policies from CloudTrail activity and flags resources shared outside your account or organization.

Make It Continuous, Not a One-Off

Least privilege drifts. New features add permissions, copied snippets reintroduce wildcards, and "temporary" grants become permanent. Bake policy review into the places changes happen — pull requests, CI, and IaC synth — so a regression is caught before it ships rather than in an annual audit.

AI-Powered IAM analysis can score each policy against least-privilege principles, explain why a grant is too broad, and propose a scoped-down replacement — in the CLI, a GitHub Action, the VS Code extension, or CDK Guard, so least privilege gets enforced on every change instead of forgotten.

Scope down your IAM policies in seconds — paste one into Shieldly's free AI-Powered analysis. No signup, no credit card.