Content Credentials prove the camera. They do not prove the photographer.

C2PA is the most serious piece of work the industry has produced on media provenance, and it does exactly what it says: it records which device and which software produced and edited a file. It does not assert that a particular accountable human captured or published it. For most provenance questions that is correct and sufficient. For the ones where money, liberty or a byline is at stake, it is the wrong question.

It is 23:10 and a picture editor has an image she needs to decide about before the morning edition. It arrived through a freelancer she has worked with twice. It carries a valid Content Credential: a signed manifest naming the camera model, the capture time, the raw conversion, two crops and a levels adjustment in a known editor. The signature verifies. The manifest is intact. Nothing has been tampered with.

She still cannot answer the only question her legal desk will ask her in the morning, which is not "was this file edited" and not "was this made by a generative model". It is: who is standing behind this picture, and will they still be standing behind it when someone disputes it?

The manifest tells her a camera took it. It does not tell her whose hands were on that camera. It cannot tell her whether the freelancer she trusts captured it, or bought it, or was handed it by someone with an agenda, or had their laptop and signing keys taken from them at a checkpoint four days ago.

This is not a flaw in C2PA. C2PA was built to answer a different question, and it answers that one well. It is a gap in what the industry has decided provenance means, and it is worth naming precisely, because a great deal of policy is currently being written on the assumption that the gap is not there.

What do Content Credentials actually prove?

Start with what is genuinely there, because the critique is only worth reading if the description is fair.

The manifest

The Coalition for Content Provenance and Authenticity, formed out of work at the Content Authenticity Initiative and the Project Origin effort, published a specification whose 2.x line is the current basis for deployment. A Content Credential is a manifest attached to or associated with an asset. It contains assertions, which are structured statements about the asset: what device captured it, what actions were taken on it, what software performed them, what the ingredients were if the asset was composed from others, and whether generative tools were involved.

The manifest is hashed and signed by a claim generator using a certificate from a recognised issuer. A verifier can check the signature, confirm the manifest has not been altered, and walk the chain of manifests back through the edit history where each step preserved the prior credential.

What the signature actually covers

This is the part worth being precise about, because it is where the reasonable inference stops.

The signature establishes that an entity holding a particular signing key asserted these statements about this asset, and that neither the statements nor the asset have changed since. That entity is a camera manufacturer's secure element, an application vendor's cloud service, an enterprise's signing infrastructure, or a creator's issued certificate. The trust anchor is the certificate authority and the entity behind the key.

So a verified Content Credential lets you say, with real confidence: this file was produced by this class of device or this software, edited in these ways, and signed by this entity. That is a substantial improvement over the previous state of affairs, which was nothing at all.

This is real engineering, and it works

Content Credentials have shipped in camera hardware from major manufacturers, in Adobe's creative tools, in generative products from several large labs, and in platform surfaces. The Content Authenticity Initiative reports membership in the thousands of organisations. Reporting in July 2026 described TikTok joining the C2PA steering committee. The European Union's AI Act transparency duties, which apply from August 2026, have pushed provenance from a good idea to a compliance question for anyone generating or distributing synthetic media at scale.

None of that is marketing. It is a standards effort that got built, shipped and adopted, which is rarer than it should be. Anything below should be read as a description of scope, not a criticism of the work.

Why does almost no content on the internet carry a credential?

Here is the awkward operational fact that even sympathetic analysis acknowledges: in practice, most content in circulation carries no Content Credential at all, and a large share of what starts with one loses it.

The reason is mundane. Ordinary distribution pipelines strip metadata. Image processing that resizes for a feed, transcodes for bandwidth, or reformats for a device commonly discards everything that is not pixels, because that behaviour predates provenance by two decades and was originally a feature, since it removed location data and device serial numbers that nobody intended to publish. A screenshot destroys the credential completely and screenshots are how an enormous fraction of images actually travel.

The inference problem this creates

The stripping problem has a second-order consequence that matters more than the first, and it is the one that limits what a viewer can conclude.

If credentials were universal, then an image without one would be suspicious. Because credentials are sparse, an image without one is simply an ordinary image. That means the absence of a credential carries no information. A verifier can say "this file is credentialed and here is what the manifest says", and can never say "this file has no credential, therefore be careful", because that describes almost everything.

So the practical inference available to a reader today is one-sided. A present credential adds information. An absent credential adds none. Any system that assumes otherwise, including any regulatory scheme that implicitly treats missing provenance as evidence of synthesis, is building on a floor that is not there yet.

What is the gap, exactly?

Now the narrow point this whole piece exists to make.

A Content Credential binds an asset to a device, a tool chain, and a signing entity. It does not contain, and does not claim to contain, an assertion that a particular named human captured, composed or published the asset and accepts responsibility for it.

For a great many uses that is precisely right, and adding a human would be worse. If you want to know whether an image came out of a generative model, the tool chain is the correct thing to record and the human is irrelevant. If you want to reconstruct an edit history, the software is what matters.

The gap appears in a specific and consequential set of cases, all of which share one property: someone must be answerable.

• An insurance claim photograph. The carrier is not primarily asking which phone took it. They are asking who submitted it and whether that person can be held to it. We wrote about this at length in the piece on claim evidence provenance.
• Evidence offered in court. Authentication of a digital exhibit is about custody and sponsorship. A judge needs a witness who can be cross-examined, not a device attestation.
• A byline. Attribution to a publication or a device is not attribution to a journalist, and the entire professional structure of accountability in reporting rests on a named human.
• Testimony, statements and declarations. The point of a declaration is that a person is on the hook for it.
• Brand and executive impersonation. The question is whether the company authorised this, which is a question about a human with authority, not about the rendering software.

In our Identity Failure Map we call this pattern Evidence Without Provenance, and this is close to its purest example: the provenance of the artifact is excellent and the provenance of the human is entirely absent.

Why does a key on a device not stand in for a person?

The obvious objection is that a signing key is held by somebody, so surely it identifies them. It is worth working through why that does not hold, because the reasoning generalises well beyond this standard.

A camera's signing key lives in the camera. Cameras are shared across a desk, lent between colleagues, rented for a shoot, sold second hand, and occasionally stolen. The key attests to the hardware and continues to attest correctly after the hardware changes hands.

A cloud service's signing key belongs to the vendor and covers everything that vendor processes for anyone. It is a statement about the service, not about the account, and certainly not about the person at the keyboard.

An enterprise signing key covers the enterprise. A newsroom key says the newsroom signed it, which is genuinely useful, and says nothing about which of four hundred people did.

Even an individually issued creator certificate proves possession of a key at signing time, which is not the same as a live human choosing to publish. Keys sit in software on machines that get compromised. This is the same reasoning that makes a stolen session so dangerous in adversary in the middle attacks: possession of a credential is not evidence of a present, intending person.

The general principle, which is the transferable lesson of this post: a signature proves control of a key. It proves a human only if the act of signing required that human to be present and to act. Everything else is inference from custody, and custody is exactly what fails under attack.

How would a human assertion sit alongside a manifest?

The constructive answer is small, which is a point in its favour. C2PA's assertion model is extensible by design, and the right move is an additional assertion inside the existing structure rather than a competing format.

At capture or at publication, the accountable human signs a short statement on their own enrolled device, using a fresh signature bound to the asset. The payload:

{
  "type": "human_attestation",
  "asset_hash": "sha256:9f2c41ab...e07d",
  "manifest_hash": "sha256:1d77b0c4...9a31",
  "role": "captured",
  "statement": "I captured this asset and accept attribution",
  "signed_at": "2026-09-17T21:14:08Z",
  "presence": "companion_device_liveness",
  "subject_key": "z6MkrJ7...xVn2"
}

Two details in there are doing the important work.

The payload covers both the asset hash and the manifest hash, which means the attestation is bound to this exact file and this exact provenance record together. Re-edit the image and the attestation no longer applies, which is correct: the person vouched for what they saw, not for whatever it becomes later.

The presence field records that the signature required a live human on a companion device rather than a key sitting in software. In the Manav flow that is a pattern displayed on the publishing screen and claimed by the person's phone, with an on-device face match and a liveness challenge, so the key cannot be exercised by a process running unattended. What the verifier gets is not "a key signed this" but "a person was there and signed this".

Verification composes cleanly and needs no callback:

function verifyHumanVouched(asset, manifest, attestation, publishedKeys) {
  // 1. Standard C2PA validation, unchanged
  if (!c2pa.validate(manifest, asset)) return NO_PROVENANCE;

  // 2. The attestation is bound to this asset AND this manifest
  if (attestation.asset_hash    !== sha256(asset))    return MISMATCH;
  if (attestation.manifest_hash !== sha256(manifest)) return MISMATCH;

  // 3. The human's signature verifies against their published key
  if (!verifyEd25519(attestation, publishedKeys[attestation.subject_key]))
    return INVALID;

  // 4. A live person produced it, rather than an unattended key
  if (attestation.presence !== "companion_device_liveness") return WEAK;

  return { provenance: manifest, vouchedBy: attestation.subject_key };
}

Which artifact answers which question

That final row is the most important one on the page, and it leads directly to the next section.

What none of this establishes

The single most common error in provenance discourse, made by vendors, by journalists covering the topic, and increasingly by people drafting policy, is to slide from "we know where this file came from" to "we know this file is truthful". Those are unrelated claims and no amount of cryptography connects them.

A human attestation proves that a specific person captured or published a specific file at a specific time and accepted attribution. It says nothing whatsoever about whether the scene in front of the lens was real. A person can photograph a staged accident with a fully credentialed camera and sign the result with impeccable liveness. Every artifact validates. The claim is still fraudulent.

What the human layer changes is not truth but accountability. When the picture turns out to be staged, there is a named person bound to it who cannot say the file appeared from nowhere. That is worth a great deal in an insurance investigation, a newsroom correction, or a courtroom, and it is worth nothing at all in the moment of verification.

We would rather state this plainly than let a reader walk away with the stronger belief, because overselling provenance is precisely the failure this post is criticising.

Who gets hurt if this is built badly?

This section matters more than the mechanism, and it should be read before anyone reaches for an implementation.

Binding a human identity to published content is dangerous. Not inconvenient. Dangerous. The people who most need to publish material that powerful parties want suppressed are precisely the people for whom attribution is a physical risk: sources inside institutions, whistleblowers, journalists in states that imprison them, human rights documenters, survivors of abuse, and ordinary people posting evidence of something that happened to them.

Anonymous and pseudonymous publication is not an edge case to be handled later. It is a load-bearing part of how accountability journalism, and a good deal of civic life, actually functions. A provenance regime that makes unattributed content presumptively untrustworthy does not eliminate untrustworthy content. It eliminates the safety of the people with the most to lose, and it does so while leaving well-resourced bad actors, who can obtain identities, entirely unaffected.

So three constraints, and we would argue they are not negotiable:

• The human assertion must be optional. Its absence must never be treated as a negative signal, by a platform, a court, a regulator or a verifier interface. An unattributed file is an ordinary file.
• It must support pseudonymity. The useful property is usually continuity, meaning the same human who published the previous fourteen items, not a legal name. A stable key that proves "same person as before" without disclosing who serves most accountability purposes and protects the publisher. This is the same distinction we draw in verifying age without collecting an identity: an attribute proof is not an identity disclosure.
• It must never become a platform requirement. The moment a platform demands a human attestation to publish, it has built an identity mandate with extra steps, and every argument against identity mandates applies with full force.

The correct framing is that the human layer is something a publisher can choose to add when they want to be answerable, in the way a byline is a choice and an anonymous tip is also legitimate. Anyone building this who is not actively worried about the misuse case is not qualified to build it.

Honest limits

• It does not survive stripping any better than a manifest does. If the pipeline discards the credential it discards the attestation with it. The human layer inherits the entire distribution problem and solves none of it.
• It does not establish truth. Covered above, and worth repeating because it is the error everyone makes.
• It does not stop a compromised or coerced human. Someone forced to sign produces a valid attestation. Cryptography has nothing to offer here.
• It requires the enrolled human to exist beforehand. An attestation is only as good as the enrollment behind it, which is a real trust bottleneck and the subject of its own hard problems in enrollment and injection attacks.
• It is a proposal, not a shipped standard. Manav can sign an asset hash and produce an offline verifiable receipt today. There is no ratified C2PA assertion type for human attestation, and the right path is to contribute one to the coalition rather than ship a rival format. We say this as people who would benefit commercially from claiming otherwise.
• Verifier interfaces are the actual bottleneck. None of this reaches a reader unless platforms display it in a way an ordinary person can interpret, and provenance user experience is, so far, mostly unsolved.

What to do this week

1. Test your own pipeline for credential survival. Take one credentialed image, push it through your CMS, your CDN and your social distribution, and check what arrives. Most teams have never measured this and are surprised.
2. Write down which decisions in your organisation need a human rather than a device. Claim adjudication, evidence submission, bylines and legal declarations usually qualify. Feed labelling usually does not.
3. Stop treating a missing credential as a signal. If any of your workflows or policies infer risk from absence, correct that now, because base rates make it unsound.
4. Separate the two questions in your policy language. "Where did this file come from" and "who is answerable for it" should be distinct fields in any editorial or claims standard, because conflating them is what produces bad decisions under pressure.
5. Ask your provenance vendor the authorship question directly. Specifically: what does your product assert about the human, as opposed to the device or the account? The answers are clarifying and occasionally uncomfortable.
6. Design the anonymous path first. If you are adding any authorship signal, build the unattributed and pseudonymous flows before the attributed one, so the safe option is the default rather than the exception.
7. Read the specification rather than the summaries. The C2PA assertion model is more flexible than most coverage suggests, and a great deal of confused debate would resolve if more participants had read it.

If you want to see what a human bound signature over a hash looks like in practice, the signing demo shows the payload and the offline verification, and the developer documentation covers receipts and published key verification.

Frequently asked questions

Does C2PA prove who created or published an image? No. Content Credentials prove which device and software produced and edited the file, and which entity signed the manifest. Proving that a specific accountable human captured or published it requires a separate signature from that person's own enrolled device, which can be carried as an additional assertion inside the same manifest structure and verified independently.

Why do most images have no Content Credentials? Ordinary distribution pipelines strip metadata during resizing, transcoding and reformatting, and screenshots discard it entirely. Because credentials are therefore sparse rather than universal, the absence of one carries no information, which limits what a viewer can reasonably infer from a file that has none.

Can Content Credentials be faked or removed? Removed easily, faked much less so. Stripping is trivial and happens by default in many pipelines. Forging a valid manifest requires a signing key trusted by the verifier, so the practical attack is not forgery but omission, and the practical consequence is that provenance systems must be designed around sparse coverage.

Does a valid Content Credential mean a photo is real? No, and this is the most common misreading. A credential describes how a file was produced and altered. It says nothing about whether the scene depicted was genuine. A person can photograph a staged scene with a fully credentialed camera, and every check will pass.

What does the EU AI Act require for content provenance? The Act's transparency obligations, applying from August 2026, require providers and deployers of certain systems to make synthetic content detectable and to disclose AI generation in defined circumstances. It sets outcomes rather than mandating one technology, which is why C2PA and watermarking have both become common implementation choices.

Is C2PA the same as a watermark like SynthID? No. A watermark embeds a signal into the pixels or audio that can survive some transformations and indicates that a model produced the content. A Content Credential is a signed metadata record describing device, software and edits. They answer different questions and are complementary rather than competing.

Would requiring human attestation endanger anonymous publishing? It would if built badly, which is why it must remain optional, support pseudonymous continuity rather than legal names, and never become a condition of publication. The absence of an attestation must carry no negative inference, otherwise the design harms sources, whistleblowers and dissidents while leaving well-resourced bad actors unaffected.

Sources

1. Coalition for Content Provenance and Authenticity, specification and assertion model documentation. c2pa.org
2. Content Authenticity Initiative, membership and adoption materials. contentauthenticity.org
3. European Commission, AI Act transparency obligations and implementation timeline. digital-strategy.ec.europa.eu
4. Google DeepMind, SynthID watermarking documentation. deepmind.google
5. Adobe, Content Credentials product and standards materials. contentcredentials.org
6. W3C, Verifiable Credentials Data Model, for the assertion and holder model referenced in the composition design. w3.org

Provenance tells you where a file has been. It was never designed to tell you who will answer for it, and those are the two different questions the industry keeps merging into one.