Content Credentials Need Pipeline Tests

The Stamping Fallacy

We stamped our AI-generated images with C2PA manifests. Uploaded them to the live site. Visitors got raw JPEGs with zero provenance data — no manifest, no claim, no signature. The stamp itself was real. The delivery pipeline ate it whole.

This is the blind spot we keep running into with DevOps and AI teams: the assumption that applying C2PA at generation time closes the loop. It doesn’t. Stamping an asset is step one. Step two — the one almost nobody budgets for — is treating every resize, recompression, or format conversion as a provenance event, not a metadata-preservation problem. Once pixels change, the old manifest’s signed binding no longer matches the file; you either sign the final rendition after it’s generated, or run the transform through a C2PA-aware tool that issues a new claim and lists the original as an ingredient. Pixel-level watermarks such as SynthID need separate robustness tests; c2patool only validates C2PA manifests, not watermark presence.

Honestly, it shouldn’t surprise anyone. Media processing layers have spent two decades stripping metadata to save bytes. EXIF data, GPS tags, colour profiles — all routinely discarded by resize tools and CDNs, because nobody needed them and they cost storage. That old optimization habit is now colliding head-on with a compliance requirement it was never built to recognize. The tooling can’t tell a C2PA manifest from an orphaned thumbnail EXIF block. It strips both the same way, without hesitation.

The WordPress and Cloudflare Black Hole

We hit this ourselves, in our own publishing workflow. Source and claim metadata get attached under internal control rules before an asset ships. The image agent writes a valid C2PA manifest into the file before handoff. At that point, the chain of custody is intact — clean, verifiable, exactly as designed.

Then it goes through publishing. WordPress receives the upload and triggers a resize via ImageMagick to produce thumbnail and featured-image variants. In our pipeline, the resized derivatives failed c2patool validation even though the original upload passed — ImageMagick’s resize step treated the C2PA manifest as unrecognized metadata and rebuilt the file without it. Manifest gone. Before the post is even live. That’s what we measured on our own stack and configuration; treat it as the failure mode to test for, not as a guarantee about every ImageMagick version or resize flag.

Say, generously, the CMS layer does preserve it. The asset still has to clear the edge. We saw the same result after the asset passed through Cloudflare’s image optimization — Polish, resizing, format conversion to WebP/AVIF: the rendition we pulled back down from the edge had no valid C2PA manifest. Two independent layers, tested independently, both stripping the same block. Two teams that never once talked to each other. Both landing on the exact same default: strip first, ask questions never.

Default web architecture is hostile to provenance metadata. Not maliciously. Structurally.

Applying WaterDoctor PDF Rules to Media

We’d actually solved a version of this problem before, in a completely different stack. WaterDoctor’s diagnostic reports are PDFs, often heavy with embedded charts and scan imagery, and we compress them before client delivery just to keep bandwidth sane. Those PDFs carry regulatory and diagnostic metadata that has to survive compression intact — it’s the record a client or auditor may need to trace back later.

The pattern we built for that isn’t clever, and it doesn’t need to be. We push the PDF through the compression engine in a staging environment first, then programmatically check that the metadata block is present at the expected byte offset before the compressed file is cleared for delivery. If the check fails, the pipeline halts. It doesn’t guess, and it never ships a compressed file on faith.

Images aren’t architecturally different from diagnostic PDFs here — and the same logic should extend to video once a pipeline is built to handle it. Both image and PDF assets are binary files moving through a compression layer that wasn’t designed with your compliance payload in mind. Both need the same discipline: don’t trust the transform. Verify the output.

Writing the CI Survival Test

So stop treating C2PA and SynthID as media features you configure once and forget. Treat them like HTTP headers. Most mature engineering teams already write CI tests confirming CORS headers or Cache-Control directives survive a CDN round trip. Provenance manifests deserve exactly that level of scrutiny — they’re just as easy to lose in a proxy layer, and far more consequential when they vanish.

The test sequence is mechanical:

1. Generate a signed asset in the build environment.
2. Push it through the staging pipeline, forcing the actual export and resize operations your production path performs.
3. Pull the final asset back down from the CDN — not from local cache.
4. Run c2patool against the downloaded file. Pass the build only if the manifest is present and cryptographically valid.

If step four fails, the build fails. No exceptions for “it worked in the generator.”

Article 50 Means Audits, Not Suggestions

EU AI Act Article 50 moves synthetic-content marking and disclosure into compliance territory — not best-practice territory — for the systems it covers. It doesn’t mandate C2PA or SynthID specifically. The obligations split by role, and both carry qualifiers worth reading closely: providers of AI systems generating synthetic audio, image, video, or text must ensure those outputs are marked in a machine-readable format and detectable as artificially generated or manipulated, but only where this is technically feasible given the state of the art. Deployers face separate disclosure duties for covered deepfakes and for certain AI-generated or manipulated text published to inform the public on matters of public interest — and Article 50 carves out its own exceptions to those duties. Skip the liability theorizing and go straight to what matters for delivery teams: if the compliance evidence you’re pointing to is a C2PA credential, the file that actually reaches the user has to carry a valid one; if you’re relying on another disclosure mechanism, that mechanism needs its own delivery test.

If your CDN edge rule or your CMS resize hook drops the credential on the way out, your system is exposed at audit — regardless of what happened upstream, regardless of how clean your generation-time process was. From what we’ve seen building this ourselves, the failure never announces itself. It just sits there quietly until someone asks to see the manifest and nobody can produce one.

Provenance isn’t an experimental checkbox anymore. It’s a pipeline property. And pipeline properties get instrumented — or they get you named in the next compliance review.