Inside some image and video files there is a string that reads `http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia`. IPTC, the standards body for news metadata, defines that term as "Digital media created algorithmically using an Artificial Intelligence model trained on captured content." When a file carries that term inside a signed record whose hash covers the file's own bytes, you have something rare in this field: a machine-checkable statement that a generative model made this, placed there by whoever ran the model.
That is Content Credentials working. What follows is what it proves, and four things it is regularly taken to prove and does not.
What are Content Credentials, and what is C2PA?
Content Credentials is the consumer-facing name for a C2PA manifest: a signed record of origin carried inside a media file. C2PA is the Coalition for Content Provenance and Authenticity, the body that publishes the open technical specification the record conforms to. Version 2.4 of that specification is dated April 2026.
C2PA lists its steering committee as Adobe, Amazon, BBC, Google, Meta Platforms, Microsoft, OpenAI, Publicis Groupe, Sony Group Corporation, TikTok and Truepic. Membership in the coalition and presence in the trust infrastructure are two different things, and a later section of this post is about how different.
What is inside a manifest?
Four parts, in the specification's own words.
| Part | Definition, C2PA specification 2.4 | | --- | --- | | Assertion | "A data structure which represents a statement either made (or 'created') by the signer or simply gathered at claim generation-time, concerning the asset." | | Claim | "A digitally signed and tamper-evident data structure that references a set of assertions, concerning an asset, and the information necessary to represent the content binding." | | Hard binding | "One or more cryptographic hashes that uniquely identifies either the entire asset or a portion thereof." | | Manifest | "The set of information about the provenance of an asset based on the combination of one or more assertions (including content bindings), a single claim, and a claim signature." |
The assertion that decides the AI question is `c2pa.actions`: a list of things done to the content, where each action may carry a `digitalSourceType` — a URI pointing into IPTC's published vocabulary. That vocabulary holds `trainedAlgorithmicMedia`, and beside it `digitalCapture` ("captured from a real-life source using a digital camera or digital recording device"), `computationalCapture` for multi-frame merges, which IPTC notes covers the HDR processing common in smartphone camera apps, and mixed terms like `compositeSynthetic` ("Mix or composite of several elements, at least one of which is Generative AI"). A source type is what a claim actually says about origin. A software name is not — more on that at the end.
The vocabulary moves. IPTC has retired `softwareImage` (14 June 2022), and both `minorHumanEdits` and `digitalArt` (17 September 2024), while adding others. Any reader written against a snapshot will eventually meet a term it has not read, so what it does with an unknown term matters: ours refuses to treat one as either exoneration or accusation, and stands down.
The hard binding is what stops the rest from being decoration. It is a hash over the asset's actual bytes — `dataHash` for images, `bmffHash` for MP4-style containers. Change one byte and it stops matching. Re-encode the file, or even losslessly re-mux it, and it stops matching.
How do you check a Content Credential?
Two independent questions, and they have to stay independent. First: does the claim signature verify, and does the signer chain to a trust list you are willing to accept? Second: do the hard-binding hashes cover the bytes actually in front of you?
A valid signature over a different payload proves nothing. A perfect hash match signed by nobody in particular proves only that whoever made the file also made the claim about it. Collapsing the two into one "has credentials" boolean hides the case worth catching: a sound signature with a broken binding is the fingerprint of a file altered after it was signed, and the reader that flattens both into "invalid" has thrown away the distinction that identifies tampering.
There is a third question, and it is the one that is easiest to get wrong.
Which manifest in the file is talking?
A file's manifest store holds one active manifest, whose hard binding covers the bytes you have, plus a manifest for every ingredient that carries one — the specification's term for existing assets brought into this one and composited, derived or edited in. An ingredient's manifest describes that other asset. It says nothing about your bytes.
The consequence is concrete. An AI-generated image that embeds a real photograph carries a perfectly genuine camera-capture assertion in its store, and that assertion is true: it belongs to the photograph. Software that pools every manifest in the file as one set reads it and clears the composite. Ours did exactly that until the store was split, and the correction is asymmetric: an ingredient's evidence may now move a verdict away from "human" — a generative ingredient blocks any clean bill of health — and may never move one toward it. A camera original with generative work composited into it is edited, not authentic.
So what does a verified manifest prove?
That a named signer staked a certificate on a specific set of statements about a specific sequence of bytes, and that those bytes have not changed since. Nothing weaker, and nothing stronger.
It is a great deal more than a classifier can offer, because it is not an estimate at all. It is also less than the word "authentic" suggests, in four particular ways.
Does a verified credential prove the scene was real?
No. A capture assertion says a sensor produced these bytes. It cannot say what was in front of the sensor, and photographing a screen is a real capture of a real display — the analog hole, and no signature closes it. A `digitalCapture` claim over a photograph of a monitor showing generated imagery is a truthful claim, correctly signed, and completely misleading about the content.
This is why, in our own policy file, the point estimate for a proof-tier human finding is 3 out of 100 rather than 0. The residual three points are not instrument noise. They are that hole, named in the comment beside the number.
Does a verified credential prove the claim is true?
No. It proves the signer made the claim and put a certificate behind it. Someone can sign a lie, and the cryptography will confirm faithfully that they signed it. That is why the interval half-width at our highest tier is 2 rather than 0: proof of signature is not proof of statement.
Two quieter versions of the same gap show up on real files. A manifest can verify perfectly and assert nothing about origin — a clip in the C2PA's public test files verifies against its exact bytes and names a hardware-attested capture SDK, while its active manifest carries no `c2pa.actions` and no `digitalSourceType` at all. A signature over a file that never says how the content was made is not provenance of a capture, and our answer for that clip is `uncertain`. And a manifest asserting only `humanEdits` — IPTC's "Augmentation, correction or enhancement by one or more humans using non-generative tools" — establishes that a person edited something. Not that a camera made it.
Does the absence of Content Credentials mean anything?
Nothing at all, and this is the misreading with the highest cost. Credentials live inside the file's bytes, and re-encoding destroys them. Screenshots, social platform transcodes, messaging apps, format conversions, and any editing that re-encodes without writing credentials of its own all destroy them. Absence is therefore the ordinary condition of media on the internet, not a signal.
It is worth being blunt about what this rules out. A photograph a person took with an unsigned camera and an AI image that has been through one screenshot present identically: no manifest, nothing to read. Any product that treats "no credentials" as leaning either way is reporting its own blindness as a finding. When our reader finds nothing it returns a status that means only "no manifest in these bytes", and the sentence it prints says so in those terms.
Is a signed credential a trusted one?
No, and the difference is a file you can read. Verifying a signature establishes that the bytes were signed by the holder of some private key. Whether that holder is anyone in particular is a separate question, answered only by checking the signing certificate against a list somebody vouches for.
The list we ship is the C2PA's own conformance trust list, fetched on 27 August 2026 from the coalition's `conformance-public` repository and pinned in our build by SHA-256: 52 certificates, of which 30 are claim signers and 22 are timestamp authorities. Seventeen organizations hold certificates on the claim-signer half:
| Group | Organizations named in the certificate subjects | | --- | --- | | Platform and phone makers | Google, Adobe, Huawei, Xiaomi, vivo | | Certificate and content-security vendors | DigiCert, SSL Corporation, TrustAsia, Snowball Technology, Huanyu Trust, Irdeto, Castlabs | | Everyone else on the list | Verimago, Encypher, Trufo, Tauth Labs, Whole Earth Labs (RealReel) |
Set that against the steering committee. Of the eleven organizations named there, two — Adobe and Google — appear on the claim-signer list under their own names. That is not an accusation of inactivity: an organization can sign perfectly good credentials using a certificate issued by one of the listed authorities, or under a root on the older interim list, or it can not sign at all, and the trust list cannot tell you which. What it does tell you is how small the set of directly vouched-for roots still is, and that a signature is only as meaningful as the list you check it against.
There is an older list, hosted at `contentcredentials.org/trust/anchors.pem`, whose own header declares it frozen and superseded by the official one and advises validators to distinguish between the two. We do not merge them, for a measured reason: that bundle carries no Google root, so it is not a superset, and merging would make an anchor from a frozen list indistinguishable from a conforming one. The cost is real and worth naming — an asset signed only under the interim list reads as untrusted in our engine. It can still be used to accuse. It can never be used to clear.
One more gap, ours rather than the standard's. We do not check certificate revocation. The reader's OCSP fetch is switched off because a manifest may name any URL, and fetching one while parsing an attacker-supplied file turned our detection endpoint into a server-side request forgery primitive — confirmed by experiment, not inferred. So a certificate on our list that is later revoked keeps working here until a maintainer refreshes the bundle, which is why that refresh is treated as a security review rather than a dependency bump.
What to actually do with a credential you find
Ask the two questions separately: did the signature verify, and does the binding cover these exact bytes. Then ask whose manifest the assertion sits on — active, or an ingredient that was composited in. Then read the `digitalSourceType`, not the tool name: a conforming editor may emit a `c2pa.edited` action with no source type at all and identify itself only through a `softwareAgent` string, and a software name is a hint rather than provenance.
If you want to check a file yourself, the Content Authenticity Initiative publishes an open-source implementation of the specification, so you need not take any vendor's reading on trust. Ours is the Python binding over the Rust core, and every finding we return stamps the exact versions of both, so anyone who disagrees with a verdict can re-run the same bytes through the same reader and see what it actually said.
