AI Image and Video Provenance: When a C2PA Credential Is Evidence—and When It Is Not

Provenance answers a limited question

A visual file may circulate with many signals: a platform label, EXIF data, a visible watermark, an author’s statement, or a provenance credential. They do not all mean the same thing, nor are they equally resilient to later changes. For a newsroom, brand team, archive, or product that integrates generative tools, the first step is to ask the right question: what evidence exists about the declared history of this specific file?

C2PA is a technical specification for expressing and verifying content provenance information. In practical terms, a credential can bind statements about the creation, editing, or combination of assets to a file and protect those statements through cryptographic mechanisms. The result can help establish whether the presented evidence is intact and who signed it, provided that a validator can verify it and that trust in the signer is justified.

That scope matters, but it is limited. A valid credential does not automatically turn a scene into a verified fact. Nor does it prove that the named author holds every necessary right, that identifiable people consented to the use, that a declared identity is correct, or that no manipulation occurred outside the recorded chain. Those questions require separate sources and controls.

The absence of a credential also does not allow anyone to conclude that the file is false, manipulated, or AI-generated. It may be absent because the tool does not issue one, because it was removed during export, because a platform detached it from the file, or because another provenance format was used. Editorial decisions should reflect both what the evidence supports and what it leaves open.

Four kinds of evidence that should remain separate

Signed credentials are the kind of evidence that comes closest to a verifiable chain of statements. They may include an issuer, assertions about actions performed, references to ingredients—assets used to produce another asset—and a signature. Their usefulness depends on the file or associated manifest remaining available, validation succeeding, and the recipient knowing how to assess the signer.

Ordinary metadata, such as date, software, or camera fields, is useful for cataloguing and directing a review. On its own, however, it does not provide the same cryptographic integrity model and may be lost or modified when copied, converted, or published. It should be treated as documentary indication, not conclusive proof of origin.

Visible or software-detectable watermarks serve a different function. They can inform or help identify content, but they do not necessarily demonstrate the full editing sequence or replace manifest verification. A visible watermark can be cropped; an imperceptible signal may not survive certain transformations. Actual behavior should be tested in the chosen workflow.

Finally, a publisher’s statement may be needed to explain to the public how content was produced or altered. It is communication attributable to the party responsible for publication, not independent technical proof. It may be supported by records and credentials, but it should be written in proportion to that evidence.

How to read a credential without turning it into a seal of authenticity

The audit should begin with the received asset, not with a screenshot of an interface. Keep an unmodified copy and calculate or record an internal file identifier before opening it in tools that might save it again. Then run an up-to-date C2PA validator and retain the result along with the date, validator version, and any warnings.

Review who issued or signed the manifest and what level of trust the organisation can assign to that party. Cryptographic verification and organisational trust are separate layers: a manifest may be well formed and have a verifiable signature, while the team must still decide whether it knows and accepts the issuer for the intended use. If the issuer’s identity is displayed through a certificate or another identifier, do not automatically turn it into a claim about intellectual-property ownership or civil identity.

Examine the declared actions. An action may indicate creation, editing, export, or another workflow operation, but it describes what the manifest says occurred. Also review the ingredients and their relationship to the final asset. The presence of a tool in the chain does not necessarily prove that all visual content came from that tool: it may have been combined with photographs, graphics, clips, audio, or other materials.

The report should distinguish technical status from the use decision. Record, for example, whether the manifest was locatable, whether the content was bound correctly, whether the signature could be validated, which assertions were present, and which limitations remained. Avoid reducing that result to a binary label such as “authentic” or “inauthentic.”

Chain of custody: preserve more than the final file

Provenance becomes less useful when an organisation tries to reconstruct it at the end of the chain. The strongest time to document an asset is when it is created or received. In a generation or editing workflow, it is advisable to preserve the original delivered by the tool, its exported version, any credentials it contains, and operational documentation that connects the file to a commission or authorisation.

For every material transformation, create a new identifiable version rather than silently replacing the original. Record the tool and version used, the operator, the date, the purpose of the modification, and the input file. If a compatible tool updates provenance during editing, validate the result again. If a tool does not preserve it, the internal record becomes particularly important contextual evidence, although it does not replace the original’s signature.

Do not confuse storage with publication. An archival master may preserve an embedded credential, while a social network, content-management system, or video provider may serve a re-encoded copy without it. Policy should therefore define which copy is the archival object, which copy the public will see, and what evidence remains available to answer later questions.

The specification contemplates ways to transport manifests that are not necessarily reduced to a single embedded metadata block. Even so, an organisation must test its own combination of formats, tools, and destinations. It is not enough to assume that a credential will survive because it was visible in the source application.

Where evidence can break, degrade, or become detached

A screenshot usually creates a new file and often excludes the original asset’s credential. It can be useful as an illustration of what appeared in an interface, but it should not be presented as evidence of the captured file’s provenance. Where possible, request the original or an internal link to the preserved object rather than relying on the screen image.

Video re-encoding, format conversion, image optimisation, cropping, metadata stripping, and certain edits can alter or remove the information needed to validate provenance. Some tools may issue a new credential that reflects the transformation; others may not. The effect depends on the implementation, input and output formats, and enabled options. Claims about compatibility should therefore rely on documented tests of the specific workflow.

It is also necessary to distinguish between a removed credential and one that still exists but is detached from the object the public downloads. Manifests can be embedded, external, or distributed through other mechanisms. If an interface displays a provenance indicator, check what happens when the file is downloaded, shared, or opened with another validator. An interface does not replace an audit of the distributed object.

When inconsistencies are found—for example, a public statement attributes an image to a tool, but the available file lacks the promised evidence—it is not appropriate to infer bad faith automatically. The proper response is to pause strong conclusions, retain the copies examined, and request the original, validation report, and an explanation of the workflow.

Decision protocol before publication or reuse

Classify evidence in four operational states. “Sufficient” does not mean total certainty: it means that, for a specific documented decision, an original is available, validation produced a satisfactory result, the issuer has been assessed, and supplementary records of rights, consent, and context exist where relevant. Even in this state, publishing a factual claim requires independent editorial verification.

“Incomplete” means there is some useful signal—for example, a valid credential on an original but not on the publication copy, or production records without a verifiable manifest—while elements needed for broad attribution are missing. It may be publishable if editorial risk is low and communication is limited to what is confirmed, but an internal note should record the gaps.

“Absent” means that no credential or verifiable provenance record is available. It does not mean that the content is deceptive or generated. In this state, the decision will depend on context, trust in the supplier, acquisition policies, and other checks. “Contradictory” means that elements do not fit together or that a material discontinuity cannot be explained. This state requires human review before distributing an attribution about origin or AI.

Classification should be applied by version. A satisfactory validation of a master does not automatically transfer to a compressed web image, a video excerpt, an audiovisual translation, or a later composition. Link every decision to a file identifier, not merely to a project’s commercial name.

Public labels: describe the evidence, do not promise more

The safest label describes the known process or the limit of the evidence. If a validated credential exists for the distributed version and its statements are relevant, one possible wording is: “This file includes verifiable provenance information about the actions declared in its creation and editing.” If the organisation wishes to mention AI, it should do so only when technical evidence and production records sufficiently identify that use.

When a credential is present in the original but its preservation in the public copy has not been confirmed, this is preferable: “The master file retained by the organisation includes verifiable provenance information; availability of that information may vary by platform.” This informs without claiming that viewers can inspect the same evidence across every destination.

Avoid phrases such as “authentic image,” “real content,” “unmanipulated,” “certified AI use,” “rights guaranteed,” or “no deepfakes” when they are based solely on a credential. Also avoid saying “not AI-generated” merely because a credential does not appear. These formulations confuse provenance evidence with fact-checking, forensic analysis, rights, or the absence of a technique.

In the European Union, transparency obligations for certain AI-generated or manipulated content require an analysis separate from the technical credential. European Commission guidance indicates that a machine-readable marking alone is not sufficient when people must be informed. The specific applicability depends on the circumstances, the organisation’s role, exceptions, and the regulatory timetable; it should be reviewed with legal advice for each publication.

Minimum internal record and supplier review

A consistent internal record makes it possible to explain decisions months later, when a platform has already replaced the published copy or a supplier has changed its product. Include an identifier for the file and every version, the location of the unaltered original, the source of receipt or production, the declared tool and version, the operator or owner, relevant dates, and the purpose of use. Add the complete validation result, the validator used, and detected warnings.

Keep evidence of licences, assignments, contractual permissions, consent from depicted people, territorial restrictions, and any factual-accuracy review separate. If a document does not exist or the organisation has not verified a point, the record should say so expressly. Combining these categories under a single “approved” status makes it impossible to know what was actually checked.

Before procuring or integrating a visual tool, request reproducible demonstrations using test files. Ask which formats support credentials, how they are retained during generation, editing, downloading, and re-uploading, which statements are issued, and how assets behave after passing through real publication destinations. Test both positive cases and files without credentials, with damaged credentials, or with later transformations.

This diligence is especially necessary when provenance capabilities are attributed to model or product names such as GPT-Image-2.5 Sunburst, Sora 2 Pro, Nano Banana 2, or Veo 3.1. It should not be claimed that any of them generate, preserve, update, or remove C2PA credentials without verifiable technical documentation and tests on the specific version. Commercial names do not replace verification of product, configuration, and date.

Final checklist

Before publishing, archiving, acquiring, or reusing an asset, check that the exact version has been identified; that the available original is preserved; that validation was performed with a recorded tool and version; that the actions, ingredients, and issuer have been read; and that warnings have been recorded. If a platform is part of the workflow, also examine the copy it delivers to the end user.

Then review, outside C2PA, what the credential does not resolve: licence and scope of use, consent, data protection, people’s identities, factual accuracy, potentially misleading context, and applicable disclosure requirements. A useful policy assigns different owners to these checks, while coordinating their results in the same case file.

Finally, communicate only what can be supported. Provenance works best as a layer of traceable evidence rather than a definitive label. Adopting this discipline makes it possible to use verifiable credentials without turning their presence into a promise of complete authenticity or their absence into an unfounded accusation.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.