S3 annotations move the label without moving the bytes, and checksums cannot see it

A writer on dev.to took a patient health record sitting in Amazon S3, a file stamped as regulated under HIPAA, and changed its security label to "public" ^[1]. By their account the file itself was never touched, not one byte, and the object's checksum was identical before and after ^[2].

That is the whole problem in one sentence. According to the author, every integrity monitor you could aim at that bucket would have looked, seen nothing, and gone back to sleep, because nothing about the file did change: what changed was the context wrapped around it ^[3][4].

The mechanism is S3 annotations, which the author describes as a feature only a few weeks old, announced by AWS in June 2026 ^[5][6]. The pitch is generous by design. Where the older attachment points, object tags and user metadata, are small, annotations carry up to a full gigabyte of structured context per object, can be changed at any time without rewriting the object, and flow automatically into an Apache Iceberg table you can query with Athena ^[7][8]. AWS aimed it at AI agents and analytics, the author writes: give data enough context that an agent can find and understand it without a human in the loop ^[9].

Read the mutability property again, because it is the entire security story. The context can move while the object stays frozen solid ^[10]. Integrity tooling built on hashing verifies the frozen part. It is structurally blind to the part that decides who may read the file, what retention applies, and whether an autonomous agent treats the contents as shareable. A hash match is now evidence about bytes only, not about classification ^[11].

The second-order consequence the author lands on is permissions. If context is a first-class, independently writable thing living on the object, then the permission to write that context is also first-class and independent, which means somebody could be holding it without you realising you handed it over ^[12].

To make the break mean something, the author built a legitimate pipeline first: a document classifier that inspects a file, decides how sensitive it is, and writes the verdict onto the object as an annotation, across four levels from public through internal and confidential to regulated ^[13]. The classifier is deliberately dumb, no Bedrock and no model, just rules and regex over patterns like Social Security numbers, card numbers, and terms such as HIPAA, PHI, MRN, salary, and runbook, kept that way to stay free and reproducible ^[14][15]. One design choice does load-bearing work: the rules run most-restrictive first, so regulated beats confidential beats internal beats public, and a file that trips two rules gets the scarier label ^[16].

Note that the "annotations replace your metadata database" argument was already published by others, along with a follow-up on how moving context onto the object changes who is allowed to edit it ^[17]. The unwritten piece, per the author, was the security one.

What to watch: whether your inventory of who can write annotations exists at all, separately from who can write objects; whether anything in your detection stack reads annotation change history out of the Iceberg table that S3 populates ^[8]; and whether the agents you are pointing at that data will accept a downgraded label without a second check. This is one practitioner's demonstration on a young feature, not a disclosed vulnerability, and it should be treated as a monitoring gap to test in your own account rather than a finding to forward.