Provenance: the one signal that can clear a file
Every other method described in this knowledge base works backwards. It looks at the artefact — the wording, the pixel statistics, the compression history — and reasons about what is likely to have produced it. Provenance works forwards: something at the moment of creation records what happened and signs that record, and the record travels with the file. That difference is why provenance is the only evidence that can establish a file was captured by a camera rather than generated, and why every other signal, no matter how many of them agree, cannot.
The standard for this is C2PA — the Coalition for Content Provenance and Authenticity — whose user-facing name is Content Credentials. It is worth understanding precisely, because it is routinely described as a watermark, which it is not, and as proof that a file is genuine, which it also is not.
What a manifest actually is
A C2PA manifest is a small structured document carried inside the file itself, usually in a JUMBF box in a JPEG, PNG, or MP4 container. It can also live beside the file as a sidecar or be fetched from a cloud service, but the embedded case is the common one. A manifest has three layers:
- Assertions: individual statements about the content. What device or software produced it. What actions were taken — created, opened, colour-adjusted, resized. Which earlier files were used as ingredients. Whether generative AI was involved, and in what role.
- A claim: the assertions gathered together with hashes of each one, plus the identity of the claim generator, which is the software that assembled the manifest.
- A claim signature: a cryptographic signature over the claim, made with a certificate belonging to whoever is standing behind it.
Files often carry a chain rather than a single manifest. Edit a signed photograph in a signed editor and the result carries a new active manifest whose ingredient references point back at the original, so the history is a tree of manifests rather than one stamp.
The hard binding: what makes it about these bytes
The part that matters most for detection is the binding — the mechanism that ties a manifest to specific content. C2PA calls a cryptographic one a hard binding. Before signing, the claim generator hashes the actual bytes of the asset (in practice, the byte ranges of the file excluding the manifest itself) and puts those hashes in the claim. The signature then covers the claim, hashes included.
The consequence is narrow and strong. If a verifier recomputes the hashes over the file in front of it and they match the ones in the signed claim, then the manifest describes this exact file, not merely a file that once looked like it. Change one pixel, re-encode the video, crop the frame, and the hash no longer matches: the binding fails and the verifier must treat the manifest as not applying.
This is the opposite trade-off from a soft binding — a watermark or a perceptual hash — which is designed to survive re-encoding and cropping precisely because it is not tied to exact bytes. Soft bindings are robust and approximate. Hard bindings are brittle and exact. For establishing that a particular file is what it claims to be, brittle and exact is the property you want.
What a valid manifest proves, and what it does not
- It proves: a specific signer, holding a specific certificate, put their name to this specific set of statements about these specific bytes, at a specific time.
- It does not prove the statements are true. A signature establishes accountability, not honesty. If a signer asserts that a synthetic clip was captured on a camera, the signature is valid and the claim is a lie. What the signature buys you is knowing exactly whose lie it is.
- It does not prove anything about a file that has none. Manifests are stripped by almost every social platform, by most screenshot paths, and by any re-encode. Absence of provenance is the ordinary condition of media on the internet, and it carries no information about origin whatsoever.
That last point is the one most often misread. A verification tool reporting "no Content Credentials found" is reporting that it learned nothing, not that the file is authentic. Any product that turns silence into an acquittal is making up evidence.
The trust list is the exoneration attack surface
Because a signature only establishes who is speaking, a verifier has to decide whose voice counts. That decision is a trust list: a bundle of certificate authorities and signer certificates whose manifests the verifier is willing to act on. A manifest that verifies cryptographically but chains to nothing on the list is data, not evidence.
Here is why that bundle deserves more scrutiny than any model in the system. A detector's most consequential output is not an accusation — it is an exoneration. If our engine issues a verdict of "human," it does so on positive provenance of the exact bytes and on nothing else. So the set of certificates on the trust list is exactly the set of parties who are able to make this product declare synthetic footage authentic. Add one careless authority and you have not degraded accuracy at the margin; you have handed someone a switch.
Three consequences follow, and they are the ones we act on:
- The bundle is pinned by hash. The trust anchors are checked against a recorded SHA-256 at load. A change to that file is a security review with a written rationale, not a dependency bump that rides along in someone's routine update.
- Unknown means withhold, never grant. When a manifest declares a source type our build does not recognise and classify, the correct behaviour is to decline to issue a human verdict — not to fall back on the assumption that an unfamiliar label is a benign one. Ambiguity resolves against exoneration, every time.
- The list stays small. Every anchor is a liability that has to be justified individually. Breadth of coverage is a feature request; the ability to falsely clear a file is a defect.
Revocation, and why we deliberately do not check it
Ordinary certificate handling includes revocation: before trusting a certificate you ask whether it has been withdrawn, usually via OCSP or a certificate revocation list. Skipping that check is normally a mistake, so it is worth being explicit that here it is a decision, and about what it costs.
The problem is where the URL comes from. The OCSP responder address is carried inside the certificate, which arrives inside the manifest, which arrives inside a file uploaded by a stranger. Fetching it means an untrusted document gets to name an address our servers will connect to. That is a textbook server-side request forgery primitive: an attacker crafts a manifest pointing at an internal address, a cloud metadata endpoint, or a host they control, and uses our verification path as a proxy for reaching things they cannot reach themselves — or as a timing oracle for what exists on our network. A detection endpoint that anyone can post a file to is precisely the wrong place to add attacker-controlled outbound requests.
So revocation fetching is switched off, and we say so rather than leaving it as an unstated default. The residual risk is real and bounded: a certificate that has been revoked but whose signature still validates would be accepted by our verifier. What bounds it is the trust list itself. Because the anchor set is small, pinned, and reviewed, the response to a compromised signer is to remove the anchor — a deliberate change to a file under review, which takes effect for everyone at the next deploy — rather than to depend on a network call made from inside the request path of an untrusted upload.
What this looks like in a verdict
In our engine, provenance sits at the top of an ordered ladder of independent checks, and the strongest check that fires decides alone. Nothing is blended, and agreement between checks never narrows the reported range: a cryptographic signature and an estimate derived from pixel statistics share no common scale, so combining them would manufacture a number rather than measure one.
For images, a check below provenance can still identify a synthetic file — a pixel classifier reads the picture when no manifest settles it. It can only ever point one way: a low score is reported as inconclusive, because a laundered AI image scores low too.
For video, provenance is not merely the strongest signal, it is the only one capable of deciding. No watermark scheme is deployed at a scale worth decoding. Container and encoder ballistics identify the last program that wrote the file, not the origin of the footage. Perceptual hashes are computed and returned, but there is no corpus to look them up in. And there is no synthetic-video classifier — sampled keyframes are scored with the still-image model and those scores are published, never allowed to decide. A signed file can be settled outright; an unsigned one gets a real provenance report and an uncertain verdict, because nothing that can honestly decide it exists yet.
Practical notes if you rely on provenance
- Preserve originals. The manifest survives copying and archiving; it does not survive a re-encode, a screenshot, or most upload pipelines. Keep the file you received, not the version the platform handed back.
- Ask for the original, not a screenshot. When authenticity matters, a screenshot is the format that guarantees no evidence is present.
- Read the assertions, not just the badge. A valid signature on a manifest that asserts no origin decides nothing. What settles a file is a capture or generation claim from a signer you accept.
- Treat absence as absence. No credentials means no information. It is the normal case, and it is not a finding about the content.
Conclusion
C2PA is the strongest evidence available to anyone verifying media, and it is strong for a reason worth restating: it establishes a signed relationship between a claim and an exact sequence of bytes. That is a different kind of statement from any inference drawn out of the content itself, and it is the only kind that can support saying a file is genuine.
It also concentrates risk. Everything rests on who is allowed to sign, which makes the trust list the component to guard hardest and change most reluctantly. A detector that adds anchors casually, or that lets an untrusted file dictate what its servers connect to, has traded away the one guarantee provenance was supposed to provide.