C2PA Content Credentials

Description

C2PA Content Credentials attach a signed provenance record, called a manifest, to a media file, so that whoever receives the file can see who signed it and what the signer declares (which tool produced it, whether a generative AI model created or altered it and what edits followed), and can check that the record, and the parts of the file its hash covers, have not changed since signing. Under the Coalition for Content Provenance and Authenticity (C2PA) technical specification, the tool that creates or edits the file writes statements called assertions, such as a 'created' action whose source type is trainedAlgorithmicMedia (the code for AI-generated content) and links to the earlier files it was made from, adds a cryptographic hash of the file's content, and signs the bundle with an X.509 certificate, the kind of credential used to secure websites. The manifest is usually embedded in the file, and each later edit in a supporting tool adds a new manifest that refers to the previous one, so the history travels with the file. A validator recomputes the hash and checks the signature, then reports the manifest as well-formed, valid or, if the signing certificate chains to a trust list such as the C2PA Trust List, trusted, and reports a failure when the file no longer matches its hash. If the manifest is removed, nothing in the file leads back to it unless a watermark or fingerprint (a 'soft binding') was also registered so that the manifest can be looked up in a repository, and a file without credentials says nothing about its origin; unlike trigger-set model watermarking or model signing, which mark or sign a model, it records the history of an individual output.

Example Use Cases

Transparency

An image-generation service offered in the EU attaches a signed manifest to every image it returns, declaring an AI 'created' action with the service as signer, as its means of meeting the AI Act's Article 50(2) duty to mark synthetic output in a machine-readable format. Its compliance team validates a weekly sample of outputs to decide whether marking is working, and registers a watermark soft binding so that a stripped image can be matched back to its record.

A news agency's verification desk runs every image sent in by the public through a C2PA validator before publication. A trusted manifest recording capture on a named camera, with no AI-generated ingredients, lets editors publish it with a provenance label. A manifest naming a generative tool, or a hash that no longer matches, sends it to forensic review, and an image with no credentials is treated as of unknown origin, not as authentic.

An insurer's claims app lets assessors apply an AI tool that enhances and annotates photographs of vehicle damage, and records each AI edit as an action in the photograph's manifest. When a claim is disputed, a reviewing assessor or the claimant's representative can see which changes the AI tool made and check them against the retained original, which the edited photograph's manifest cites as an ingredient.

A social-media platform reads Content Credentials on upload, labels images whose trusted manifest declares a generative AI source, and shows users who signed the record. Its trust-and-safety team tracks what share of uploads carry trusted, untrusted or no credentials, to decide how far its synthetic-media policy can rely on the labels and where it still needs other detection methods.

Limitations

The record is easy to lose. Anyone can remove the manifest, an attack the C2PA's own threat model expects, and the file is then an ordinary file with no link to its history unless a watermark or fingerprint soft binding was registered with a manifest repository. Because credentials are optional and removable, a file without them says nothing about its origin: the absence of a manifest cannot show that content is human-made or unaltered.
A valid manifest shows who signed the record and that what its hash covers is unchanged, not that its statements are true. A signer can omit an AI step, a stolen key yields manifests that validate, and a camera photographing a screen signs a genuine capture of a staged scene. Validators need not check revocation, metadata such as location may sit outside the hash, and a 2026 preprint found validators disagreeing on the same file, so a result depends on the signer, validator and trust list.
The history is complete only while every tool in the workflow supports C2PA. An edit made in an unsupported tool is not recorded, and if the file later passes through a supporting tool, the new signer implicitly vouches for that unrecorded change, so the chain can show fewer steps than took place. The C2PA itself says the approach depends on widespread adoption by tools and platforms.
Manifests can disclose more than the creator intends, such as capture time and place, device details, the edit history and, through the separate Creator Assertions Working Group identity extension, who made the content. The C2PA's threat model lists identifying creators and tracking viewers as risks. Assertions can be redacted when a file is reused as an ingredient, but people working in risky settings, such as human-rights documentation, must decide what to include before signing.
Support for AI-generated text is immature. Embedding a manifest in plain text, as invisible Unicode characters, entered the specification in version 2.3 and is still marked as under review; the reference SDK supports it only behind an unstable option, and any edit to the text breaks the hash. For language-model output the method is much less dependable than for images, video and audio, where embedding is established.

Resources

Research Papers

C2PA Technical Specification, version 1.0

Software Packages

c2pa-rs: Rust SDK for the C2PA specification

Oct 11, 2026

Rust SDK for the core C2PA (Coalition for Content Provenance and Authenticity) specification

Tutorials

Using C2PA Tool

Command line tool for displaying and adding C2PA manifests - contentauth/c2patool

Documentations

Content Credentials: C2PA Technical Specification, version 2.4

Related Techniques

Name	Description	Assurance Goals
Model Signing	Model signing lets the publisher of a machine-learning model attach a cryptographic signature to the model's files, so that anyone who later loads them can check who released them and that no file has changed since. Under the Open Source Security Foundation's Model Signing (OMS) specification and its reference tool, model-signing, the publisher computes a hash (a short fingerprint that changes if a single byte of the file changes) of every file in the model directory, such as weights, configuration, tokeniser and any dataset files kept with them, lists the hashes in a sorted manifest and signs the manifest, producing a detached signature file kept beside the model. The signature can be made with the publisher's own key, with a certificate from an organisation's certificate authority, or through Sigstore, which issues a short-lived certificate tied to a verified online identity, such as a person's account or a build pipeline's, and records each signing event in a transparency log, an append-only record that can be inspected afterwards. Before loading, the consumer verifies the signature against the signer it expects, recomputes every hash and rejects the model if any listed file differs or is missing or, unless that check is switched off, an unlisted file has appeared, so the evidence is a pass or fail tied to a named signer and an exact set of files. Unlike the unsigned file hashes kept by data-versioning tools, it shows who stands behind the files, and unlike a watermark, which is trained into the weights so that it survives in an altered copy, it is broken by any change; it says nothing about how the model behaves or what it was trained on.	Security
API Usage Pattern Monitoring	API usage pattern monitoring examines how each account uses a deployed model's API, to catch misuse that no single request reveals. The monitor keeps a running record per account and compares it with a baseline of normal use, raising an alert when the account departs from it. Published detectors for model theft show two ways to do this: one tests whether the distances between an account's successive queries follow the bell-shaped pattern that ordinary use produces, and another estimates how much of the model's behaviour the account's queries and responses would let someone rebuild. Providers also score how often an account triggers content filters or repeats jailbreak attempts, and send high scores for review. The output is a log of alerts and the actions taken, which gives a dated record of how the API was used compared with the uses it was approved for.	Security Safety Transparency
Zero-Knowledge Proof of Model Inference	A zero-knowledge proof of model inference lets the owner of a model show an outside party that one specific model, fixed in advance, turns a particular input into a particular output, without revealing the model's weights. The owner publishes a commitment to the weights, a short cryptographic fingerprint such as a hash that binds them without disclosing them, together with a verification key that fixes the model's architecture. The model's arithmetic is converted to whole numbers (quantised) and written as a system of equations called a circuit, and for each input a proving system produces a proof, of a few kilobytes to a few hundred kilobytes, that this circuit, run with weights matching the commitment, turns that input into that output; the input can be public or committed in the same way. Anyone holding the verification key can check the proof in milliseconds to seconds: it shows that the committed model gives that output for that input, while keeping the weights hidden, and says nothing about whether that model is accurate, fair or safe. Unlike homomorphic encryption, which lets a server compute on data it cannot read but gives the caller no evidence of which computation was run, and unlike model signing, which lets someone who holds a model's files check who released them, it lets someone who never sees the weights check individual outputs against them.	Transparency