This rule detects AWS CloudTrail events where a principal alters a bucket's ACL to grant public read or public read/write access via the PutBucketAcl API call, and the principal performing the change is a newly observed identity (not present in the history window). It targets canned ACLs such as public-read and public-read-write, which can bypass some Block Public Access controls. The detection uses a history window (now-7d) to establish baseline identities and flags new ones that succeed in applying these public ACLs. It filters for CloudTrail events from s3.amazonaws.com with a successful PutBucketAcl, while excluding known automation users (e.g., Terraform, Pulumi, CloudFormation) to reduce noise. The rule is designed to surface potentially compromised credentials or misconfigurations that could expose bucket contents to unauthenticated users, aiding early containment of data exfiltration risks. It is intended for Cloud data sources and Cloud Service contexts. The rule provides triage steps, remediation guidance, and links to AWS documentation. The historical-identity angle helps detect sudden changes in access control by unfamiliar principals, which is a common post-compromise or misconfiguration signal in cloud storage. Overall, this rule helps identify newly used identities attempting to open bucket ACLs to public access, enabling operators to verify authorization, assess exposure, and enforce stronger access controls (e.g., enabling Block Public Access at account or bucket level) to mitigate risk of inadvertent or intentional data exposure. The rule includes a false-positive note for static hosting scenarios and prescribes targeted follow-up to confirm legitimate use versus compromise.