Cloud security remediation:
how to prove a fix worked.

Start with the read that should never have succeeded

The case concerns one test object, media-test/canary.txt. At policy revision 12, an authorized anonymous read returns a simulated 200 OK. The policy also grants the application identity, media-api, read access that must remain available.

The proposed change is small: remove the anonymous read grant and retain the application grant. Nothing in this case authorizes changing object contents, deleting data, or adjusting permissions on another object.

Before making a real change, capture the original request context: target, operation, caller identity, relevant policy state, result, and observation time. Record the evidence source and collector, and retain an inspectable reference in the approved evidence system. A test performed with an administrator’s credentials would answer a different question from an anonymous read. Likewise, a successful canary read establishes the tested exposure; it cannot tell you whether someone previously accessed production data.

Confirm the legitimate dependency with the service owner, then record a successful pre-change read using the intended application identity and access path. Define the expected object response so the same behavior can be checked afterwards. If that baseline already fails, investigate before attributing a later failure to remediation. AWS explicitly advises checking that applications will continue working without public access before applying S3 public-access restrictions. AWS guidance on managing public access.

Write down what must change and what must survive

The access matrix makes the intended result reviewable before anyone approves it. In this fixture, revision 13 removes one grant. Preserving the other grant is necessary, but the service still needs a working read after execution.

Read the columns carefully: the service’s existing grant is configuration evidence, not a measured working baseline. The final column identifies the observations to collect. The “required after” column specifies acceptance criteria, not results that can be assumed from the proposed diff.

On AWS, use the platform’s own policy checks during preparation. IAM Access Analyzer checks policy grammar and AWS best practices; access previews can show how a proposed S3 policy affects public and cross-account access. These answer useful questions about permissions before deployment. The application check remains a separate task. Policy checks; S3 access previews.

Applying these checks to Amazon S3 public access

S3 guidance and linked AWS documentation reviewed 1 October 2026.

For an S3 review, translate the case’s two outcomes into checks for the real object and application. The walkthrough above remains a platform-neutral simulation. The mapping below is evaluation guidance, not an executable AWS policy or a report of a Cotton integration.

1. Establish the intended access. Name the bucket, object, application identity, and access path. With the service owner, record a successful application read before changing permissions. AWS advises checking that applications will keep working before restricting public access. AWS guidance on managing public access.
2. Review the effective controls. Inspect the relevant bucket and access-point policies, ACLs, and Block Public Access settings, including applicable account and organization controls. S3 applies the most restrictive combination of applicable Block Public Access settings. A wildcard principal alone does not establish that a policy is public; its conditions matter. S3 Block Public Access and public-policy evaluation.
3. Review the proposed change before execution. Where available, use an IAM Access Analyzer access preview to inspect how a proposed bucket policy changes public and cross-account access. Retain the proposal and preview with the exact approval. The preview evaluates permissions; the application still needs a working test. Previewing S3 access.
4. Match the checks to the approved scope. Removing a particular policy grant and changing Block Public Access are different changes. Block Public Access has no per-object setting. Review the wider effect before approving bucket- or account-level controls, then record the state actually observed after execution. S3 control scope.
5. Retest both outcomes. Confirm that an authorized anonymous test reaches the intended object and is denied, and that the intended application can still read it through its required path. Retain times and results. IAM Access Analyzer findings can take time to reflect changes, so include their evaluation time when using them as supporting evidence. S3 finding update behavior.

A failed application read or missing result keeps this case open even when anonymous access is denied. Record the gap, its owner, and any separately approved recovery action in the closure record. Broader policy changes need checks for the other affected operations and access paths.

Give the approval something precise to authorize

“Fix public access” leaves too much for an executor to interpret. A reviewer should be able to identify the object, the grant being removed, and the grant being preserved without reconstructing the request from a conversation.

The 60-second window makes expiry easy to inspect in the demo. It is not a suggested production approval duration. Choose a validity period for the actual workflow and enforce it at execution.

The simulation rejects execution after expiry or when the policy no longer matches revision 12. Changing its selected outcome resets the case and invalidates approval. A deployed workflow must also reject a substituted target, operation, or diff and obtain fresh authorization for the changed proposal. Record the approver’s identity and authority separately from the executor’s identity.

This matters when another change lands during review. Applying an old proposal to new state can erase a legitimate update or remove access the reviewer never considered. Refresh the evidence and proposal before asking for approval again.

Check the object after execution

After applying the approved change, record the observed policy revision and any execution uncertainty. Then run the two checks in the matrix. Give each observation a target, caller, method, observation time, evidence source, collector, and retained reference. Agree how fresh the evidence must be before the test, and distinguish a source’s observation time from when its result was collected.

For the security check, establish that the anonymous request reached the intended resource and was denied. A timeout, an incorrect URL, or an unavailable service gives you a different result. For the service check, use the intended application identity and verify the expected object response. Avoid treating a cached response as proof of current storage access.

A finding dashboard can help corroborate the change, but account for its update behavior. AWS documents delays before some IAM Access Analyzer for S3 findings reflect permission changes. Record when the analyzer last evaluated the configuration instead of expecting every signal to update together. IAM Access Analyzer for S3 update behavior.

The intended verifier needs separately governed access to evidence and authority to withhold closure. Identify which observations can be checked against the target or another controlled source, and which rely only on the executor’s report. Giving the executor a second prompt to summarize its own work would leave the reviewer dependent on that report. Cotton’s browser fixture illustrates the decision; it does not implement that production separation.

Two common reasons to keep the case open

The exposure is blocked, but the service fails. Preserve the passing security result and the failing application result. Assign the service impact for investigation and obtain authorization for any recovery action. Restoring the old policy could also restore public access, so “roll back” needs a considered decision and its own checks.

The exposure is blocked, but service evidence is missing. Mark that check unknown and keep the case open. Identify who will collect the missing evidence and what needs to be rerun. Silence from a test runner cannot establish that the application works.

The successful branch requires both checks to pass. You can compare all three outcomes in the interactive public-access case. For a wider evaluation, the pilot acceptance checklist also covers rejected approvals, stale state, interrupted execution, and revoked authority.

Leave a closure record someone else can use

A useful record connects the finding to its resolution without forcing a future reviewer to search across disconnected logs. This example summarizes the simulation’s successful branch. A real record needs actual timestamps, accountable identities, and retained evidence.

Carry the same fields into your own process using the reusable closure-record template. Include unresolved questions and the events that require a new review, such as a later policy change, a new exposure finding, or contradictory service evidence.

Closure describes the tested state at a recorded time. A single object read cannot demonstrate the health of every application operation. Broaden the checks when the real change has a broader effect. The automated security remediation guide explains how these checks fit into the wider workflow.

Published by Cotton. This is proposed evaluation guidance accompanying a startup developing AI security workflows. The examples do not establish shipping capabilities or assurance of any production environment.

What if a workload returns AccessDenied after the policy change?

Retain the exact caller, action, resource, error details, and current and proposed policy revisions. A denial after a change is a reason to investigate; timing alone does not establish which policy or control caused it.

Compare the changed policy with the workload requests that must remain allowed. Cotton’s AWS policy review workflow treats IAM identity policies and S3 bucket policies separately. The shared-role example shows how a narrower identity policy can omit another job’s required write.

For S3, AWS documents several possible causes of 403 Access Denied errors, including applicable policies and access controls. The supplied documents may not contain the cause. Investigate the actual environment, obtain approval for any recovery change, and repeat both security and service checks before closing the case.