groundy
Culture & Society

C2PA vs Reproducible Provenance: What AI Content Rules Can't Verify

C2PA signatures verify metadata integrity but not production truth. EU AI Act mandates labeling. Teams should log generation records to enable reproducible provenance checks.

Published 5 references
A skeptical green resin dinosaur wears a blank sealed medallion beside an open translucent case containing three molds of its body parts, against a warm ivory background.
On this page11 sections

If you ship a generative-media feature and need to decide what generation evidence to capture, the short answer is: sign with C2PA for interoperability, but treat a Content Credential as a signed claim about metadata rather than proof of how an asset was produced, and keep your own internal log of the generation record, because no current marking mechanism lets a third party re-check production after the fact. The obligation is live: Article 50 II of the EU AI Act, which requires AI-generated outputs to carry both human-understandable and machine-readable labels, has been in force since 2 August 2026. The intellectual pressure comes from a new preprint arguing for “reproducible provenance,” and it deserves a label up front: the preprint is a Work-In-Progress report from a single team, an unreplicated expert-perception study proposing a direction rather than a shipped standard, and it documents no deployed implementation. What follows maps what a credential actually asserts against what a stronger bar would require, and prices the tradeoff that marking-focused coverage tends to skip: the retention bill.

What a Content Credential actually signs

A C2PA manifest is a bundle of signed assertions attached to a media file. The signature makes those assertions tamper-evident: change a covered byte range and validation fails. That is a real property; Adobe, Google, Microsoft, Meta and Amazon participate in the coalition and have endorsed its adoption. But a signature over claims is not evidence that the claims are true. A manifest can faithfully attest “this file carries these assertions, signed by this key” while the assertions themselves describe a generation process nobody re-ran.

The stronger critique is formal, not rhetorical. A formal-methods analysis of the C2PA specifications concludes: “We find that the current C2PA specifications fail to achieve their claimed security goals. Furthermore, they also fail to achieve key additional goals, which all such provenance systems require for trustworthy deployment. As a result, C2PA may mislead users, platforms, and policymakers if relied upon prematurely.” The same analysis notes a status point that matters for compliance planning: C2PA is an industry-led effort, a coalition with technical specifications, ecosystem tools and a conformance program, not a government or international standard. Regulator expectations and coalition specifications are different kinds of authority, and conflating them is how teams end up over-trusting a green checkmark.

One caveat on sourcing: these capability findings come from academic analyses of the C2PA specification, not from the specification text itself, and the papers examine the spec as of their writing. Re-check the current spec version before finalizing a compliance position.

Where the signature stops

Three documented mechanisms define the gap between “signed” and “verified.”

Exclusion ranges. The C2PA specifications permit parts of a file to be left outside the signed region. Per the formal-methods analysis: “The C2PA specifications allow certain parts of a file (such as metadata) to be excluded from protection (Figure 3). (a) These regions can be altered without invalidating the signature, and (b) important information (e.g., location data) can be changed undetected.” A validator that reports “signature valid” is reporting on the covered ranges. What sits in an excluded range can change silently. For a trust-and-safety team, that means the green check answers a narrower question than the UI implies.

Desynchronized channels. C2PA provenance and watermarking are often discussed as layers of one defense. Mechanically they are independent checks, and a paper on authenticated contradictions states the separation plainly: “C2PA manifest validation is a cryptographic signature check over metadata [8, 7, 45], while watermark detection is a signal-decoding operation over pixel data [54, 55]. Neither procedure conditions on the output of the other.” The consequence the authors establish is that a single asset can carry a cryptographically valid manifest whose content contradicts its watermark status, and neither validation path will notice, because neither looks at the other’s output. If your moderation pipeline treats “valid manifest” and “watermark detected” as redundant confirmations of the same fact, the mechanism says they are not.

Partial credentials. The edit chain has its own completeness problem. According to the specification, as cited in a forensics study of partial C2PA manifests, “the action named c2pa.created must be written in the assertion store when an asset is created de novo, and the nature of such operation shall be recorded in a further subfield. Therefore, partial CCs are manifests that do not contain such action.” A manifest missing c2pa.created attests less than a full one: it may record edits without recording creation.

Here is the counterweight, and it cuts against dismissing C2PA. That same forensics paper is titled “Enhanced image forensics through partial C2PA-based provenance information,” and its finding is that even partial credentials carry usable forensic signal. The honest position is not “C2PA is broken, discard it.” It is that a Content Credential is evidence of a specific, bounded kind, and the bound does not reach “how this artifact was actually produced.”

The reproducible-provenance bar, and who is arguing for it

The stronger bar comes from “The Verification Crisis: Expert Perceptions of GenAI Disinformation and the Case for Reproducible Provenance,” a preprint presented at WWW Companion ‘26 in Dubai in April 2026. Two things about this source need to stay attached to every claim drawn from it: it reports expert perceptions from a single team’s survey, and its central proposal is a direction, not a deployed system. Its headline finding, that “Experts view Technical Detection Tools as the least effective long-term solution (Mean 3.4),” is a perception score on a rating scale, not a measured detection-efficacy result. It is unreplicated. Treat it as a signal about where expert confidence sits, not as proof that detectors fail.

The proposal itself is a Transparency of Methods (TOM) score, “defined as the share of applicable items of the computational reproducibility checklists by Momeni et al. (Momeni et al., 2025) (as used on the Methods Hub).” The underlying idea transfers directly to deployer decisions even if the score never ships: provenance you can re-check requires the method, not just the label. For a generated image, the method is the model and version, the prompt, the seed, the sampling parameters, the toolchain that produced the file, and the edit chain afterward. A Content Credential can assert some of these. Nothing in the credential lets a third party re-run or independently re-verify them.

That asymmetry is the article’s core finding. Post-hoc detection asks “does this artifact look synthetic?” and the surveyed experts, whatever the limits of their sample, rate that approach weakest over the long term. Marking asks “does this artifact carry a signed claim?” and the formal analysis says the claim’s scope is narrower than assumed. Reproducible provenance asks “can the production be re-checked from records?” and the answer is yes only if someone kept the records. Nobody can keep them retroactively. That is why the logging decision is the one that cannot wait for the standards argument to settle.

What your pipeline should capture now

The capture checklist follows from the verification gap, and it is an inference, not a measured result: whether logged reproducibility improves downstream moderation or compliance outcomes remains unmeasured. The recommendation rests on the documented fact that neither manifest validation nor watermark detection lets a third party re-check production, plus the labeling obligation that has been in force since August 2026. Given that, the fields worth capturing at generation time are:

  • Model and version, including fine-tune or checkpoint identifiers, since “the same model” is meaningless across silent version bumps.
  • Prompt and any negative prompt or system conditioning, which is also the most sensitive field in the list.
  • Seeds and sampling parameters (temperature, guidance, steps, sampler), the difference between “we logged the settings” and “the output is in principle reproducible.”
  • Toolchain hashes: the generator build, post-processing steps, encoders. This is what makes the edit chain auditable rather than asserted.
  • Edit chain: every transformation after initial generation, which is also what distinguishes a full manifest from a partial one under the c2pa.created rule.

Capture internally, disclose selectively. The internal log and the public credential are different artifacts with different audiences, and designing them as one thing is how teams end up either leaking prompts or asserting less than they know.

What each mechanism lets a third party re-verify

MechanismWhat it checksWhat a third party can independently re-verifyDocumented failure mode
C2PA manifest validationCryptographic signature over metadata assertionsThat the signed assertions are unaltered in covered byte rangesExclusion ranges allow undetected alteration of unprotected regions such as metadata (formal analysis)
Watermark detectionSignal decoding over pixel dataWhether a mark is present in the pixelsNever conditions on manifest validation, so the two can contradict (desynchronization paper)
Partial Content CredentialSigned assertions without c2pa.createdEdit history, not de-novo creationMissing creation action; still useful forensic signal (forensics paper)
Post-hoc detection toolsStatistical properties of the artifactNothing about provenance; a synthetic/likely-synthetic judgmentRated least effective long-term by surveyed experts, Mean 3.4, perception data from one unreplicated study (Verification Crisis preprint)
Internal generation log with controlled disclosureYour own records: model, prompt, seed, parameters, toolchain, edit chainProduction re-checkable only to the extent you disclose recordsRetention and disclosure liability; cost unquantified in these analyses

The last row is the one this article adds to the usual comparison, and its cost column is a framing, not a number. None of these analyses quantifies prompt or PII retention costs, deletion schedules, or legal exposure from holding generation logs.

The live obligation and the watermark dilemma

Article 50 II is the forcing function, and it has been in force since 2 August 2026. As the analysis of structural compliance gaps puts it: “Art. 50 II of the EU Artificial Intelligence Act mandates dual transparency for AI-generated content: outputs must be labeled in both human-understandable and machine-readable form for automated verification. This requirement, entering into force in August 2026, collides with fundamental constraints of current generative AI systems.”

The collision the paper describes is practical for anyone relying on watermarks to satisfy the machine-readable half. In synthetic-data pipelines, watermarks designed to survive human inspection risk being learned as spurious features during model training, while marks suited to machine verification are fragile under standard data processing operations. A mark that survives the pipeline may teach the next model the wrong lesson; a mark that avoids that may not survive compression and resizing. This does not make watermarking useless, but it does mean a watermark-only compliance strategy carries a documented fragility, and it strengthens the case for keeping the generation record as the layer you control fully.

The retention bill

Reproducible provenance shifts the burden of proof from post-hoc detection to pipeline record-keeping, and record-keeping has a price the marking debate rarely mentions. Treat prompts as personal data by default: users can type names, employer details, medical or legal context into a generator. Seeds and parameters are cheap to store; prompts are cheap to store and expensive to hold. Depending on your data-protection regime, a retained prompt can be a disclosure target, a breach surface, and a data-subject-request obligation. Deleting it later does not help the artifact generated yesterday, which is the tension: re-verification value lives in retention, and liability lives there too.

None of these analyses quantifies these costs, so budget counsel time rather than assuming a number. What the evidence supports is a design posture: separate the retention classes. Model, version, seeds, sampling parameters, toolchain hashes and the edit chain are low-sensitivity and cheap to keep long. Prompts are high-sensitivity; hash them, vault them, or keep them under a shorter retention schedule with a documented disclosure process, so that you can corroborate a specific artifact under process without running a permanent prompt archive. This is a bounded engineering judgment, not a validated result: the verification gap and the labeling obligation in force since August 2026 are documented, the retention design is the inference I am drawing from them, and your counsel and DPO get a vote that no preprint does.

Verdict: sign with C2PA, verify with logs

Sign with C2PA. The interop value is real, the ecosystem endorsement is broad, and even partial manifests demonstrably aid forensics. But treat a Content Credential as what the mechanism makes it: a signed claim about metadata, bounded by exclusion ranges, never conditioned on the pixel-level mark, and only as complete as its c2pa.created action. Then capture the generation record internally, model and version, prompt, seeds and sampling parameters, toolchain hashes, edit chain, under a disclosure policy you design now rather than improvise under a request later. If a lost log means you cannot substantiate a disputed asset in 2027, the missing record will matter more than any marking headline does today.

The limits deserve equal weight. The reproducible-provenance bar rests on a Work-In-Progress report from a single team, an unreplicated perception study whose TOM score is a proposal and whose pages document no deployed implementation. The detection-ineffectiveness figure is a survey mean, not a measurement. C2PA’s shortcomings are documented in academic analyses of the specification, and the spec evolves, so re-check capability claims against the current version before you finalize a compliance position. The decision you actually face is narrower than the debate: the verification gap is documented, the obligation is in force, and the log you do not capture now cannot be reconstructed when someone asks how an artifact was made.

Frequently Asked Questions

How should prompts be handled differently from other generation logs due to sensitivity?

Prompts are high-sensitivity; hash them, vault them, or keep them under a shorter retention schedule with a documented disclosure process, so that you can corroborate a specific artifact under process without running a permanent prompt archive.

When did the EU AI Act labeling obligation for AI-generated content come into force?

The obligation is live: Article 50 II of the EU AI Act, which requires AI-generated outputs to carry both human-understandable and machine-readable labels, has been in force since 2 August 2026.

References

Follow the links in the article for context. The supporting material is collected here for further reading.

  1. Analysis of structural compliance gapsarxiv.orgAccessed
  2. Formal-methods analysis of the C2PA specificationsarxiv.orgAccessed
  3. Paper on authenticated contradictionsarxiv.orgAccessed
  4. Forensics study of partial C2PA manifestsarxiv.orgAccessed

Join the discussion

Share a useful perspective or ask a question about this article.

Discussion guidelinesComments privacy