AI Content Provenance and C2PA Content Credentials

Labelling laws now expect generated images, audio and video to carry machine-readable proof of where they came from, and most organisations have no pipeline that can create, protect or check that proof. The EU AI Act's Article 50(2) requires providers of generative AI systems to mark outputs in a machine-readable, detectable way, and China's labelling measures, in force since 1 September 2025, require implicit labels in file metadata. The C2PA specification, whose manifests are branded Content Credentials, is the most widely implemented open format for that metadata. This guide explains how a C2PA manifest is built and signed, how to manage the signing keys and certificates, how to keep credentials intact through content pipelines, how to validate what you receive, and where provenance stops helping. It is for engineering teams shipping generative features, media and communications teams, trust and safety teams and security architects. Model provenance and watermarking in general are covered in the AI Model Provenance and Watermarking Guide.

Key takeaways

A Content Credential is a signed claim, not a label. The C2PA manifest binds assertions about an asset to its bytes with a hash and an X.509 signature, so any change to the signed content breaks validation.
The signing key is a high-value machine credential. Whoever holds it can make content appear to come from your organisation; keep it in an HSM or cloud KMS and give the signing service its own scoped identity.
Metadata stripping is the main failure. The 2025 NSA and Five Eyes partner guidance warns that processes which strip metadata remove credentials; pair manifests with watermarks and fingerprints ("Durable Content Credentials").
Trust depends on the certificate, not the manifest. Self-signed certificates are now reported as untrusted, and the C2PA Trust List is restricted to certificates with the claim signing extended key usage.
Provenance proves origin, not truth. Credentials say who signed and what actions were declared; absence of a credential does not make media fake, and presence does not make it accurate.

Why provenance is now a compliance requirement

Requirement	Who it applies to	What it asks for	Status (checked 27 October 2026)
EU AI Act Article 50(2)	Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text	Outputs marked in a machine-readable format and detectable as artificially generated or manipulated; solutions effective, interoperable, robust and reliable as far as technically feasible	Applies from 2 August 2026; the Commission's AI Act Service Desk gives systems already on the market before that date until 2 December 2026
EU AI Act Article 50(4)	Deployers publishing deep fakes or AI-generated text on matters of public interest	Visible disclosure to people	Applies from 2 August 2026
EU Code of Practice on marking and labelling AI-generated content	Providers (marking and detection) and deployers (labelling)	Voluntary means of showing compliance with Article 50(2) and (4)	Drafted through 2026 under the AI Office; check the Commission page for the final text
China: Measures for Labeling AI-Generated Synthetic Content	Generation service providers, dissemination platforms, app stores and users	Explicit visible labels plus implicit labels in file metadata recording content attributes, the provider's name or code and a content ID; platforms must check metadata; malicious removal or tampering of labels is prohibited	Issued March 2025 by the CAC and three other authorities; in force since 1 September 2025

Neither law names C2PA. The EU text asks for interoperable, robust marking, and China's measures ask for metadata plus optional watermarks. C2PA covers the metadata layer well and supports soft bindings (watermarks and fingerprints) for durability, which is why it features heavily in implementation planning. The detail of Article 50 is in the EU AI Act Article 50 Transparency Obligations Guide.

How a C2PA manifest works

The C2PA Technical Specification (version 2.2, May 2025, with later versions published) defines these building blocks:

Assertions: statements about the asset, identified by labels. The actions assertion (c2pa.actions) records what was done, such as creation or editing. C2PA's AI and machine learning guidance says a generative model's output should carry the digital source type trainedAlgorithmicMedia.
Claim: a digitally signed, tamper-evident structure that references the assertions and the content binding.
Claim signature: made with the signer's private key; only X.509 certificates may be used, with RFC 3161 time-stamps.
Manifest and manifest store: assertions, claim and signature together form a manifest; an asset's history of manifests is the manifest store, embedded in the file (using JUMBF boxes) or held externally and referenced. The last manifest is the active manifest.
Hard binding: cryptographic hashes over the asset bytes (for example c2pa.hash.data), so edits to the content invalidate the credential.
Soft binding: a watermark or fingerprint used to find the manifest again when metadata is lost. The specification states a soft binding must not be used as a hard binding.
Ingredients: earlier assets used to make the new one, with their manifests copied into the new store, which is how a composite or edited image keeps its history. The AI guidance suggests recording the prompt as an input ingredient and linking to the model's own credential.
Redaction: assertions can be removed when an asset becomes an ingredient (for privacy), but actions assertions and hard bindings must not be redacted.

Supported formats include JPEG, PNG, BMFF-based video such as MP4, PDF and ZIP-based formats. Text is the weak spot: a paragraph of generated text has no container to carry a manifest once it is copied, which is why text marking usually relies on other techniques.

Validation states

State	Meaning	What to do with it
No manifest	No credential found, or it was stripped	Try soft binding lookup; treat as unknown provenance, not as fake
Well-formed	The manifest parses correctly	Not yet evidence of anything
Valid	Signature, time-stamp, assertions and hard binding check out	Content is unchanged since signing
Trusted	Valid and signed by a certificate chaining to a trust anchor you accept	You can attribute the claims to the signer
Invalid	Hash mismatch, bad signature or revoked certificate	Content altered after signing or signer compromised; investigate

Signing keys and certificates: the identity problem

Content Credentials move trust from the file to the signer, so the signing key is the asset to protect. A stolen key lets an attacker publish convincing "official" media; a leaked key in a generative service lets anyone mark content as yours.

Certificate source: use certificates from a certification authority whose roots appear in the trust lists your audience uses; the C2PA Trust List in specification 2.2 is restricted to certificates carrying the c2pa-kp-claimSigning EKU. Self-signed certificates are flagged as untrusted by current validators.
Key custody: generate and keep private keys in an HSM or cloud KMS; never place them in container images, notebooks or CI variables. See the Secrets Management Guide.
Signing service identity: expose signing through an internal service whose callers authenticate with workload identity, and log every signing request with the calling identity and asset hash.
Separate keys by purpose: distinct certificates for AI-generated output, for edited corporate media and for camera capture, so a compromise of one does not taint all provenance.
Rotation and revocation: plan certificate renewal and test revocation; validators check revocation, so a compromised key can be cut off.
Time-stamping: use an RFC 3161 time-stamp authority so signatures remain verifiable after the certificate expires.

The certificate and key lifecycle is the same discipline as code signing. See the Code Signing Security Guide and the Certificate Revocation Guide.

Implementing Content Credentials

Map your content flows. List where synthetic media is generated (product features, marketing tools, internal assistants) and where media is published or ingested (website, social channels, customer uploads).
Decide where to sign. The NSA-led guidance suggests signing at capture, during editing or just before publication. For generative features, sign at generation inside the service so every output is covered.
Define assertions. At minimum: actions with the AI digital source type, the generator (software agent) and time. Decide deliberately what not to include: prompts and user identifiers may be personal data, and the specification asks implementers to let creators and publishers control what is included.
Build the signing service with KMS-held keys, scoped caller identities and logging.
Add durability. Register a fingerprint or embed a watermark linked to the manifest so it can be recovered when metadata is stripped, and keep read-only originals in a searchable store.
Fix the strippers. Test every image resizer, CDN optimisation, transcoder and CMS upload path; many remove metadata by default. Change settings or re-sign after processing.
Display and verify. Show credential information on your own site (C2PA provides SDKs) and validate incoming media in moderation and newsroom workflows.
Pilot, then expand. Start with one generative feature and one publishing channel, measure survival rates, then roll out. Rolling back means disabling signing in the service; existing signed assets remain valid.

Decision guidance

Situation	Approach	Trade-off
You provide a generative AI feature in the EU	Sign every output with C2PA and add a watermark or fingerprint	Engineering effort and per-asset cost; strongest Article 50(2) position
You use a third-party generator	Require the supplier to mark outputs; preserve its credentials; add your own manifest if you edit	Depends on supplier support; check contracts
Media organisation or public body	Sign at capture and publication; verify on ingest	Camera and workflow changes; protects authentic content against impersonation
Platform hosting user content	Read manifests and soft bindings on upload; show labels; avoid stripping	Required for dissemination platforms under China's measures; detection of unmarked content remains hard
Small organisation with occasional AI images	Use tools that already embed credentials and keep publishing paths from stripping them	Little control over keys; limited assurance

Validating credentials you receive

Consuming provenance is as important as producing it, especially for newsrooms, investigators, insurers, identity verification teams and platforms. A sound validation step does more than look for a badge.

Parse and validate the active manifest: check the claim signature, the time-stamp, certificate revocation and every hard binding against the file you hold. A valid result means the bytes are unchanged since signing.
Decide which signers you trust: maintain your own trust configuration (the C2PA Trust List plus any publishers you have verified directly). The NSA-led guidance notes that disconnected networks may need to obtain publishers' verification certificates in advance.
Walk the ingredients: an edited asset may have a trusted final signer but untrusted or missing history. Record which ingredients were AI-generated and which manifests were inaccessible (the specification provides a manifest.inaccessible code for remote manifests that cannot be retrieved).
Recover stripped credentials: where no manifest is present, query watermark detectors or fingerprint services for a matching manifest, then validate it as above.
Record the result: store the validation outcome, signer, time and tool version with the case or moderation record, so decisions are evidenced.

Where provenance stops helping

Attackers opt out: provenance helps honest producers prove origin. A fraudster creating a fake executive video will not sign it, so detection, verification procedures and user training remain necessary.
Analogue hole: photographing a screen or re-recording audio produces a new, unsigned file; only watermarks that survive capture can link it back.
Text: generated text has no durable container, so Article 50 text obligations are usually met through visible disclosure and other marking techniques rather than C2PA.
Live media: real-time calls and streams are not covered by file-based manifests in most deployments.
Interpretation: credentials answer who, when, where and how, but, as the 2025 guidance puts it, not why, and not whether the content is true.

Detection and measurement

Coverage: percentage of generated assets leaving your systems with a valid, trusted manifest.
Survival rate: percentage of assets whose credential still validates after each publishing channel, measured by sampling published copies.
Recovery rate: percentage of stripped copies whose provenance can be recovered through watermark or fingerprint lookup.
Signing hygiene: keys held in HSM or KMS (target 100 percent), days to certificate expiry, number of signing calls from unexpected identities (target zero).
Ingest validation: share of inbound media checked for credentials in moderation or editorial workflows, and number of invalid manifests investigated.

Alert on signing requests outside the expected service identities, bursts of signing volume, and validation failures on your own published assets, which can indicate tampering or a broken pipeline.

Common failure patterns

Signing keys in application config: the key that vouches for your brand sits in an environment variable of the generation service.
A CDN or CMS that strips metadata: credentials exist at generation and vanish before the public sees the file.
Self-signed or test certificates in production: manifests validate structurally but show as untrusted everywhere.
Treating missing credentials as proof of fakery: most authentic media still carries none, and the guidance is explicit that absence does not make media untrustworthy.
Over-sharing in assertions: prompts, user IDs or location data embedded in public files create privacy exposure.
Expecting provenance to stop fraud: the Arup deepfake fraud used deepfake participants in a video meeting to trigger HK$200 million in transfers. Attackers do not sign their fakes, so the control that matters there is out-of-band verification of payment requests, not credentials.

Framework mapping

Area	Reference	Relevance
Integrity of published content	NIST SP 800-53 SI-7 Software, Firmware, and Information Integrity	Hash binding and signature validation
Key and certificate management	NIST SP 800-53 SC-12, SC-17; ISO/IEC 27001:2022 A.8.24	Signing key custody and PKI certificates
Data protection in metadata	ISO/IEC 27001:2022 A.5.34; GDPR data minimisation	Choosing which assertions to publish
Deepfake threats	MITRE ATLAS AML.T0088 Generate Deepfakes; AML.M0034 Deepfake Detection	Provenance complements detection
Data security outcomes	NIST CSF 2.0 PR.DS-01, PR.DS-02	Integrity of data at rest and in transit

Practitioner checklist

Inventory every place your organisation generates or publishes synthetic media.
Sign generated outputs with C2PA manifests carrying the AI digital source type.
Obtain signing certificates from a CA trusted by common validators; remove self-signed certificates.
Hold signing keys in an HSM or KMS behind a signing service with scoped, logged caller identities.
Add watermark or fingerprint soft bindings and keep read-only originals.
Test every publishing path for metadata stripping and fix or re-sign.
Decide which assertions are published, with a privacy review.
Validate inbound media credentials in moderation and editorial workflows.
Track coverage, survival and recovery rates, and certificate expiry.

AI Content Provenance and C2PA Guide: Sign, preserve and verify Content Credentials