iam-deceptive-escalation-auditor

Privilege-escalation audit skill for one AWS IAM principal. Takes every permissions policy attached to a role or user (plus the trust policy and permissions boundary if supplied), resolves the effective permission set across all of them, and answers one question a per-statement read cannot: can this principal escalate to a privilege it was not granted, and is an apparent escalation real or already neutralised. It returns findings with severity and a fix, then names exactly where a single principal's policy documents stop being able to answer the question.

The escalation combinations this skill exists to catch are precisely the ones that span two statements or two attached policies, so that no single statement looks guilty on its own. iam:PassRole in one policy and sagemaker:CreateTrainingJob in another are each routine; together they let the principal launch compute with any role attached and inherit it. A per-statement read clears every statement and misses the union. The other half of the skill is the inverse discipline: an explicit Deny, a resource scope, a broken trust, or an unsatisfiable Condition can neutralise an escalation that still reads as critical, and the audit must not fabricate a finding the effective permissions do not support.

When to invoke

• An agent is asked to audit an IAM role or user for privilege escalation, over-broad

grants, or "can this principal become administrator."

• A policy is being shipped or reviewed and the question is whether two individually-fine

grants combine into an escalation.

• A policy looks dangerous (a full mutation kit, a cross-account assume, an Action '*')

and the claim "but it's capped / scoped / denied" needs to be confirmed against the effective permissions, not taken on trust.

• An incident assumes a principal is compromised and the question is what it can escalate to.

What this skill reads, and what it does not

It reads the static policy documents attached to one principal: every permissions policy, plus the trust policy (AssumeRolePolicyDocument) and the permissions boundary if supplied. That is the entire input. The audit is correct and complete for the effective permissions those documents express, and it is explicit about the rest. Every audit ends by naming the joins it cannot make:

• It does not see the principal's other attached policies if only some were supplied.

Effective permissions are the union of every managed and inline policy. Join: principal to its full set of attached policies.

• It does not know the permissions boundary unless one is supplied. A boundary caps

what any Allow can actually grant. Join: principal to its permissions boundary.

• It does not see org SCPs. A Service Control Policy can Deny actions this policy

Allows and is invisible from the account. Join: account to its organization's SCPs.

• It does not contain the privileges of a targeted role. An escalation that passes,

assumes, or hijacks a role only matters if that role is more privileged than this principal, and those privileges live in other documents. Join: this policy to the roles and resources it references.

A clean (neutralised) policy still gets a boundary section, because a capped policy is not a proven-safe principal.

The model

Build the effective permission set across all attached policies. An action is granted when some Allow statement matches it (by case-insensitive glob on Action, or by NotAction) and no blanket Deny (on Resource "*") matches it. Deny wins over Allow, always. The escalation checks then run against this resolved set, not against any single statement, because the combos are unions and the neutralisations are denies.

Deny handling is a conservative approximation: a Deny on Resource "*" kills the action; resource-specific denies are behind the boundary (the audit does not enumerate the account's ARNs). This never under-reports a grant on a wildcard resource, which is the case the skill cares about.

The methodology, in order

1. Resolve the effective permission set

Before any judgment, union the statements and apply Deny:

• Load every policy*.json for the principal. A principal can have several attached

policies, and the escalation combos are exactly the ones that span them.

• Split into Allow and Deny statements. An action is granted only if an Allow matches it and

no blanket Deny does. Read Effect: Deny as a hard constraint, not noise — it is the single most common neutraliser in this corpus.

• Expand a wildcard Action (* or svc:*) into the concrete sensitive permissions it

grants, so a wildcard is judged by what it contains, not skimmed as "broad."

• Read the trust policy (enables the trust-exposure check) and the permissions boundary

(suppresses the "no boundary provided" note and may itself be the Deny that caps a kit).

2. Check the cross-statement escalation combos (E1-E6)

These are the flagship. Each spans statements so no single one looks guilty. Run them against the resolved set:

• E1 (critical/high) — `iam:PassRole` + a compute-launch action. Pair PassRole with

ec2:RunInstances, lambda:CreateFunction, ecs:RunTask, sagemaker:CreateTrainingJob, cloudformation:CreateStack, etc.: launch compute with a more-privileged role attached, then use that compute's credentials. Critical when PassRole is on Resource "*" (any role, including admin); high when scoped (the escalation is real only if that scoped role is more privileged — a boundary question). The launch action must actually bind a role: Start/Invoke on existing compute take no PassRole argument and do not arm E1.

• E2 (critical) — rewrite a managed policy in place. iam:CreatePolicyVersion /

iam:SetDefaultPolicyVersion: mint a new admin version of an attached policy, or flip the default back to a permissive one. No second action needed; the policy ARN is unchanged.

• E3 (critical) — hijack a function's execution role. lambda:UpdateFunctionCode:

overwrite an existing function's code to run attacker code with that function's role. No PassRole required (it reuses an attached role).

• E4 (critical) — attach an admin policy to a principal. iam:AttachUserPolicy /

AttachRolePolicy / PutRolePolicy etc.: a single attach call turns a scoped identity into an administrator.

• E5 (critical/high) — rewrite a role's trust policy, then assume it.

iam:UpdateAssumeRolePolicy (+ sts:AssumeRole = critical): rewrite a privileged role's trust to trust this principal, then assume it.

• E6 (high) — mint credentials for another identity. iam:CreateAccessKey /

CreateLoginProfile / AddUserToGroup etc.: a sideways takeover that never touches the caller's own policies, so a review of this principal's permissions looks clean.

What is NOT an escalation (do not flag these): A standalone sts:AssumeRole grant is not an in-account privilege escalation on its own. Escalation-via-assume is E5 and requires iam:UpdateAssumeRolePolicy to rewrite a role's trust so it trusts this principal. Without that rewrite capability, an sts:AssumeRole grant only does anything if the target role already trusts this principal back, and even then it is lateral movement to whatever that role can do, not self-escalation, scored as the boundary question of "is the target more privileged." A cross-account sts:AssumeRole narrowed by an aws:PrincipalOrgID / sts:ExternalId condition, with no UpdateAssumeRolePolicy to relax either side, is inert: report no escalation. Do not debate whether the condition is "satisfiable" or call the path "live" — that is the wrong frame and produces a false positive. The grant is unused and removable; the correct recommendation is "no fix needed (optionally remove the inert grant)", never "harden / pin / monitor it."

3. Classify the wildcard grants (W1-W5)

Each Allow statement gets at most one wildcard finding (W1 > W3 > W2 > W4 > W5):

• *W1 (critical) — `Action '' on Resource ''`.* Full administrator by value. Every

privesc combo is a subset of this one grant, so report it as the single headline rather than enumerating a dozen restatements.

• W3 (high) — `Allow` + `NotAction`. This is "allow everything except a short list," not

"allow these few." It reads narrow and is one of the broadest possible shapes. The safe form is Deny + NotAction.

• *W2 (high) — service-level wildcard (`svc:`) on a sensitive service** (iam, sts, kms,

secretsmanager, s3, lambda, ec2, ...). Hands over every mutating and credential-bearing action that service exposes.

• *W4 (medium) — mutating actions on `Resource ''`** where the action supports

resource-level scoping. Broader than the workload needs.

• *W5 (low) — broad read on `Resource ''` restricted to the sensitive-data** read set:

s3:GetObject/ListBucket, secretsmanager:GetSecretValue, kms:Decrypt, dynamodb:GetItem/Scan/Query, ssm:GetParameter(s). A data-exfiltration reach whose impact depends on the data classification (behind the boundary): a flag, not a confirmed leak. W5 does not fire on benign read APIs — cost-and-usage / billing reads, Describe* / List* inventory, CloudWatch, tagging reads — on Resource '*'. Broad access to non-sensitive metadata is not a W5 finding; flagging it is a false positive.

4. Check trust-policy exposure (X1)

• X1 (high) — wildcard principal with no narrowing condition. A trust policy that allows

Principal "*" with no aws:PrincipalOrgID / aws:SourceAccount / sts:ExternalId condition lets any AWS principal in any account assume the role. A wildcard principal with an ExternalId or org condition (the cross-account vendor pattern) is fine and must not be flagged.

5. Stay quiet on the deceptive-clean policy

This is the half the naive read gets wrong in the other direction. An apparent escalation that the effective permissions neutralise is CLEAN, and the audit must say so instead of flagging a critical that cannot fire. The resolution in step 1 is what proves it. The neutralisers seen in practice, each of which must suppress the finding it looks like:

• An explicit `Deny` on `iam:PassRole` kills the E1 combo even with a scoped Allow and a

launch action present. The PassRole half is dead.

• *`Action '' pinned to one bucket** (never Resource '*'), with a Deny` on every

escalation-bearing service, expands to nothing useful. Not W1.

• A broken trust: sts:AssumeRole on an admin-sounding role whose trust policy does not

trust this principal back, and no iam:UpdateAssumeRolePolicy to rewrite it. The path is inert.

• A permissions-boundary `Deny` over a full mutation kit (E2/E4/E5/E6 primitives) on

Resource '*' collapses the effective set to read-only. The kit is capped.

• A cross-account assume narrowed by a `Condition` (an sts:ExternalId + aws:PrincipalOrgID),

with the target's trust narrowed by the same condition and no iam:UpdateAssumeRolePolicy to relax either side, is inert (see "What is NOT an escalation"). Report no escalation; recommend at most removing the unused grant. Do not call the path live or recommend hardening it — that is the false positive this fixture baits.

• A PassRole whose only passable role is read-only, and whose compute verbs

(Start/Invoke) bind no role. The shape of E1 is there; the gain is not.

On a clean policy the audit reports: no real escalation, why the apparent one is neutralised (the Deny / scope / broken trust / sealed condition), and the boundary. It does not headline a neutralised or read-only grant as critical, and does not drown the verdict in nitpicks about correctly-scoped statements.

6. Rank and report, then name the boundary

Order findings by severity (critical, high, medium, low). For each: the statement(s) it is grounded in, what the escalation is, and the fix. Then list the boundary from step "What this skill reads." A clean policy still gets a boundary section.

Severity model

The low band is deliberately honest: W5 depends on what data the resources hold, which is not in the policy. It is a flag to verify, not a verdict.

Rule reference

The matching half of every escalation rule is the clean verdict: the combo present in statements but killed by a Deny / scope / broken trust / sealed condition is not a finding. Reporting it anyway is the dominant failure mode this skill prevents.

Output format

The agent's final message in any invocation must include:

1. Principal: the role/user, how many statements across how many attached policies.
2. Findings: ranked by severity, each with the rule, the statement(s) it is grounded in,

what the escalation is, and the fix. Or "no real escalation" for a neutralised policy, stating why it is neutralised.

1. Boundary: the joins this audit could not make (other attached policies, the

permissions boundary, the org SCPs, the privileges of a targeted role), stated explicitly.

Worked examples

Seven end-to-end fixtures are committed under fixtures/, each with a runnable replay test. The set is deliberately weighted toward the deceptive-clean cases, because over-flagging a neutralised policy is the cold agent's dominant failure here:

• 08-ml-platform-passrole-launch-needle:

the needle. iam:PassRole on Resource '*' and sagemaker:CreateTrainingJob sit four policies apart across ~16 statements; only the union is the critical E1 escalation.

• 01-orphaned-passrole-deny: PassRole +

RunInstances looks like E1, but an explicit Deny on iam:PassRole kills the combo. Clean.

• 02-action-star-blanket-deny: Action '*'

reads as admin but is pinned to one sandbox bucket with a Deny on every dangerous service. Clean.

• 03-assumerole-broken-trust: sts:AssumeRole on

an admin-sounding role whose trust does not point back, and no rewrite action. Clean.

• 05-iam-mutation-boundary-capped: a full

mutation kit (E2/E4/E5/E6 primitives) capped by a permissions-boundary Deny on Resource '*'. Clean.

• 06-cross-account-assume-condition-gated:

a cross-account assume sealed by an unsatisfiable ExternalId + org-id condition at both ends. Clean.

• 07-passrole-sandboxed-role-orphaned:

PassRole + compute verbs, but the verbs bind no role and the one passable role is read-only. Clean.

Replay tests

Every fixture has a replay test in tests/ that runs the methodology (via the deterministic reference engine tests/_audit.py) against the committed policy JSON, with no external credentials. Run from the skill directory:

for t in tests/replay_*.py; do python "$t" || exit 1; done

The seven tests cover the needle (E1 from the union) and the six neutralisation mechanisms (Deny, scope, broken trust, boundary cap, sealed condition, orphaned combo). Tests exit non-zero if the audit names the wrong escalation or fabricates one on a clean policy. See tests/README.md for the fixture schema.

Failure modes

This skill is wrong in predictable ways. Read FAILURE_MODES.md before relying on it. Highlights:

• It audits the documents supplied. If only some of a principal's attached policies are

passed, the effective-permission union is incomplete and a real grant (or a neutralising Deny) may be missing.

• Deny resolution is approximated at Resource "*". A resource-specific Deny that neutralises

a grant on a concrete ARN is behind the boundary, not modelled.

• An escalation that passes, assumes, or hijacks a role is only as dangerous as that role,

whose privileges are not in this document. The severity assumes the target is more privileged; confirm it.

Anyshift integration (opt-in)

The audit above runs end-to-end against the policy JSON the user already has. No Anyshift dependency.

Every boundary note in this skill is a join: principal to its full set of attached policies, principal to its permissions boundary, account to its org SCPs, this policy to the privileges of the roles it passes or assumes. The Anyshift MCP can act as a context primer by resolving those joins from a versioned resource graph, so an E1 finding ("scoped PassRole, escalation real only if the target role is more privileged") can be closed instead of deferred. A measured "with vs without" delta will be published here once the integration has been exercised against the replay fixtures.