DEV Community: Jeff Tham

Shieldly Launch Offer: AI-Powered AWS IAM Security from $1.90/Month

Jeff Tham — Sat, 20 Jun 2026 18:44:42 +0000

We launched Shieldly last week — AI-Powered security analysis for AWS IAM policies, CloudFormation templates, and costs.

The reaction so far has been consistent: "Why does every other IAM tool require an enterprise contract before I can see a single finding?"

We agree. So here's our answer:

Free — no signup, no credit card

Paste an IAM policy into the IAM Advisor and get:

Risk score
Every finding explained in plain English
Prioritized remediation steps
Privilege escalation chain detection

No account needed. No AWS credentials required. Just paste and go: shieldly.io/app/iam

Advanced features — from $1.90/month

For teams that want continuous analysis across CLI, CI, and IDE:

New customer offer: code 90Off2M
→ 90% off your first 2 months
→ Pro plan: $19/mo → $1.90/mo
→ Team plan: $49/mo → $4.90/mo

Apply the code at checkout: shieldly.io/pricing

What you get on Pro

500 analyses/day (vs 20 free)
Advanced AI model (deeper reasoning on complex policies)
CLI: npx @shieldly/cli analyze policy.json
GitHub Action: catches IAM risks in every PR
VS Code extension: analysis as you write
CloudFormation security scanning
AWS cost analysis

Why we made the free tier genuinely useful

The engineer who wrote the policy is the one who can fix it. If the tool requires a purchase order before they can see a finding, the finding never gets fixed.

The demo exists to give that engineer the information — right now, for free. The paid plan exists for teams that want the same analysis baked into their CI pipeline.

Try it free at shieldly.io/app/iam or use code 90Off2M at checkout for 90% off your first 2 months.

AWS IAM Least Privilege: A Practical Guide to Scoping Down Policies

Jeff Tham — Sat, 20 Jun 2026 14:16:52 +0000

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.

AWS IAM Privilege Escalation: Common Paths and How to Catch Them

Jeff Tham — Sat, 20 Jun 2026 14:12:54 +0000

Originally published at shieldly.io/blog.

Privilege escalation is the moment a limited AWS identity gains permissions it was never meant to have. It rarely comes from a single "admin" policy. Far more often it hides in an innocent-looking combination of permissions that, chained together, let a low-privileged user, role, or compromised credential promote itself to full account control.

Because each individual permission looks reasonable on its own, these paths slip past human review and rule-based scanners alike. Below are the escalation patterns we see most often, why they work, and how to find them in your own policies.

What Makes Privilege Escalation Possible

Every escalation path exploits the same idea: some IAM actions let you change who can do what, or let you run code as a more privileged identity. If a principal can modify policies, attach permissions, pass roles, or create compute that assumes a role, it can usually reach administrator access in one or two steps.

The danger is contextual. iam:PassRole is harmless until it is paired with a service that runs code. iam:CreatePolicyVersion is fine until the principal can point it at a policy attached to itself. Risk lives in the combination, not the line.

The Most Common Escalation Paths

These are the high-frequency patterns documented in IAM privilege escalation research (including the well-known Rhino Security Labs catalog). If a non-admin identity holds any of them, treat it as effectively admin.

PassRole + RunInstances. iam:PassRole plus ec2:RunInstances lets a principal launch an EC2 instance with an administrator instance profile, then use that instance's credentials.
PassRole + Lambda. iam:PassRole with lambda:CreateFunction and lambda:InvokeFunction lets an attacker create a function that runs as a privileged role and execute arbitrary AWS API calls.
CreatePolicyVersion. iam:CreatePolicyVersion on a managed policy the principal is attached to lets it write a brand-new default version granting "Action": "*".
AttachUserPolicy / AttachRolePolicy. The ability to attach AdministratorAccess to yourself is a one-call path to full control.
PutUserPolicy / PutRolePolicy. Inline-policy write permission lets a principal grant itself any permission directly.
UpdateAssumeRolePolicy. Rewriting a privileged role's trust policy to trust the attacker, then assuming it.
CreateAccessKey. Minting access keys for a more privileged user.

What an Escalation Policy Looks Like

The policy below grants only two actions. Neither is *, and a quick glance might wave it through a code review. Together they are a direct path to administrator.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole",
        "ec2:RunInstances"
      ],
      "Resource": "*"
    }
  ]
}

The fix is to scope iam:PassRole to the specific, least-privileged roles the workload actually needs, and constrain it with a iam:PassedToService condition so the role can only be handed to the intended service.

Why Static Tools Miss These

Rule-based linters evaluate permissions in isolation: they flag a wildcard, an iam:*, or a known-bad action. But an escalation path is an interaction between permissions that are individually benign. Detecting it requires reasoning about the attack chain — what each permission unlocks when combined with the others in the same policy and the surrounding account.

How to Find Privilege Escalation in Your Policies

Inventory the dangerous actions. Search every policy for iam:PassRole, iam:Create*, iam:Attach*, iam:Put*, and iam:UpdateAssumeRolePolicy.
Scope and condition them. Replace Resource: * with explicit ARNs and add conditions that limit which roles and services are in play.
Analyze the whole policy, not the line. AI-Powered IAM analysis reads the full policy in context, detects multi-step escalation chains, and returns a risk score plus concrete remediation for each finding — the kind of reasoning rule engines can't do.

Find privilege escalation before attackers do — paste an IAM policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Why Wildcards in AWS IAM Policies Are Dangerous (and How to Fix Them)

Jeff Tham — Sat, 20 Jun 2026 14:10:36 +0000

Originally published at shieldly.io/blog.

The asterisk is the single most overused character in AWS IAM. It is quick to type, it makes errors disappear, and it is the root cause of a huge share of real cloud breaches. There are three wildcards that matter most — in the Action, Resource, and Principal fields — and each one grants far more than most teams realize.

1. Action: * — Every Operation, Including Destructive Ones

"Action": "*" grants every API operation across every service. Even the narrower "s3:*" is dangerous: it bundles read, write, DeleteObject, DeleteBucket, and PutBucketPolicy — meaning a credential intended to upload a file can also wipe the bucket or rewrite its access policy.

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

This is administrator access by another name. If you see it outside a dedicated, tightly controlled admin role, treat it as a critical finding.

2. Resource: * — Across Every Object in the Account

"Resource": "*" applies the granted actions to every resource the service has. s3:GetObject on * can read every object in every bucket — not just the one the workload needs. Scope to explicit ARNs:

"Resource": "arn:aws:s3:::my-app-uploads/*"

A few IAM and account-level actions genuinely require * because they have no resource ARN, but they are the exception. For the vast majority of policies, a real ARN belongs there.

3. Principal: * — Open to the Entire Internet

On resource-based policies (S3 bucket policies, KMS key policies, SQS, SNS, Lambda), "Principal": "*" means anyone — including anonymous, unauthenticated callers — unless a condition narrows it. This is how buckets end up publicly readable. If you must use it, always pair it with a strict condition such as aws:PrincipalOrgID or aws:SourceArn.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" }
  }
}

How to Scope Wildcards Down

Enumerate the actions you actually call. Use CloudTrail or IAM Access Analyzer to see which operations the identity uses, then list only those.
Name your resources. Replace * with specific ARNs; use path prefixes where you need a group of objects.
Constrain principals with conditions. Never leave Principal: * unconditioned on a resource policy.
Catch them automatically. Wildcards reappear constantly as policies change. Run them through an AI-Powered IAM analyzer that flags every risky wildcard, explains the real-world exposure it creates, and proposes a scoped replacement.

Catch IAM risks automatically — paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.