A policy can be valid JSON and still remove access a workload needs. Review the current and proposed permissions together, then test the requests that must remain allowed and the access that should be denied.
Guide and worked example. Use the complete policies and downloadable request tests below. Cotton’s hosted browser reviewer and ChatGPT plugin have not been published; this page does not run policy analysis.
Start with a complete worked example
A reporting job and an export job share one IAM role. Follow a narrower policy that breaks the export requirement, then a corrected draft that preserves the declared work.
Review the change, not just the policy syntax
Cotton’s review method brings policy findings, changes, declared access requirements, and unresolved checks into one review. Identify whether you have an IAM identity policy for permissions attached to an identity, or an S3 bucket policy for a bucket’s resource policy. Review these policy types separately. An IAM policy that contains S3 actions is still an IAM identity policy.
For an IAM comparison, provide the exact current policy and proposed policy, identify which is which, and describe the change’s goal. Add representative action-and-resource tests with an expected allow or deny outcome. A useful review can show that a proposal reduces access while still failing a required export request.
This guide covers review of supplied documents. It does not connect to your AWS account, discover all attached policies, change permissions, or run your application.
What do validation, simulation, and change review tell you?
Scroll across to compare all columns.
| Check | Useful evidence | What remains to establish |
|---|---|---|
| IAM policy validation | AWS IAM Access Analyzer findings about policy grammar and supported security recommendations. | Whether the proposed permissions meet your workload’s needs. |
| Permission simulation | An allow, deny, or incomplete result for supplied policies and declared requests, within the supported simulation scope. | Effective access in the real account and successful application behavior. |
| Current-to-proposed comparison | Changed grants, AWS comparison findings when available, and requirements that need attention. | Whether the requirements cover all affected workloads and relevant conditions. |
| Post-change verification | Fresh security and service observations after an authorized deployment. | Evidence must come from the deployed environment; the document review cannot supply it. |
AWS provides policy validation and the IAM policy simulator. Cotton’s review method organizes these kinds of evidence around a proposed change and the access you declare. The worked example uses authored expectations, clearly labeled as synthetic. An unavailable or incomplete check remains unresolved.
Simulation results can differ from a live request. Other policies, permissions boundaries, organization controls, session policies, resource policies, conditions, and application dependencies may affect the outcome. Preserve those gaps in the review.
Prepare inputs another reviewer can understand
- Choose the policy type. Distinguish IAM identity policies from S3 bucket policies and choose checks that support the document type.
- Label the exact documents. Current is the baseline; proposed is the change under review. A single-policy validation cannot establish what changed.
- State the objective. For example: remove broad S3 permissions while preserving the reporting and export jobs.
- Declare required and forbidden requests. Use specific AWS actions and resource ARNs. Include negative tests for access you intend to remove.
- Record missing context. Identify other policies or conditions the review has not evaluated, and the live checks needed before closure.
Use synthetic or suitably redacted inputs for evaluation. The worked example’s six request tests are downloadable without an account. They cover that example’s declared requirements, not every possible request.
Carry the unresolved checks into the next decision
A useful report retains the two policy roles, findings and their source, request-test expectations and results, missing evidence, and verification steps. Review every denied requirement before applying the change. An omitted workload requirement can make an apparently successful comparison misleading.
For the shared reporting role, the bad proposal still permits report reads and writes but omits export writes. The corrected draft restores the export requirement without restoring the broad s3:* grant. Both jobs still use the same permission set because they share the same role.
After review, follow your change process: obtain approval for the exact proposal, execute through the authorized path, and collect fresh security and service evidence. Cotton’s cloud-remediation case shows the record needed to support closure; the agent-permissions guide explains the authority boundary.
Browser reviewer and ChatGPT plugin availability
The hosted browser service and ChatGPT plugin have not been published. The complete worked policies, downloadable request tests, and review method on these pages are available now.
We’re preparing Cotton AWS Policy Review to apply this method through a browser workflow and a ChatGPT plugin. Its scope is supplied IAM identity or S3 bucket-policy documents, declared requirements, and a copyable review record. It does not grant access to your AWS account or authorize a change.
You can use this brief to frame a review with your team:
Compare these current and proposed IAM identity policies. Check the declared permission tests, identify access that the proposal removes or adds, and list what still needs verification before deployment.Include the labeled policies and tests. For a bucket resource policy, state that the review concerns an S3 bucket policy instead. Run the applicable AWS checks through your approved tools, retain their actual results, and record any remaining gaps.
Sources and scope
Reviewed 7 October 2026. The example and review method are authored by Cotton. AWS documentation describes the underlying checks and their limitations; it does not endorse Cotton or establish the result of this example.
DESIGN PARTNER PROGRAM
Bring one permission-change review to Cotton
We’re building the workflow from a finding to a reviewed change and verified outcome. Share the decision your team needs to make, the workload access it must preserve, and the evidence your reviewers require.
Explore a design partnership