By Neeraj Kumar Yadav · AWS permissions
Start with a concrete change
Suppose a statement allows s3:GetObject on a particular bucket path. A pull request adds s3:DeleteObject. A structural comparison can report that new action entry and point to the changed statement.
Before: ["s3:GetObject"] After: ["s3:GetObject", "s3:DeleteObject"] Observed: s3:DeleteObject was added.
That is useful evidence for a reviewer. It is a narrower claim than saying the role can now delete every object.
The policy file is part of a larger decision
AWS evaluates access using the applicable policy context. Depending on the request, that can include identity policies, resource policies, permissions boundaries, session policies, and organization controls. Explicit denies and the details of the request matter.
A tool that receives only two documents does not automatically possess that wider context. It should not present a structural comparison as a complete account-level authorization decision.
Avoid confusing formatting with behaviour
Reordering an action array should not create added-action findings. Matching statements and normalizing supported representations helps reduce noise. Unsupported constructs should stay visible rather than silently receiving a reassuring result.
Conditions deserve their own attention
The action list can stay the same while a condition changes. A reviewer needs to see that change too. A first structural tool can show the before and after values without pretending to infer every consequence.
Separate evidence from interpretation
- Observation: which action, resource, condition, or effect changed?
- Source: which statement and which analysis produced the finding?
- Scope: which documents and supported constructs were evaluated?
- Uncertainty: what still requires context or human review?
Use AWS analysis where appropriate
IAM Access Analyzer provides policy validation and custom policy checks. A review tool can surface those results alongside structural findings, identifying which engine produced each result. Some custom checks incur AWS charges.
The project I’m starting
AWS Permission Review begins with an offline CLI and synthetic fixtures. The first goal is an understandable report that makes its supported scope explicit. GitHub integration and optional AWS-backed checks follow after that foundation works.