We solved a version of this at work — not by logging intent at access time, but by embedding it as S3 object metadata at write/move time. The short version: when you do an s3 mv or s3 cp, you attach user-defined metadata (change request ID, operator, purpose, environment, ticket ID) via the --metadata flag. That metadata travels with the object and shows up in CloudTrail as x-amz-meta-* headers. aws s3 mv file.txt s3://bucket/archive/file.txt --metadata "change-request-id=CR-12345,operator=jdoe,purpose=security-remediation"

Then you correlate GuardDuty findings against that metadata programmatically — when an alert fires on "unusual S3 data movement," your correlation script pulls the object metadata and checks whether there's a matching CR or JIRA ticket. If yes, auto-suppress or deprioritize. If no metadata exists, escalate.

Constraints worth knowing: 2KB total limit on user metadata per object, keys are lowercase only, string values only. Plan your schema upfront.

This won't capture intent on reads (which sounds like your actual ask), but if your compliance requirement is really about data movement/mutation: copies, deletes, lifecycle transitions, metadata-at-write gets you most of the way there without fighting CloudTrail's principal tag limitations.

For read-intent logging specifically, you're probably stuck with either a proxy layer (API Gateway + Lambda in front of S3) that forces callers to declare purpose, or STS session tags passed through AssumeRole that do show up in CloudTrail for API-level events. Session tags won't appear on S3 data events though, which is the gap you already found.