auditing-s3-object-ownership-trustlisted

# Auditing S3 object-ownership trust: when the object, not the bucket, decides access Object stores let access be decided in more than one place, and that is where ownership trust breaks. A bucket policy is the central control most teams reason about, but each object also has an owner and, unless disabled, its own ACL, and a cross-account upload can land an object owned by the uploader rather than the bucket owner. The result is objects the bucket owner cannot fully control, ACLs that grant access the bucket policy meant to deny, and public grants riding on individual objects under a bucket that looks private. When a bucket receives objects from more than one principal, central governance is an assumption, not a fact. You audit these by checking who owns each object, whether object ACLs are still in force, and whether any object grants access the bucket policy did not intend. ## When to use - A bucket receives objects from more than one principal, including cross-account or third-party writers. - Access is meant to be governed centrally by the bucket policy, but object ACLs may still be enabled. - Cross-account writes may land objects the bucket owner does not own or cannot fully read or control. ## Scope check Audit object ownership only in buckets and accounts you own or are authorized to assess, on non-production data. Confirming access reads or controls real objects, so stay inside the authorized bucket and treat any object contents as sensitive within scope. If you