AWS IAM Policy Reviewer
Review overly broad identity-policy statements without connecting to AWS. Follow a fabricated role-assumption permission from a wildcard-resource finding to a proposed narrower role ARN.
1 statement reviewed · 1 baseline candidate → 0 modeled findings after narrowing
What the saved results show
A fabricated AWS IAM identity-policy statement allows sts:AssumeRole with Resource: "*". It also includes an example principal-tag condition. The static reviewer emits one ASSUMEROLE_ALL_RESOURCES review candidate and records that a condition is present, without interpreting it.
- Baseline: one review candidate. The statement names no role ARN, so an analyst should ask which roles and accounts the permission was intended to cover. The finding does not prove that any role can be assumed; the target's trust policy and other controls still matter.
- Proposed follow-up: zero modeled candidates. I replaced the wildcard resource with
arn:aws:iam::111122223333:role/example-response-readonly, a fabricated role ARN, while preserving the sample condition. A second offline run reports no patterns from this tool's narrow rule set. It is not a tested production remediation.
How I approached it
I built a read-only Python CLI that parses an intentionally limited identity-policy JSON grammar, identifies literal broad Allow patterns, and connects each review candidate to a statement ID. It also recognizes iam:PassRole and service-wide wildcard actions; mixed action lists can produce separate candidates.
For role assumption, I treated the wildcard as a reason to investigate intended role ARNs and trust relationships—not as a vulnerability verdict. AWS action names are case-insensitive, so the tool normalizes exact sensitive-action comparisons. Unsupported policy forms are rejected instead of silently treated as clean.
Open source and reproduce
These are stored outputs from the offline CLI, with matching fabricated input policies. No AWS calls were required. The repository contains the execution instructions and focused tests.
The IAM source project has merged into main. Links pin the revision used for this case so its original evidence remains traceable. The findings remain limited to the reviewer's explicitly documented checks; merged source is not a claim of validated cloud permissions.
Scope and limits
Synthetic demonstration only. No AWS account, credential, principal, cloud resource, live permission, or deployed remediation was accessed or changed. The reviewer does not calculate effective permissions, evaluate conditions, role trust policies, explicit denies, SCPs, permission boundaries, session policies, or resource-based policies.
Before changing a real policy, I would verify authorized role access requirements, policy conditions and target trust, use approved AWS validation and access testing, and retain a rollback plan. A zero-finding result is not proof of least privilege.