C2PA Content Credentials for AI Provenance

A Content Credential is not a single tag. C2PA's explainer defines a manifest as "the set of information about the provenance of an asset consisting of one or more assertions that are digitally signed."

In practice, a handful of assertion types do most of the work.

• c2pa.actions: a log of what was done to the file (created, opened, cropped, color-corrected, composited), where each entry can carry a digitalSourceType field stating whether that step came from a camera, a human edit, or an AI model.
• c2pa.ingredient: a pointer to any source asset folded into this one, such as the photo a generative-fill edit started from.
• c2pa.hash.data: the cryptographic hash that hard-binds the manifest to the file's actual bytes.
• c2pa.thumbnail: a small preview image.
• Standard metadata assertions that map onto existing EXIF, IPTC, and XMP fields rather than reinventing camera or caption metadata from scratch.

All of that is organized by a "claim," the structure that gathers together everything the signer is vouching for. The claim also records the claim generator (the specific product and version that did the signing) plus a unique instance ID for that version of the file.

When assets get combined, each ingredient carries its own provenance forward. C2PA describes the result as "a tree of provenance, much like a family tree, that can stretch all the way back to each ingredient's creation."

The c2pa.hash.data assertion records a cryptographic hash (SHA-256, SHA-384, or SHA-512) computed over specific byte ranges of the real file, deliberately excluding the manifest itself. That hash is then rolled up into the rest of the signed data.

C2PA's explainer describes the technique directly: "standard cryptographic hashes, such as SHA2-256, with a Merkle tree-like approach of having one hash included in a secondary hash (etc.) and then finally digitally signed."

The practical effect is simple. Change a single pixel after signing and the hash a verifier recomputes from the file no longer matches the one locked into the manifest, so tampering surfaces automatically, with no cooperation from the editor required.

The weakness is just as simple. Strip the manifest out of the file and there is nothing left to hash-check.

C2PA's answer is to pair hard binding with a "soft binding" (watermarking or fingerprinting) to create what the spec calls durable Content Credentials, so a manifest can still be found after it's been physically removed from the file.

OpenAI cites the same tradeoff for its own stack. Its help center notes that metadata "can sometimes be removed by platforms, editing tools, or file conversions," while a watermark "is part of the content itself and may persist through some edits or transformations."

Once the assertions and claim are assembled, the bundle is signed by whoever, or whatever software, performed the operation. C2PA's explainer says the manifest is "signed with the private key of the software or hardware that performed the operations, thus ensuring its authenticity and integrity. The corresponding public key is made available for verification."

It compares the design to "SSL/TLS and PDF signatures" using X.509 certificates, the same technology behind the padlock in your browser. A verifier checks the signature against the signer's public key, then checks that certificate against a trust anchor.

For C2PA, that anchor is the C2PA Trust List, which the explainer says works "similar to how a web browser or PDF viewer includes their own set of Trust Lists (e.g., CA/Browser Forum, EUTL, etc.)." Getting onto it runs through C2PA's Conformance Program, which independently tests three separate things:

• Generator products, the tools that create and sign manifests.
• Validator products, the tools that check them.
• Certificate authorities, who issue the signing certificates in the first place.

None of this is a truth guarantee, and C2PA says so plainly: "the trust in the contents of a Content Credential is based on the trust relationship between the creator of the Content Credential and the consumer." Verification proves the signer is who the certificate says and that nothing was altered after signing. It does not prove the signer told the truth.

OpenAI states on its provenance page that it has become "a C2PA Conforming Generator Product." That is OpenAI's own announcement, not something this site could check against a public conformance registry, so treat it as self-reported rather than third-party-verified.

Coverage varies by content type, and OpenAI's own materials are specific about it.

• Images from ChatGPT, Codex, or the OpenAI API: a C2PA Content Credential plus an invisible SynthID watermark, a joint capability built with Google DeepMind and expanded through 2026.
• Audio, as of a July 31, 2026 update: a SynthID watermark only, with no C2PA metadata layer yet.
• A visible OpenAI watermark, if you ask a model for one: a separate feature that is explicitly not machine-readable, and not the same thing as either embedded signal.

OpenAI's public tool at openai.com/verify checks an uploaded file for a SynthID watermark or a trusted C2PA manifest associated with OpenAI. A positive match means a supported signal was found.

A negative result proves far less. The file could predate the rollout, come from an unsupported product or export path, or have had its signals stripped or degraded on the way to you.

What OpenAI has not published is the literal field-by-field manifest JSON for a specific image. Combining its own description with the C2PA assertion vocabulary and IPTC's digitalSourceType codes, a plausible (explicitly inferred, not confirmed) sketch of a pure text-to-image generation would include:

• A c2pa.actions assertion with a "created" action whose digitalSourceType points to IPTC's trainedAlgorithmicMedia code ("digital media created algorithmically using an Artificial Intelligence model trained on captured content").
• A c2pa.hash.data assertion hard-binding the manifest to the image bytes.
• A claim generator string identifying the OpenAI product and version.
• A claim signature chaining to an OpenAI-controlled certificate.

For an edit rather than a generation, say you upload a photo and ask for an object to be removed, you would also expect a c2pa.ingredient assertion referencing that uploaded source file. The relevant action's digitalSourceType would more plausibly use IPTC's compositeWithTrainedAlgorithmicMedia code instead. Treat that whole sketch as informed inference from verified building blocks, not a captured real-world manifest.

Two independent checks have found gaps between the public claims and the actual files. Neither has a documented response from OpenAI, and neither has been replicated by this site.

In November 2025, a named author cross-posted an investigation to LessWrong and the EA Forum. Sora 2 videos carrying the visible watermark showed no detectable C2PA metadata through either OpenAI's own Verify tool or the open-source c2pa-rs CLI.

The second is a June 28, 2026 thread on OpenAI's own developer forum, asking whether C2PA metadata chunks are being stripped from images uploaded to ChatGPT on purpose. The poster's OpenAI-generated PNG verified cleanly at openai.com/verify with Content Credentials and SynthID both present, then came back from a round trip through a ChatGPT conversation stripped down to bare PNG chunks.

Both sit at community-discussion confidence, and both are worth knowing because they set expectations. A provenance signal is only as good as every pipeline the file passes through afterward.