Limits in AI imagery authorship and provenance
Introduction
In early 2024, I wrote about an idea borrowed from galleries: wall labels as UX for AI disclosure. A wall label does two things at once: it gives viewers a shared vocabulary (“digital print”, “oil on canvas”), and discloses how a piece came about. In this analog form, it’s anything but a cryptographic guarantee. It is a social and institutional convention.
Since then, two digitally-native approaches have moved from research and specification work into real tooling:
SynthID: watermark-based signals for AI-generated media, plus vendor tooling to check for those signals.
C2PA Content Credentials: signed provenance metadata that can be displayed by platforms (for example through the “cr” icon on LinkedIn).
Both aim to reduce ambiguity around AI content. Both also run into practical limits. In my own tests, the gap between what the standards promise and what survives in real workflows came from three places:
Detection is not provenance (watermarks can be present or absent for reasons that do not map cleanly to “real vs AI”).
Provenance is not automatically complete (provenance data can omit inputs or be recorded at a different layer than the one a verifier displays).
Trust models differ (C2PA is built around a specific ecosystem of issuers and policies, which does not naturally align with, for example, the European eIDAS trust framework).
Terms: authorship, provenance, detection
I will use three terms consistently:
Detection: a signal that correlates with a certain process (for example, a watermark detector returning “present”).
Provenance: a structured, tamper-evident record attached to a file (for example, C2PA manifests).
Authorship: a claim that a specific person or organisation stands behind the content in a way that is legally and operationally meaningful.
These terms overlap, but they are not interchangeable. A watermark can be good detection while being weak at determining authorship. A provenance manifest can be cryptographically correct while still omitting the inputs that matter to a reader, e.g. authorship identity.
Introduction to SynthID
SynthID is, at its core, a watermarking system paired with a detector. For the image modality, the promise is not really to “prove the full story”. The promise is closer to: “embed an imperceptible signal at generation time that can later be detected by compatible tools, even after some common edits”.
Two consequences matter in practice:
A positive detection can be informative (it suggests that, at some point, the media passed through that watermarking pipeline).
A negative detection is not equivalent to “not AI” or even “not from that vendor”. Put differently: robustness is not the same as invariance; and normal image handling can break that detection.
This is not a failure of the concept. It is the boundary of what watermarking can realistically do in open ecosystems. Watermarking can complement provenance. But it cannot replace provenance.
Introduction to C2PA
C2PA Content Credentials attaches a signed manifest store to media. The manifest can include:
actions (created, edited, opened, converted),
information about the signing entity (issuer, certificate chain),
optional ingredients (inputs), and
optional thumbnails or references that a verifier can display as a “history view”.
Two points are easy to miss when reading only the high-level narrative:
C2PA signs claims, not reality. It gives you cryptographic integrity of the statement, not a guarantee that the statement is complete.
C2PA is an ecosystem, not just a format. Which issuers are accepted and which fields are surfaced is controlled by policy, trust lists, and platform decisions.
A minimal lab tool: c2patool
The C2PA alliance has published the tool `c2patool` for working with C2PA manifests in media assets.
`c2patool <file> --info` shows whether a manifest store is present.
`c2patool <file> --tree` reveals manifest nesting.
`c2patool <file> -d --output <dir> -f` extracts the manifest store, detailed JSON, and the raw `manifest_data.c2pa` blob.
This lets you see what is actually in the file without relying on UI heuristics:
% c2patool --tree in/gemini.jpg
Tree View:
Asset:gemini.jpg, Manifest:urn:c2pa:325aa0bc-003e-ce15-a590-484494020695
├── Assertion:c2pa.actions.v2
├── Asset:Untitled
└── Asset:Untitled% c2patool --tree in/openai.png
Tree View:
Asset:openai.png, Manifest:urn:c2pa:89648ab5-0581-40cf-96f0-2b04169b3638
├── Assertion:c2pa.actions.v2
└── Asset:image.png, Manifest:urn:c2pa:a2363d4d-ac87-4be8-8a1d-8faf6072960d
└── Assertion:c2pa.actions.v2What my C2PA experiments found
1. OpenAI gpt-image outputs: “opened” at the top, “created” inside
Across three OpenAI images (no input image, one input image, two input images), the structure was consistent:
2 manifests
active manifest action: `c2pa.opened`
a nested `image.png` asset with its own manifest that includes `c2pa.created` (and a `softwareAgent` field in that nested manifest)
A verifier that renders the active manifest can end up showing an “ingredient” preview that looks like the output itself, because the “ingredient” is effectively that nested `image.png`. This is a plausible explanation for the “ingredient thumbnail equals output thumbnail” effect you noticed in the web verifier.
In the C2PA web verifier, this gets displayed as an ingredient that is the same as the output:
The second observation is more important for “provenance as disclosure”: in my tests I could not match the hashes in the manifest to the hashes of my local input images (QR codes). In other words, these particular manifests did not allow me, as a third party holding candidate inputs, to verify “this exact input file was used”.
This is still useful provenance, but it is not “full recipe transparency”.
2. Google Nano Banana Pro output: ingredients exist, but are not resolved as inputs
For the Gemini sample, the manifest had:
1 manifest
action: `c2pa.created`
2 ingredients with relationship `inputTo`
However, in the extracted JSON these ingredients did not resolve to titles or thumbnails, and I could not match them to local input images by hash. In practical terms, this makes the provenance graph visible (”there were inputs”) without enabling a third party to confirm what those inputs were.
Depending on what one expects from “provenance”, this can be either acceptable or disappointing. It is at least a concrete point to document: the manifest can encode “inputs existed” without encoding “inputs are verifiable / recoverable”.
In the web verification tool, this is also rendered as unknown ingredients:
3. LetzAI outputs: no C2PA at all
I also tested three images generated with LetzAI, with their own first party image generation models. `c2patool --tree` returned:
Error: no JUMBF data foundAnd the web verification tools confirms:
No Content CredentialSo in practice, C2PA support is neither universal nor consistent.
The missing “Created by” field
LinkedIn documents a Content Credentials experience that can include fields like:
whether AI was used,
the app or device used,
who issued the credentials,
and potentially a ”Created by” field.
In my LinkedIn screenshot, fields like “App or device used” do appear, but “Created by” is absent. `c2patool` confirms that this field is not included by either image generator.
A reason for this could be that image generation platforms do not have a cryptographic mechanism for person-level authorship that they can responsibly publish. To show “Created by Nils Durner” in a verifiable way, a platform would need at least:
a stable identity binding (identity proofing),
key management per identity (including issuance, revocation, recovery),
a privacy model (what is disclosed to whom),
and a trust model that platforms like LinkedIn accept.
What we do get today is typically just product/service accountability: “Issued by OpenAI” or “Issued by Google LLC” - without authorship/responsibility established or disclosed.
Trust, governance, and eIDAS
C2PA does not just standardize a file format. It also comes with a governance layer: a policy-driven trust model for who is allowed to sign Content Credentials in a way that verifiers and platforms will accept.
In practice, this behaves like its own PKI ecosystem, centered around conformant issuers and generators (products and services), not around natural persons. The result is a useful baseline (”Issued by OpenAI”, “Issued by Google LLC”), but it does not naturally answer the question “which individual stands behind this?”.
This is where the comparison with signing PDFs is helpful:
For PDFs, Europe has a strong, interoperable trust anchor via the EUTL (and national Trusted Lists). In the document world, that has become the default way to validate qualified signatures and seals across borders.
For C2PA, the trust anchor is not the EUTL. It is the C2PA ecosystem itself, with its own expectations about which CAs and certificates represent a conformant signer.
That looks a bit like the historic split between EUTL (European trust lists) and AATL (Adobe’s Approved Trust List) in the PDF ecosystem: interoperability depends not only on cryptography, but on which trust store a verifier chooses to ship. C2PA verifiers are not generally designed to treat eIDAS trust lists as sufficient for accepting a C2PA signer.
A second friction point is purely technical: C2PA claim signing uses COSE (CBOR-based signatures), whereas qualified signing workflows in Europe prefer ETSI CMS/CAdES (ASN.1/DER with signed attributes). Even if both ultimately sign bytes, they do so in different containers with different conventions. That makes “just sign the C2PA bytes with a qualified certificate” at least non-trivial in typical qualified signing setups.
So today, the mainstream C2PA verification and platform UX is built around yet another, aside from Web PKI and EUTL, trust framework and a different signature format, optimized for product-level provenance rather than person-level identity. This is why we cannot simply re-sign C2PA to bind media assets to our identity.
Conclusion
SynthID and C2PA are shaped by the ecosystems that deploy them:
SynthID gives a vendor-scoped detection signal. Practical image handling and editing workflows do disable that signal, despite claims to the contrary.
C2PA gives a signed provenance record, usually at product/service granularity. Again, practicalities leave much to be desired.
eIDAS, on the other hand, gives strong, regulated identity and accountability, but it does not plug into the current C2PA trust model and COSE-based signature container.
If you need provenance, the most honest path today is layering: let C2PA speak for the generator, and let an eIDAS-compliant container speak for the accountable human or organization.