DEV Community: Shieldly

What the IAM Policy Simulator Actually Tells You (and What It Doesn't)

Shieldly — Wed, 22 Jul 2026 13:11:41 +0000

AWS ships a policy simulator: paste a principal, an action, a resource, and it tells you whether that specific request would be allowed or denied. It runs the same evaluation logic AWS uses at runtime, including identity policies, resource policies, permission boundaries, and SCPs. Teams reach for it before shipping a policy change, treat a clean result as a green light, and move on.

That's a narrower guarantee than it looks like.

What the Simulator Is Actually Answering

The simulator answers one question at a time: given this exact principal, this exact action, this exact resource, what's the decision? That's genuinely useful — it's the same logic AWS applies at runtime, so a simulated "Allow" is a real allow, not a guess.

But "is this one request permitted" and "is this policy safe to ship" are different questions. A policy can pass every simulated check you think to run and still grant far more than you intended, because the simulator only evaluates the specific combinations you feed it.

Where the Gap Shows Up

You have to already know what to ask. The simulator doesn't enumerate what a principal can do — it confirms or denies whatever action/resource pair you type in. If you don't think to test iam:PassRole against every role in the account, or s3:GetObject against every bucket a wildcard resource might match, the simulator won't surface it for you. It's a lookup, not an audit.

It doesn't follow chains. Say the policy under test grants sts:AssumeRole on a single role. The simulator will correctly tell you that's allowed. It won't tell you what that assumed role can then do, because that's a second policy, evaluated by a second simulator call you'd have to think to make. Multiply that by every AssumeRole and PassRole statement in a real account and the number of calls needed to actually cover the graph gets large fast.

Wildcards pass silently. "Resource": "arn:aws:s3:::*/*" simulated against one specific bucket returns "Allow" — correctly. It doesn't flag that the same statement matches every other bucket in every other account the identity might reach. The simulator isn't wrong here; it's just not built to say "by the way, this also matches 40 other things you didn't ask about."

Boundaries and SCPs compute correctly, but only for the query you gave it. If a permission boundary caps an identity policy down to two actions, the simulator will show that correctly for those two actions. It won't proactively tell you the boundary is even attached, or that removing it would change the outcome, unless you already knew to check.

Why This Matters for Pre-Deploy Review

None of this makes the simulator unreliable. The decision it returns for a given query is exactly what AWS would do at runtime. The failure mode is procedural: teams run a handful of simulated checks against the changes they're consciously aware of, get clean results, and treat that as equivalent to "this policy is safe." It answers the questions you ask. It doesn't tell you which questions you forgot to ask.

That gap matters most on new roles and CI/CD-authored policies, where nobody has built the mental model of what the role should and shouldn't reach yet — there's no experienced reviewer's intuition to fill in the queries the simulator won't generate on its own.

What Closes the Gap

Closing it means generating the queries instead of hand-picking them: walking every AssumeRole and PassRole statement to see what's reachable two and three hops out, expanding wildcard resources against the actual resources in the account instead of one example, and checking whether a boundary or SCP is present at all before assuming the identity policy is the whole story. That's the same evaluation logic the simulator runs, just applied exhaustively instead of one query at a time.

This is where AI-Powered analysis earns its keep: Shieldly's free demo at shieldly.io/app/iam takes a pasted policy and runs that exhaustive pass automatically, surfacing over-privileged wildcards, chained AssumeRole/PassRole paths, and missing boundaries without requiring you to already know which combination to test. No signup needed for the demo.

For teams: the CLI (@shieldly/cli), GitHub Action, CDK Construct (@shieldly/cdk-guard), and VS Code extension run the same analysis in CI and in your editor, so the check happens on every policy change, not just the ones someone remembers to simulate by hand. Team plan adds scheduled auto-scanning across a full account.

The policy simulator tells you the truth about the exact question you asked. The risk lives in the questions a wildcard, a chain, or an unfamiliar new role never prompted you to ask in the first place.

Why Reviewing IAM Policies One at a Time Misses the Real Risk

Shieldly — Tue, 21 Jul 2026 13:12:27 +0000

Ask most teams how they review IAM, and the answer is some version of: pull up the policy, read the Action and Resource blocks, check for wildcards, move to the next policy. That catches the obvious problems. It misses the ones that matter most.

The reason is simple: permissions don't live in one policy. They live in chains.

A Policy That Looks Fine in Isolation

Take a developer role with this statement:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::111111111111:role/deploy-pipeline"
}

Reviewed alone, this looks reasonable. The developer can't read S3, can't touch DynamoDB, can't do much of anything directly. sts:AssumeRole on a single named role looks tightly scoped.

Now look at what deploy-pipeline can do:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::prod-customer-data/*"
}

The developer's own policy never mentions S3. But the developer can assume deploy-pipeline, and deploy-pipeline has full S3 access to a bucket holding customer data. Reviewed separately, both policies pass. Reviewed as a chain, the developer effectively has s3:* on customer data, two hops away from anything their own policy admits to.

Where Chains Actually Form

A few patterns account for most of the chains we see:

Role assumption chains. sts:AssumeRole on Role A, and Role A can assume Role B, and Role B has the permissions that matter. Each hop looks narrow. The composite doesn't.

PassRole handoffs. A CI/CD identity can't launch an EC2 instance directly, but it can pass a role to EC2 via iam:PassRole, and that role can. The actual capability lives in the passed role, not the identity that triggered it.

Trust policy loops. Role A trusts Role B's account, Role B trusts Role C's account, and nobody mapped the full trust graph across three AWS accounts. Each individual trust relationship was approved by someone. The transitive closure wasn't reviewed by anyone.

Resource policy plus identity policy. An identity policy grants s3:GetObject on *. A bucket policy in a different account grants read access to that same identity by ARN. Neither policy alone looks broad. Together, the identity can read a bucket its own team never provisioned.

Why Manual Review Doesn't Catch This

None of these chains are hidden exactly — they're spread across multiple documents that nobody reads side by side. A policy review checklist evaluates one JSON document against a rubric. It doesn't ask "what can this identity reach two or three hops out." That question requires building a graph: every role, every trust relationship, every AssumeRole and PassRole statement, resolved against every other policy in the account.

At a handful of roles, a sharp reviewer can hold that graph in their head. At the hundreds of roles a mid-sized AWS account accumulates after a couple of years, nobody can. The review still happens — it's still a checkbox in the audit — it just stops catching the escalation paths that go more than one hop deep.

What to Actually Check

If you're auditing IAM manually, a few questions catch a disproportionate share of chain risk:

For every sts:AssumeRole statement, what can the assumed role do, and what can it assume?
For every iam:PassRole statement, is it scoped with iam:PassedToService, or can the role be passed to anything?
Do any cross-account trust policies exist that nobody outside the original approver has looked at recently?
Does any identity policy combine with a resource-based policy (S3 bucket policy, KMS key policy, Lambda resource policy) to grant more than either grants alone?

None of these require exotic tooling to check by hand for a small number of roles. They require deliberately looking one hop past the policy in front of you, which most reviews don't budget time for.

Where Automation Actually Helps

This is the specific problem AI-Powered analysis is well suited for: not spotting an obvious wildcard, but resolving a graph of AssumeRole and PassRole relationships across every policy in an account and flagging where the composite permission exceeds what any single policy discloses.

Shieldly's free demo at shieldly.io/app/iam traces trust relationships and PassRole targets when you paste a policy, so you can see what a role can reach beyond its own statements, not just what it explicitly grants. No signup needed for the demo.

For teams: the CLI (@shieldly/cli), GitHub Action, CDK Construct (@shieldly/cdk-guard), and VS Code extension surface the same findings in CI and in your editor. Team plan adds scheduled auto-scanning across an account so chain risk gets caught as roles evolve, not just at the moment someone remembers to run an audit.

A policy that passes review in isolation can still be one AssumeRole away from a problem. The chain is the thing worth auditing, not just the link in front of you.

5 IAM Condition Keys That Prevent the Mistakes Wildcards Create

Shieldly — Mon, 20 Jul 2026 13:12:28 +0000

5 IAM Condition Keys That Prevent the Mistakes Wildcards Create

An IAM policy with Action: "s3:*" and Resource: "*" is an obvious problem. You can spot it from across the room.

The harder problems are the policies that look reasonable. Action: "s3:GetObject" on Resource: "*" — that's just one action, right? But it means the role can read objects from every S3 bucket in the account, including the one where CloudTrail logs land and the one the billing team uses for customer invoices.

Condition keys are how you write policies that are broad where they need to be and tight everywhere else. They add a second dimension to every permission statement: not just what this role can do, but under what circumstances it can do it.

Here are five condition keys that catch the most common IAM overpermission patterns.

1. `aws:SourceIp` — Restrict by Network Origin

The most straightforward condition. If a role should only be used from your office VPN or a specific VPC, add an IP restriction.

"Condition": {
  "IpAddress": {
    "aws:SourceIp": "10.0.0.0/8"
  }
}

This is useful for break-glass admin roles and any permission that should never be called from outside your network. Note that aws:SourceIp checks the original requester's IP — if the call comes through a VPC endpoint or AWS service, you might want aws:VpcSourceIp instead.

2. `aws:RequestedRegion` — Lock to Specific Regions

If your infrastructure only runs in us-east-1 and eu-west-1, a role that can create resources in ap-southeast-1 is a role you don't need. aws:RequestedRegion prevents actions in regions you don't use, which limits blast radius if credentials leak.

"Condition": {
  "StringEquals": {
    "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
  }
}

This is also a compliance win — many frameworks expect you to demonstrate that production workloads only run in approved regions.

3. `iam:PassedToService` — Scope PassRole

iam:PassRole is one of the most dangerous permissions in IAM. It controls which principals can pass which roles to which services. A wildcard PassRole on Resource: "*" means the principal can attach any role — including AdministratorAccess — to any service it can launch.

Add iam:PassedToService to restrict which AWS services can receive a passed role:

"Condition": {
  "StringEquals": {
    "iam:PassedToService": "lambda.amazonaws.com"
  }
}

Now the principal can still pass roles, but only to Lambda. If it's a CI/CD role that deploys functions, that's exactly what you want. If the role gets compromised, the attacker can't use it to launch an EC2 instance with an admin instance profile.

4. `aws:ResourceTag` + `aws:PrincipalTag` — Attribute-Based Access Control

Tag-based conditions scale better than listing individual resource ARNs. Instead of maintaining a list of every EC2 instance a role can terminate, tag your instances by environment and write the condition once:

"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "staging"
  }
}

Pair it with aws:PrincipalTag on the role side, and you can write policies that say "users in the Engineering department can terminate instances tagged with Engineering." That's ABAC — attribute-based access control — and it's how teams with 200+ roles keep permissions manageable without drowning in policy length limits.

5. `s3:ResourceAccount` — Cross-Account S3 Access

If a role in account A needs to read objects from a bucket in account B, s3:GetObject on Resource: "*" lets it read from every account that grants it access — not just account B. An overly permissive bucket policy in a third account suddenly becomes readable.

"Condition": {
  "StringEquals": {
    "s3:ResourceAccount": "222222222222"
  }
}

Now the role can only access S3 objects in account B, even if other accounts have open bucket policies. This matters when you're managing cross-account access across an organization with dozens of accounts and hundreds of buckets.

Finding Policies That Miss These

The problem with condition keys is that they're invisible until you go looking. An IAM policy with no conditions looks exactly as "valid" as one with them — both return 200 OK from the API, and neither throws an error until the wrong access happens.

Shieldly's free AI-Powered demo at shieldly.io/app/iam flags policies that are missing condition keys where they'd reduce risk. Paste a JSON policy and you'll see which statements would benefit from IP restrictions, PassedToService scoping, or resource tag conditions — no signup needed.

For teams: the CLI (@shieldly/cli), GitHub Action, CDK Construct (@shieldly/cdk-guard), and VS Code extension all surface the same findings in your existing workflow.

Condition keys don't make your policies longer. They make them more precise. And precision is what separates "nobody's found it yet" from "there's nothing to find."

4 IAM Misconfiguration Patterns That Keep Showing Up in Real AWS Accounts

Shieldly — Wed, 15 Jul 2026 13:21:13 +0000

I spend a lot of time looking at IAM policies. Real ones — from production accounts, staging environments, CI/CD pipelines. After a while, the same mistakes keep appearing. Not because teams are careless. Because IAM's policy language is expressive enough that you can write something that looks reasonable and still be wrong.

Here are four patterns I keep finding, why they're dangerous, and how to catch them.

1. `Action: ""` with `Resource: ""`

This is the obvious one, but it hides in less obvious places. It's not always AdministratorAccess. Sometimes it's a Lambda execution role that started as a placeholder during development. Six months later it's still there, running in production, with full access to every service.

What to check: Does this role actually need to touch DynamoDB? SQS? KMS? If the Lambda only writes to CloudWatch Logs and reads from one S3 bucket, scope it to those two services.

The fix isn't Action: "s3:*" — that still gives the role permission to delete every bucket in the account. Narrow it to the specific actions the function calls: s3:GetObject, s3:PutObject.

2. `iam:PassRole` without conditions

PassRole is the permission that says "this principal can pass a role to an AWS service." It's what lets a Lambda function assume its execution role, or an EC2 instance launch with an instance profile.

Without conditions, PassRole with a wildcard resource means the principal can pass any role in the account. A developer with PassRole on * can launch an EC2 instance with the account's admin role attached.

What to check: Every PassRole statement should have a Resource field that lists specific role ARNs, and ideally a Condition with iam:PassedToService scoping which services can receive the role.

3. `s3:GetObject` on `*` in a role's policy

A role that can read any S3 object in any bucket. Including the bucket where your CloudTrail logs land. Including buckets owned by other teams that might contain customer data.

This often happens because someone created a role to read from one specific bucket, typed "Resource": "*" to get it working, and never came back to tighten it.

What to check: Every s3:GetObject statement should list specific bucket ARNs. If the role needs access to multiple buckets, list them explicitly. The extra thirty seconds of typing saves you from a blast radius problem later.

4. Missing condition keys on broad permissions

A role with ec2:TerminateInstances on * is a role that can terminate every EC2 instance in the account. Add "Condition": {"StringEquals": {"aws:ResourceTag/Environment": "staging"}} and suddenly that same permission only applies to instances tagged Environment: staging.

Condition keys like aws:ResourceTag, aws:PrincipalTag, and aws:SourceIp are how you write policies that are broad where they need to be and tight everywhere else. But most policies I see don't use them at all.

What to check: For any Action that includes Delete* or Terminate*, look at whether a resource tag condition would reduce the blast radius. ABAC (attribute-based access control) isn't just a buzzword — it's how teams with 200+ roles keep permissions manageable.

How to catch these systematically

Manual review works for one role. It doesn't scale to fifty. And it definitely doesn't work when policies change across deploys and nobody reviews the diff.

The Shieldly free demo at shieldly.io/app/iam runs AI-Powered analysis on any IAM policy and flags wildcard actions, missing conditions, overly broad resources, and PassRole risks — no signup needed. Paste a policy and get findings with remediation steps.

For teams: the CLI (@shieldly/cli) and GitHub Action slot into CI/CD. The CDK Construct (@shieldly/cdk-guard) catches issues before deployment. And the VS Code extension flags them while you're writing the policy.

I built Shieldly because I spent too many Friday afternoons staring at JSON policy documents wondering which wildcard was the problem. If these patterns look familiar, give the demo a try.

The Hidden Cost of Manual IAM Review

Shieldly — Wed, 15 Jul 2026 00:10:34 +0000

The Hidden Cost of Manual IAM Review

Most teams don't track how long they spend reviewing IAM policies. When I started measuring it on my own team, the numbers were worse than I expected.

A thorough manual review of one IAM policy takes 10 to 15 minutes. Not a quick scan. A real review: read every statement, trace every cross-account trust, verify every condition key, check for privilege escalation paths, confirm the resource ARNs match what you think they should.

At 4 engineers touching IAM once a week, that's 4 hours a month. 48 hours a year of senior engineers reading JSON documents.

And that's the optimistic case. Add a security incident. Add an audit. Add the emergency Friday-afternoon policy change that needs review before deploy. The real number is higher.

What manual review misses

The problem isn't just the time. It's that humans are bad at repetitive structured-data review, especially under time pressure.

Here are the things I've seen slip through manual IAM reviews on production systems:

iam:PassRole with no condition. This is the big one. PassRole lets a principal pass a role to a service â€” and if there's no iam:PassedToService condition, that role can be passed to any service that accepts roles. Including services the attacker controls. The reviewer saw the action, mentally categorized it as "role stuff," and moved on. It was statement 47 of 52 â€” the reviewer had already been reading policies for 40 minutes.

Wildcard resource with sensitive actions. s3:* on Resource: "*" is obvious. s3:GetObject on "arn:aws:s3:::*-backup/*" with a wildcard in the bucket name â€” that's subtle. The reviewer reads it as "restricted to backup buckets" and moves on. But the wildcard means any bucket ending in -backup, including ones in other accounts if cross-account access is configured.

Missing aws:SourceArn on Lambda invocation permissions. When you grant another service permission to invoke your Lambda function, you need aws:SourceArn to prevent the confused deputy problem. Without it, any principal in the trusted service's account can invoke your function through that service. This one gets missed because the reviewer focuses on the principal, not the condition block.

CloudFormation-generated role names that don't match the policy's intent. A policy grants dynamodb:PutItem on a table called prod-users. But the resource ARN references a table with a CloudFormation-generated suffix like prod-users-AB12CD34EF. The reviewer sees "prod-users" in the logical name and confirms. The physical resource is a different table entirely.

The pattern: fatigue degrades quality

Everyone starts a review session sharp. The first policy gets 100% attention. By the third policy, you're skimming condition blocks. By the fifth, you're checking actions and resources and hoping nothing weird is in the conditions. This isn't incompetence â€” it's how human attention works on repetitive structured-data tasks.

The worst-case scenario: the reviewer is 3 tickets behind on a Friday at 4pm. They have a deploy waiting on their approval. They scan the policy in 2 minutes, see nothing obviously wrong, and approve. That's the moment iam:PassRole with no condition gets through.

What automation changes

Automated IAM analysis doesn't get tired. It doesn't have a Friday afternoon. It checks every condition on every statement on every review, regardless of how many policies came before it.

For our team, switching from manual-only review to automated-first changed two things:

Review time dropped from 10-15 minutes to 30 seconds per policy. The tool flags issues; the human verifies the flags. The human spends time on judgment (is this intentional? does the context justify this wildcard?) instead of discovery (does this policy have a wildcard somewhere?).
Catch rate improved. Not because the tool is smarter than a human â€” it's not. Because it doesn't skip statement 47.

Try it yourself

You can test this on your own policies. Paste any IAM policy into Shieldly's free analyzer at shieldly.io/app/iam â€” no signup, no credit card. It'll show you every wildcard, every missing condition, every PassRole without a service restriction, every resource mismatch. Same engine that runs on the paid plans.

If you want to automate it: Builder ($19/mo) adds API access and the Cost Advisor. Pro ($49/mo) adds the Compliance Panel for audit readiness. Team ($99/mo) adds automated scanning, Slack alerts, and supports up to 10 engineers.

The math on manual IAM review isn't complicated. 48 hours of senior engineer time per year, plus whatever gets through on Friday afternoons. It's just uncomfortable to calculate.

I built Shieldly â€” AI-Powered Security Analysis for AWS. This is real math from measuring my own team's review time, not a benchmark.

Catch Risky IAM in Your CDK App Before cdk deploy

Shieldly — Mon, 13 Jul 2026 13:19:00 +0000

You ship a CDK stack. One IAM role has a wildcard because you copy-pasted a gist eight months ago. That role is now your blast radius.

Most CDK pipelines have linting. They have type checking. They have cdk diff to preview changes. But nobody's checking IAM policies for overpermissions at synth time.

@shieldly/cdk-guard fills that gap. It runs AI-Powered security analysis on every synthesized stack: risky IAM policies and CloudFormation misconfigurations get flagged before anything hits CloudFormation.

Disclosure: I work on Shieldly.

What it catches

The patterns that manual review misses:

Action: "*" or "*:*": the obvious one, but easy to miss when buried in a 200-line stack
iam:PassRole with a wildcard resource and no conditions: lets a compromised principal hand privileged roles to services it controls
s3:* on a role that only needs GetObject: permission inflation that grows over time
Missing condition keys: no aws:SourceArn, no aws:PrincipalOrgID, no constraints at all

None of these are obscure. They're the patterns that show up in every post-incident review.

Setup

npm install --save-dev @shieldly/cdk-guard

Simplest path is the CLI wrapper: it runs cdk synth, then analyzes all synthesized stacks. Works with any CDK language:

npx @shieldly/cdk-guard

Or add the construct-style guard in a JavaScript/TypeScript CDK app. It analyzes cdk.out/ automatically when the process exits, no explicit call needed:

import * as cdk from 'aws-cdk-lib';
import { ShieldlyGuard } from '@shieldly/cdk-guard';

const app = new cdk.App();

new ShieldlyGuard({
  failOn: 'High',  // Critical | High | Medium | Low | none
});

new MyStack(app, 'MyStack');

If findings at or above failOn severity come back, the process exits non-zero and your deploy stops.

You'll need an API key (SHIELDLY_API_KEY env var, keys are on the Builder plan and above); without a key it runs against the free demo endpoint with a scan limit. Privacy note: your CDK templates are never logged, cache keys are one-way SHA-256 hashes.

CI/CD integration

Block bad policies before they reach main:

# GitHub Actions example
- name: CDK security check
  run: npx @shieldly/cdk-guard
  env:
    SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

There's also a cdk.json hook variant ("afterSynth": ["npx", "@shieldly/cdk-guard", "--no-synth"]) if you want it to run on every synth regardless of who invokes it.

What it costs

API keys start on the Builder plan ($19/mo, 150 analysis units/day). There's also a free tier (20 analysis units/day) and a keyless demo mode with a scan limit, so you can try it before paying anything.

The package is on npm. Source is on GitHub.

Why "Request a Demo" Is the Wrong First Step for IAM Security Tools

Shieldly — Fri, 10 Jul 2026 13:18:29 +0000

I built an IAM policy analyzer. The most common first question wasn't about features. It was "what happens to my policies after I paste them?"

Fair question. You're handing over your infrastructure's permission model to a text box. If the vendor can't answer that question clearly, you shouldn't trust them with anything else.

But there's a second problem most security tools create: they gate the answer behind a demo call.

The Demo Call Problem

"Request a demo" means:

You fill out a form
Someone emails you a Calendly link
You spend 30 minutes on a screen share with a sales engineer
They show you a sandboxed environment with synthetic data
Your actual IAM policy never touches the product

You walk away knowing how the tool looks, not how it works on your infrastructure.

Real demo mode â€” the kind where you paste an actual policy and get real findings â€” answers three questions immediately:

Does this tool find issues I actually have? Not curated examples. Your policies.
What does the output look like? Is it actionable or a wall of text?
Is the analysis fast enough to fit into my workflow? Or do I need to context-switch and come back?

A sales demo answers none of these.

What Real Demo Mode Requires

Building a tool anyone can use without signing up means solving a few problems:

Input privacy. Your policies can't be logged. Shieldly uses a one-way SHA-256 hash of your input as a cache key. The plaintext never hits a log, never lands in a training set, never sits in an analytics database. The hash lets us return cached results for identical policies without storing the policies themselves.

Rate limiting that doesn't break the experience. You need enough free analyses to evaluate the tool (20 analysis units per day on the free tier) without opening a vector for abuse. Server-side caps, not localStorage counters that anyone can clear.

Real analysis, not a reduced model. Some tools run a lighter model for demo traffic. Shieldly runs the same analysis pipeline whether you're signed in or not â€” Standard AI for free users, Advanced and Enterprise for paid tiers. The demo isn't a downgraded experience. It's the real thing, just gated by a daily cap.

Evaluating a Security Tool Without a Demo Call

If a tool has real demo mode, you can test it in 5 minutes:

Paste a policy you already reviewed manually. You know what the issues are. Does the tool catch them? Does it find things you missed?
Paste a policy you know is clean. Does it produce false positives? A tool that flags s3:ListBucket as a finding on a read-only reporting role isn't useful.
Check the findings format. Are findings grouped by severity? Does each one explain why it's a problem and how to fix it? If the output is just "this policy has 7 issues" with no detail, you'll need a second tool to actually remediate.

Try It With Your Own Policy

Shieldly's IAM analyzer is free at shieldly.io/app/iam. No signup, no credit card. Paste any IAM policy â€” resource policy, identity policy, SCP â€” and get real findings in seconds.

The free tier gives you 20 analysis units per day. Builder ($19/mo) adds API access and Cost Advisor. Pro ($49/mo) adds a compliance panel. Team ($99/mo) adds auto-scanning and Slack alerts for up to 10 engineers.

If you paste a policy and the findings aren't useful, that's honest feedback I want to hear. If they are useful, you just evaluated a security tool in less time than a demo call would have taken.

AWS IAM Privilege Escalation: Real Attack Paths DevOps Engineers Need to Know

Shieldly — Tue, 07 Jul 2026 13:16:20 +0000

You've locked down your AWS accounts. MFA is enforced, no wildcard IAM policies in production, and you've got a service control policy (SCP) boundary that's tighter than a production change freeze. Feels safe, right?

Then someone on your team grants iam:PassRole to a Lambda function, and a junior engineer accidentally leaves iam:CreatePolicyVersion on a developer role. Two harmless-looking permissions. One breach.

IAM privilege escalation in AWS rarely comes from obvious admin access. It comes from chains — individually reasonable permissions that, when combined, let an attacker with a foothold pivot to full account compromise. Here are the escalation paths I've seen pop up in real AWS environments, what they look like in practice, and how to shut them down without breaking your team's workflow.

Path 1: `iam:PassRole` → Lambda → `sts:AssumeRole`

This is the most common escalation I encounter during reviews. It's deceptively simple.

The dangerous permission set:

{
  "Effect": "Allow",
  "Action": ["iam:PassRole", "lambda:CreateFunction", "lambda:InvokeFunction"],
  "Resource": "*"
}

On its own, iam:PassRole lets an IAM principal attach an existing IAM role to an AWS service. It doesn't grant any permissions on that role's policies — just the ability to attach it. Engineers add this to Lambda execution roles all the time so CI/CD pipelines can deploy functions.

The escalation:

An attacker who compromises a principal with those three permissions can:

Find a high-privilege IAM role in the account (e.g., AdminRole, DeploymentRole, BreakGlassRole).
Create a Lambda function with that role attached via iam:PassRole.
Write a one-liner in the function that calls sts:AssumeRole on itself — or, more destructively, calls iam:CreateAccessKey on an admin user.
Invoke the function, extract the credentials, and own the role.

# payload.py — deployed as Lambda, attached to the victim role
import boto3, json

def handler(event, context):
    sts = boto3.client('sts')
    # Just long enough to exfil
    creds = sts.get_session_token(DurationSeconds=900)
    return {'status': 'done', 'access': creds['Credentials']['AccessKeyId']}

The mitigation isn't "never use iam:PassRole" — that's impractical. The fix is resource constraints on iam:PassRole to limit what roles can be passed, and lambda:CreateFunction to restrict what functions can be created. Pair this with a permissions boundary on Lambda execution roles, and the path collapses.

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::*:role/ci-cd-*",
  "Condition": {
    "StringEquals": {"iam:PassedToService": "lambda.amazonaws.com"}
  }
}

Path 2: EC2 Instance Profile Chaining

EC2 instance profiles are the original IAM escalation vector, and they're still widespread. The mechanics are different from the Lambda path but the endgame is the same: hijacking an attached role's identity.

The setup:

Your CI/CD runners live on EC2. Each runner gets an instance profile role — say EC2-CI-Runner — with permissions to pull from ECR, write to CloudWatch, and access an S3 bucket for build artifacts. Standard stuff.

Someone adds ec2:AssociateIamInstanceProfile to a developer role so the team can attach profiles to test instances during development. That's the crack in the door.

The escalation:

An attacker with ec2:AssociateIamInstanceProfile (and ec2:RunInstances or access to an existing instance) can:

Launch a new EC2 instance (or hijack an existing stopped one they can ec2:StartInstances).
Detach the low-privilege instance profile from the target instance.
Associate a high-privilege instance profile — one attached to a production service or a data pipeline — onto their instance.
SSH in (via SSM or a key they control) and retrieve the instance metadata credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/.

One curl command later, they have AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN for the production role.

# On the attacker-controlled EC2 instance
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

The fix:

Never grant ec2:AssociateIamInstanceProfile without a resource constraint on the instance profile ARN, not just the instance. Lock it down to specific profiles:

{
  "Effect": "Allow",
  "Action": "ec2:AssociateIamInstanceProfile",
  "Resource": [
    "arn:aws:ec2:*:*:instance/*",
    "arn:aws:iam::*:instance-profile/development-*"
  ]
}

Better yet, add a Condition key checking that the profile isn't tagged as production, or apply a service control policy that blocks instance profile association for non-admin roles entirely.

Path 3: `iam:CreatePolicyVersion` — The Nearly Silent Takeover

This one flies under the radar because it's one permission — no chaining required.

iam:CreatePolicyVersion lets you create a new version of an existing customer-managed policy. If the policy is attached to a user, group, or role, the new version can be set as default, instantly granting new permissions to every principal under that policy.

The scenario:

A security-conscious team grants iam:CreatePolicyVersion to a handful of trusted engineers so they can iterate on policy changes without going through a full deployment pipeline. The policy in question, SupportEngineerPolicy, is attached to 40 support engineers who need read-only access to CloudWatch and limited EC2 describe permissions.

An attacker compromises one support engineer's credentials — phishing, leaked token, compromised workstation — and discovers they can create policy versions. They craft a new version of SupportEngineerPolicy that adds "Effect": "Allow", "Action": "*", "Resource": "*" and set it as default.

# One API call to own the environment
aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/SupportEngineerPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
  --set-as-default

Every principal attached to that policy — 40 engineers — now has full administrative access. The attacker exfiltrates data, creates backdoor users, and the blast radius is enormous. The worst part? No new IAM users or roles were created. No obvious anomalies in CloudTrail if you're not watching CreatePolicyVersion events.

The mitigation:

Block iam:CreatePolicyVersion with an SCP for all non-admin roles. Use iam:SetDefaultPolicyVersion as a sensitive action that triggers an alert in your SIEM. Treat policy version management the same way you treat IAM user creation — it's a privileged operation, not a convenience feature.

{
  "Effect": "Deny",
  "Action": [
    "iam:CreatePolicyVersion",
    "iam:SetDefaultPolicyVersion",
    "iam:DeletePolicyVersion"
  ],
  "Resource": "*",
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/admin-*"
    }
  }
}

Putting It Together: Defense in Depth for IAM

If there's one lesson from years of AWS IR, it's this: IAM permissions are directional. You can't audit them in isolation. A permission that's harmless in role A becomes critical when paired with role B's pass-role target or role C's policy attachment.

What works in practice:

SCP boundaries first. Deny iam:PassRole for cross-account roles, deny iam:CreatePolicyVersion broadly, and restrict instance profile associations at the organization level. You can't accidentally grant what SCPs already block.
Resource-level constraints on everything. "Resource": "*" on pass-role or create-function is a risk acceptance, not a policy. Scope every actionable IAM permission to specific ARN patterns.
Alert on the escalation primitives. CloudWatch Events on CreatePolicyVersion, PassRole to non-standard services, and AssociateIamInstanceProfile on production-tagged instances. Don't wait for a breach to find out your monitoring had a gap.
Audit with an adversarial mindset. Don't ask "does this role have too many permissions?" Ask "if this role is compromised, what can the attacker reach from here?" Map the chains, not just the leaf permissions.
Use permissions boundaries. Every role your team creates should have a permissions boundary that caps its effective permissions regardless of what policies get attached later. It's the IAM equivalent of a circuit breaker.

IAM privilege escalation isn't a vulnerability in AWS — it's a vulnerability in how we compose IAM permissions day to day. The tools themselves are fine. The chains we build with them are the problem.

Know your chains. Test them before an attacker does.

9 AWS IAM Privilege Escalation Methods You Can Check in 5 Minutes

Shieldly — Mon, 06 Jul 2026 10:19:37 +0000

Most AWS IAM breaches do not start with a zero-day. They start with a policy that
granted one permission too many — and that single permission turned out to be a path to
administrator. Here are nine real privilege-escalation methods, what each one needs, and
how to close it. Each links to a deeper write-up with an example vulnerable policy and the
exploit command.

Self-service to admin

These need nothing but a permission on your own identity:

iam:AttachUserPolicy — attach AdministratorAccess to your own user.
iam:PutUserPolicy — write an inline "Action": "*" policy on yourself.
iam:UpdateLoginProfile — reset the console password of a more-privileged user and sign in as them (unless they have MFA).
iam:AttachGroupPolicy / iam:PutGroupPolicy — attach or inline admin onto a group you belong to; every member inherits it.

Role-based, if you can assume the role

iam:AttachRolePolicy / iam:PutRolePolicy — grant admin to a role you can assume.

PassRole + a compute service

iam:PassRole is the most abused permission on AWS because it is the bridge between
"I can configure a service" and "that service runs as a privileged role":

ECS — register a task definition whose task role is privileged, run it, read the credentials from the task metadata endpoint.
Lambda event source mapping — create a function with a privileged execution role and trigger it from a stream, no lambda:InvokeFunction required.

Already on the box

ssm:SendCommand — run commands on an EC2 instance that already holds a privileged instance-profile role, and use its credentials off-box. No iam:PassRole needed.

The common fix

Across all of these the pattern is the same: scope iam:PassRole with an
iam:PassedToService condition and a role allowlist, restrict the policy/role-management
actions to administrators, and apply a permissions boundary so an attached admin policy
can never exceed the boundary.

You can paste a policy into Shieldly and get AI-Powered
analysis of exactly which of these paths it opens and the conditioned fix — free, no signup.
The full reference of escalation methods is at
shieldly.io/iam.

Disclosure: I help build Shieldly.

Gate Insecure AWS IAM in Pull Requests with a Free GitHub Action

Shieldly — Sun, 05 Jul 2026 13:15:02 +0000

Originally published at shieldly.io/blog.

Most IAM problems are not caught by a clever attacker. They are caught â€” eventually â€” by an audit, months after a wildcard shipped because a deploy was blocked at 6pm. The fix is to move the check left: review the policy in the pull request, automatically, before it merges.

Why the PR Is the Right Place

By the time a misconfiguration reaches a quarterly security review, it has been live for a quarter. The PR is the moment the author has full context, the change is small, and tightening a policy costs one comment instead of a migration project.

A CI gate also takes the awkward human conversation off the table â€” the bot flags it, consistently, every time.

Add the Action in 3 Lines

# .github/workflows/shieldly.yml
name: IAM Security Analysis
on: [pull_request]

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shieldly-io/action@v1
        with:
          fail-on-severity: HIGH
        env:
          SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

The Action scans changed IAM policies, resource-based policies, and CloudFormation templates in the PR, posts findings as a review comment with the why and the suggested fix, and fails the check on HIGH or CRITICAL findings so risky access cannot merge unnoticed.

What It Catches

Wildcard Action: * and Resource: *
Privilege escalation paths (PassRole chains, CreatePolicyVersion, AttachUserPolicy abuse)
Trust policy misconfigurations (Principal: *, missing ExternalId)
CloudFormation roles with AdministratorAccess
iam:PassRole on Resource: *
NotAction + Effect: Allow patterns

Configuration Options

- uses: shieldly-io/action@v1
  with:
    paths: "**/*.json,**/*.yaml,cdk.out/**/*.template.json"
    fail-on-severity: HIGH   # CRITICAL, HIGH, MEDIUM, LOW
    comment-on-pr: true      # Post findings as PR comment (default: true)

Free Tier

The Action works on the free plan â€” no credit card, no per-seat charge. Each PR scan uses analysis units from your daily quota. The free plan includes 20 analysis units/day.

Launch offer: code 90Off2M â€” 90% off first 2 months. Builder from $1.90/mo, includes 150 analysis units/day and priority scan queuing.

Install: github.com/shieldly-io/action

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

AWS STS ExternalId and the Confused Deputy Problem: A Practical Guide

Shieldly — Wed, 01 Jul 2026 13:20:01 +0000

Originally published at shieldly.io/blog.

Cross-account IAM roles are the standard mechanism for granting third-party services access to your AWS account. The problem is that naming an entire AWS account as the trusted principal is not specific enough. Any identity authenticating from that account can call sts:AssumeRole on your role. This is the confused deputy problem, and ExternalId is the condition that closes it.

What the Confused Deputy Problem Is

The confused deputy is a class of vulnerability where a privileged program is tricked by a less-privileged caller into performing actions on the caller's behalf.

In AWS: a SaaS provider has a trusted AWS account. Customers create cross-account roles naming the SaaS provider's account as the trusted principal:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::VENDOR-ACCOUNT:root"
  },
  "Action": "sts:AssumeRole"
}

Any identity in the vendor's account can call sts:AssumeRole on any customer's role — because from AWS's perspective, the call originates from the correct trusted account. Customer A can potentially assume Customer B's role if they know B's role ARN. The SaaS provider is the confused deputy.

How ExternalId Fixes It

When a vendor requires ExternalId as a condition on sts:AssumeRole, they generate a unique secret value per customer and store it. When their service assumes your role, it passes that value:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::VENDOR-ACCOUNT:root"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "a7f3b2c9-unique-per-customer"
    }
  }
}

A different customer cannot assume your role because they do not know your ExternalId — even if they use the same vendor account.

Implementing It Correctly

The ExternalId must be:

Unique per customer-vendor relationship — not shared across customers
Unguessable — a UUID or similar high-entropy value, not a predictable string like a customer name or account ID
Generated by the vendor — not chosen by the customer (a customer-chosen ID is potentially guessable by other customers of the same vendor)

Also verify that you cannot pass an arbitrary ExternalId to the vendor's service. If the vendor accepts any value you provide, the control is ineffective.

Red Flags in Third-Party Integration Docs

Watch for these in vendor setup instructions:

No mention of ExternalId
Instructions to trust arn:aws:iam::VENDOR-ACCOUNT:root with no condition
A fixed, static ExternalId shared across all customers (defeats the purpose)

Catch confused deputy risks automatically — paste a cross-account trust policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Builder from $1.90/mo. shieldly.io/pricing

The 7 IAM Misconfigurations We See in Almost Every AWS Account

Shieldly — Wed, 01 Jul 2026 02:33:59 +0000

Originally published at shieldly.io/blog.

After analyzing a lot of IAM policies, the same seven patterns show up again and again. Here is each one, why it is dangerous, and the fix.

1. Action: * on Resource: *

{
  "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. Fix: enumerate the exact actions the workload needs.

2. s3:* on Resource: *

Even scoping to one service is too broad. s3:* includes s3:DeleteObject, s3:DeleteBucket, and s3:PutBucketPolicy. Fix: list only the specific actions (s3:GetObject, s3:PutObject, etc.) on the specific bucket ARN.

3. iam:PassRole on Resource: *

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

PassRole is harmless until paired with a service launch. On Resource: * it lets a principal pass any role in the account to any service — including admin roles. Fix: scope to specific role ARNs and add the iam:PassedToService condition key.

4. Trust policy Principal: *

{
  "Principal": "*"
}

Any AWS identity in the world can attempt to assume the role. Almost always unintentional. Fix: replace with explicit account or role ARNs, and add an ExternalId condition for cross-account access.

5. Missing ExternalId on third-party cross-account roles

Without ExternalId, any customer of the same vendor can assume your role (the confused deputy problem). Fix: require a unique ExternalId condition on every cross-account trust policy.

6. Inline policies on IAM users

Inline policies do not appear in the IAM managed policy list and are easy to miss in audits. They also travel with the user — if the user is deleted and a new one created with the same name, they do not transfer. Fix: move to customer-managed policies attached to roles, not users.

7. sts:AssumeRole on Resource: *

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

A principal with this permission can assume any role in the account whose trust policy allows it. That includes roles with administrator access. Fix: scope to specific role ARNs.

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

Launch offer: code 90Off2M — 90% off first 2 months. Builder from $1.90/mo. shieldly.io/pricing

DEV Community: Shieldly

What the IAM Policy Simulator Actually Tells You (and What It Doesn't)

What the Simulator Is Actually Answering

Where the Gap Shows Up

Why This Matters for Pre-Deploy Review

What Closes the Gap

Why Reviewing IAM Policies One at a Time Misses the Real Risk

A Policy That Looks Fine in Isolation

Where Chains Actually Form

Why Manual Review Doesn't Catch This

What to Actually Check

Where Automation Actually Helps

5 IAM Condition Keys That Prevent the Mistakes Wildcards Create

5 IAM Condition Keys That Prevent the Mistakes Wildcards Create

1. aws:SourceIp — Restrict by Network Origin

2. aws:RequestedRegion — Lock to Specific Regions

3. iam:PassedToService — Scope PassRole

4. aws:ResourceTag + aws:PrincipalTag — Attribute-Based Access Control

5. s3:ResourceAccount — Cross-Account S3 Access

Finding Policies That Miss These

4 IAM Misconfiguration Patterns That Keep Showing Up in Real AWS Accounts

1. Action: "*" with Resource: "*"

2. iam:PassRole without conditions

3. s3:GetObject on * in a role's policy

4. Missing condition keys on broad permissions

How to catch these systematically

The Hidden Cost of Manual IAM Review

The Hidden Cost of Manual IAM Review

What manual review misses

The pattern: fatigue degrades quality

What automation changes

Try it yourself

Catch Risky IAM in Your CDK App Before cdk deploy

What it catches

Setup

CI/CD integration

What it costs

Why "Request a Demo" Is the Wrong First Step for IAM Security Tools

The Demo Call Problem

What Real Demo Mode Requires

Evaluating a Security Tool Without a Demo Call

Try It With Your Own Policy

AWS IAM Privilege Escalation: Real Attack Paths DevOps Engineers Need to Know

Path 1: iam:PassRole → Lambda → sts:AssumeRole

Path 2: EC2 Instance Profile Chaining

Path 3: iam:CreatePolicyVersion — The Nearly Silent Takeover

Putting It Together: Defense in Depth for IAM

9 AWS IAM Privilege Escalation Methods You Can Check in 5 Minutes

Self-service to admin

Role-based, if you can assume the role

PassRole + a compute service

Already on the box

The common fix

Gate Insecure AWS IAM in Pull Requests with a Free GitHub Action

Why the PR Is the Right Place

Add the Action in 3 Lines

What It Catches

Configuration Options

Free Tier

AWS STS ExternalId and the Confused Deputy Problem: A Practical Guide

What the Confused Deputy Problem Is

How ExternalId Fixes It

Implementing It Correctly

Red Flags in Third-Party Integration Docs

The 7 IAM Misconfigurations We See in Almost Every AWS Account

1. Action: * on Resource: *

2. s3:* on Resource: *

3. iam:PassRole on Resource: *

4. Trust policy Principal: *

5. Missing ExternalId on third-party cross-account roles

6. Inline policies on IAM users

7. sts:AssumeRole on Resource: *

1. `aws:SourceIp` — Restrict by Network Origin

2. `aws:RequestedRegion` — Lock to Specific Regions

3. `iam:PassedToService` — Scope PassRole

4. `aws:ResourceTag` + `aws:PrincipalTag` — Attribute-Based Access Control

5. `s3:ResourceAccount` — Cross-Account S3 Access

1. `Action: ""` with `Resource: ""`

2. `iam:PassRole` without conditions

3. `s3:GetObject` on `*` in a role's policy

Path 1: `iam:PassRole` → Lambda → `sts:AssumeRole`

Path 3: `iam:CreatePolicyVersion` — The Nearly Silent Takeover