Check a permission change before it ships
Review an AWS cloud permission change and test that a fix keeps the access people need.
Runs in your browser. No policy upload.
Checking the proposed permission…
Database deletion
Database deletion
Why review this?
The engine is checking the supplied proposal.
Inspect the request and source evidence
AWS (Amazon Web Services) is the cloud platform in this example. ImplicitDeny means the supplied policy does not grant this request. ExplicitDeny means an applicable rule blocks it. Allow means the supplied policy permits it.
Engine decision for deletion: current policy Checking…, proposed policy Checking….
Checked request
rds:DeleteDBInstanceStatement from proposed policy
Loading source…
Evidence
Resolving citation…Remove deletion and keep report access
Compare the policy before and after the fix, then test both requests.
Original change: awaiting the engine check.
Required access
s3:GetObjectRequired resourcearn:aws:s3:::reports/daily.csvEdit candidate and required access
Report access must still work. Missing information or a new serious finding stops the check.
Not checked yet
Select Verify correction to test both requests.
Download the result with its evidence
Each result is saved with the exact policies, the cited policy lines and the engine that checked them.
Inspect the exact record
Keep a record of the review
Export the original review, correction and source evidence in one JSON record.
What the record includes
- The permission request
- Current and proposed policies, the action, resource and supplied condition context.
- The reason for review
- A deterministic result and the statement and source line behind it. The original proposal stays visible.
- The correction check
- Risk closure, required-access preservation and introduced high or critical findings, checked separately.
- The portable record
- Exact inputs, SHA-256 identities, engine and schema versions, citations, corrected outcome and scope limits.
Limits
A checked correction covers only the supplied policies and the access requests you declare. It is not an account-wide safety check or production approval.
Which account rules are outside this check?
Organisation-wide restrictions, limits on roles, temporary-session rules and cross-account access are excluded. Engineers know these as SCPs, permission boundaries, session policies and cross-account interactions.
AWS Access Analyzer already provides new-access checks. PolicyLens offers a smaller, inspectable workflow. Independent comparison with the AWS simulator remains outstanding.
Review your own policies
Open or paste current and proposed JSON. Declare the access to check.
Open policy reviewCheck who can do what in an AWS account
A deterministic policy engine makes each decision and cites the statement and line behind it. If you enable Claude, it only explains the engine’s results.
- 1 Loads the sample account snapshot
- 2 Lists who can delete the prod-1 database
- 3 Finds paths to administrator, including role chains
- 4 Lists resource policies open to other accounts
Add a policy and select Analyse policies. Findings appear here with severity, evidence lines and a suggested fix.
After analysis, this tab lists the normalised statements the engine works from. Use it to check any cited answer.
Check who can perform an action across a whole account. Load an account snapshot in the format of aws iam get-account-authorization-details. Analysis is deterministic and cites the granting statement or escalation path. Run sample account check above runs all three checks on a sample account.
Who can perform an action
Reach administrator
Lists principals that can become administrator directly, by assuming a role, or through a privilege-escalation technique, with the path for each.
Resource-policy exposures
Finds KMS key policies, S3 bucket policies and other resource policies in the snapshot that grant access to an external account or the public. Each result is a cited finding, listed separately from admin paths.
Review a permission change
Add your current and proposed policies, name the action to check, then test a correction that keeps the access people need.
Checks run on your PolicyLens server. Optional AI sends extracted facts to Anthropic only when requested and configured.
Current and proposed policies · edit inputs
ConditionalAllow means access is unresolved: information is missing or a condition is unsupported. It cannot prove access is preserved.
Add both policies and the action to check, or load the made-up example.
Original proposal
The checked transition and granting statement will appear here.
Corrected candidate
Review the proposal first, then verify a correction. The original result stays visible.
Edit and verify correction
Verification covers the declared risk and required request only.