SkillVaultskills Browse all 500 skills

Infrastructure · Version 1.1.0 · Reviewed 2026-08-02

IAM Least Privilege Reviewer

Review and harden escalation path analysis and wildcard grant reduction with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Reduces identity and access risk by finding privilege escalation paths, wildcard grants, unused permissions, and trust misconfigurations.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Escalation path analysis
  • Wildcard grant reduction
  • Unused permission cleanup

How IAM Least Privilege Reviewer works

You provide

Role policies, trust relationships, and access history

It inspects

Escalation paths such as PassRole plus compute-create

It decides

Scoped policy with the escalation path closed

You verify

Attempt the escalation and confirm it now fails

What it checks first

IAM Least Privilege Reviewer reduces identity and access risk by finding privilege escalation paths, wildcard grants, unused permissions, and trust misconfigurations. Use it when the work involves Escalation path analysis, Wildcard grant reduction, Unused permission cleanup.

  1. Escalation paths, especially permissions that let a principal assume or grant broader access.
  2. Wildcards in action or resource, which almost always exceed the intended scope.
  3. Trust policies, since a permissive principal condition matters more than the permission list.
  4. Actual usage from access logs, which reveals the permissions that were never needed.
  5. Whether credentials are long-lived static keys or short-lived workload identities.

Failure modes it recognizes

  • PassRole combined with a compute-create permission, letting a narrow role launch a workload as a broad one.
  • A wildcard resource on a data action, granting access to every bucket or table rather than one.
  • A trust policy with an overly broad principal, allowing assumption from an unintended account.
  • Permissions granted during an incident and never revoked afterwards.
  • A managed policy attached for convenience that includes far more than the task requires.
  • Conditions written on attributes an attacker controls, so the condition is not a constraint.

Answers it will reject

  • Granting administrative access to unblock a deployment, with a promise to narrow it later.
  • Reviewing the permission list while ignoring the trust relationship that decides who can use it.
  • Assuming a role is minimal because it has worked without incident.
  • Denying a specific action instead of removing the broad grant that permits it.

Decision rules it applies

  • Scope PassRole and any delegation permission by explicit resource, never by wildcard.
  • Derive the permission set from observed usage, then remove what was never called.
  • Prefer short-lived workload identity over static keys wherever the platform supports it.
  • Review the trust policy with the same rigor as the permission policy.

Evidence it asks for

  • Run an access analyzer or equivalent to enumerate reachable escalation paths.
  • Compare granted actions against actually-invoked actions over a full business cycle.
  • Attempt the escalation path after remediation and confirm it now fails.

The method inside

  1. Map the artifact, actors, boundaries, and invariants relevant to escalation path analysis.
  2. Trace concrete failure or abuse paths for wildcard grant reduction; do not report checklist items without a mechanism.
  3. Prioritize unused permission cleanup findings by impact, likelihood, confidence, and cost of correction.
  4. Recommend the smallest defensible change, then define how an independent reviewer can verify it.

Deliverables

  • Escalation path analysis assessment
  • Wildcard grant reduction decision and action plan
  • Unused permission cleanup verification checklist

Evidence requirements

  • Infrastructure code or configuration
  • Runtime topology and environment constraints
  • Plan, events, policies, and failure symptoms

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Review this IAM role. It has worked fine for two years so we assume it is reasonable.

Expected output

Working fine is evidence of sufficiency, not of least privilege. The material risk here is an escalation path: iam:PassRole combined with a compute-create permission lets this role assume any role it can pass, which is usually broader than the role itself. Scope PassRole by resource before touching anything else...

Boundaries and compatibility

Ideal for

  • Escalation path analysis: produce a decision or artifact grounded in supplied evidence.
  • Wildcard grant reduction: produce a decision or artifact grounded in supplied evidence.
  • Unused permission cleanup: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Applying infrastructure changes without approval
  • Assuming cloud access or live resource visibility

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.