The Files Remember: Auditing Provenance on Generated Media Before You Publish
The hangover is the handoff
You generate an image, a video, or a voice track. You export it. You post it. Somewhere between the export button and the publish button, the file stops being just pixels and becomes a small backpack of claims: EXIF fields, XMP packets, container tags, C2PA manifests, vendor watermarks, maybe a prompt string, maybe a device name, maybe a local file path. Some of that backpack is useful. Some of it is a leak. Most of it is invisible to the person clicking publish.
That is the provenance hangover. The file remembers more than you think, and it forgets faster than you hope. Provenance is not a property that stays attached forever. It is a chain of custody, and every edit, screenshot, re-encode, and upload is a chance for the chain to break.
What we audited
We tested a representative set of generative image, video, and audio tools in October and November 2026. We are labeling them rather than turning this into a vendor scorecard, because the point is the pattern, not the brand. Image tools A, B, and C; video tools D and E; audio tools F and G. We inspected final exports with exiftool, ffprobe, and c2patool, then ran them through common paths: direct upload to major US social platforms, screenshot, screen recording, re-export from an editor, and sending through a workplace chat app.
We looked for four things: embedded metadata, visible watermarks, invisible or forensic watermarks, and C2PA content credentials. We also checked for accidental fields like prompt text, seed values, user IDs, GPS coordinates, device names, and local file paths.
What actually survives
| Artifact | Where it lives | Direct upload | Screenshot or recompress | Notes |
|---|---|---|---|---|
| EXIF and XMP | Image metadata | Often stripped | Rarely survives | GPS and device fields can leak |
| Container tags | Video and audio files | Sometimes preserved | Usually gone | ffmpeg copy may keep or drop them |
| C2PA manifest | Embedded or sidecar | Platform-dependent | Usually gone | A valid signature is not a truth check |
| Visible watermark | Pixels | Survives | Survives | Can be cropped or painted over |
| Invisible watermark | Pixels or audio | Maybe | Sometimes | Needs a vendor detector to verify |
| Prompt or seed metadata | XMP or JSON sidecar | Sometimes | Rarely | Easy accidental IP leak |
The C2PA piece deserves a plain-English note. A valid manifest means the file was signed by a credential and that the manifest has not been tampered with since signing. It does not prove the signer told the truth. It is a signed statement, not a fact. A manifest can say an image was generated by a particular tool, edited by a particular person, and composed with particular ingredients. That is useful. It is not a lie detector.
Three ways teams get burned
Prompt leakage. In our audit, one image tool wrote the full prompt into XMP by default. Another included a seed value and a model name. A third included the local username in an author field. None of that is necessarily sensitive, but a prompt can contain a client name, an unreleased product, or a private joke that was never meant to ship.
False confidence. A team adds C2PA signing to its export pipeline, then runs the file through a re-encoder that strips the manifest. The team still tells users the file is provenance-protected. It is not. The validator fails, and the claim becomes worse than no claim at all.
Watermark mismatch. A vendor adds an invisible watermark, but the team never tests whether its own downstream detector can find it after a platform re-encode. If you cannot verify the mark, do not promise the mark.
The pre-publish checklist
- Run exiftool or ffprobe on the final export, not the source file. The export is what leaves your building.
- Validate C2PA with c2patool and record the signer and claim generator. A green check is not enough; read what the manifest says.
- Search for prompt, seed, user ID, device, GPS, and local path fields. Strip what you do not need.
- Check the visible watermark at 100% and after a crop. If it disappears at thumbnail size, it is not doing much.
- Test invisible watermarks with the vendor detector after your normal editing and upload path.
- Re-download the asset from the target platform and re-run the checks. Platforms change files.
- Take a screenshot of the published asset and check again. Screenshots are a common copy path and a common provenance killer.
- Preserve a signed source copy if provenance matters for compliance or client delivery. Keep it separate from the published file.
- Document edits: crop, color, voice conversion, speed change, captions. A chain of custody without edit notes is just a receipt.
- Decide the disclosure tier before publishing: visible label, caption, metadata only, or none. Write the decision down so the next person does not guess.
Disclosure is a product surface
This is where provenance stops being an engineering chore and becomes product design. The export modal should tell people what is in the file. Not in a settings page three clicks away. In the moment they hit export.
A useful pattern is two clear choices: clean export and provenance-preserving export. Clean export strips prompt text, GPS, device IDs, and unnecessary metadata. Provenance-preserving export keeps the C2PA manifest and any required watermark. Show a short receipt: what was kept, what was removed, and what can no longer be verified after upload. Log the choice.
For avatar, dubbing, and voice features, surface the synthetic-media label where the audience will see it, not only in metadata. For teams that need C2PA, make the signer identity and edit history legible to a human, not just a validator. And do not treat provenance as a substitute for consent. A signed file can still be a non-consensual likeness.
What we changed in our own workflow
We added an export receipt, a CI check that fails when a generated asset carries unexpected prompt or GPS fields, and a platform round-trip test for any asset we publicly claim is provenance-protected. We also stopped assuming that a C2PA badge in an app means the file still has a manifest after it leaves the app.
The file remembers more than you think. The useful move is to decide what you want it to remember before it goes out the door.
