Provenance verification: four kinds, and how each one is checked
6 min readProvenance verification is checking a claim about where something came from, or what happened to it, against evidence you do not have to take on trust. In software that evidence is nearly always a signature from an identity you recognise, plus a hash that ties the claim to the exact bytes it describes.
The term covers four different problems with four different standards. Searching for it returns all of them mixed together, so this page sorts them. (Outside software, provenance verification usually means art, antiques or metals checked against documents, assays and registries. This page covers the digital kinds.)
Four kinds of digital provenance
| Kind | The question it answers | Main standards and tools | What a verifier checks |
|---|---|---|---|
| Content | Who made this image, video or document, and how was it edited? | C2PA Content Credentials | The manifest’s signature, and a hash binding it to the file’s bytes |
| Build | Which source and which builder produced this software artifact? | SLSA, in-toto, Sigstore | The attestation’s signature, the builder’s identity, the artifact digest |
| Data | Where did this dataset come from, and what transformed it? | W3C PROV, OpenLineage | Usually nothing cryptographic: the lineage graph is rarely signed |
| Execution | What did a running system, such as an AI agent, do, in what order, under what authority? | Provetrail (draft spec); signed workflow histories in Dapr 1.18 | A signed Merkle root over the events and, at the governance level, the admission behind each action |
All four can apply to the same system. An AI agent can be built with SLSA provenance, read a dataset with OpenLineage lineage, produce an image with a C2PA credential, and leave an execution record of everything it did in between. Each record answers a question the other three cannot.
Content provenance: who made this file
C2PA attaches a signed manifest to an image, video, audio file or document, recording who created it, with what tool, and which edits followed, including whether a generative model was involved. You can inspect one at verify.contentauthenticity.org or with the open-source c2patool.
A valid manifest proves the signer made those claims and that the file has not changed since. Whether to believe the signer is a separate check: their certificate has to chain to a trust list you accept, such as the one C2PA publishes. A missing manifest proves nothing, because many platforms strip metadata on upload.
Build provenance: where this software came from
A build attestation records the source repository, the commit, the builder and the parameters that produced an artifact, signed by the build platform. npm and GitHub Actions produce them when a project’s release workflow asks for them, and container registries store them beside the image. The commands to check each are in how to verify software provenance.
Build provenance ends when the artifact is produced. It records nothing about what the software does once it runs.
Data provenance: where this dataset came from
Data lineage records which sources fed a dataset and which jobs transformed it. W3C PROV is the general model, a W3C Recommendation since 2013. OpenLineage is an open specification for lineage events, with integrations for Airflow, Spark and dbt among others.
Neither defines a signature. Lineage is a record a pipeline writes about itself. That makes it good for debugging and impact analysis, and weak as evidence to an outsider: the party that ran the pipeline is the only witness.
Execution provenance: what an agent did
Execution provenance records the actions a running system took: each tool call, each side effect, in order, with the authorization decision that admitted it. It is most needed for AI agents, because an agent decides its own actions at runtime and none of the other three records describes them.
A Provetrail record commits the events to a Merkle tree and signs the root with an Ed25519 key. Provetrail’s conformance suite has four levels: L1 to L3 cover integrity, and L4 covers governance. At L4, a record also carries an admission or refusal for every side-effecting action, the output of the pre-execution checks that decided whether the action could run. Anyone holding the record and a public key they trust for the signer can check it without access to the system that produced it. The home page runs the integrity check, signature and Merkle root, in your browser.
The record comes from the runtime that executes the agent’s actions, because only the code that dispatches a tool call can witness it. Flynn is the open-source reference runtime, and flynn spine verify checks all four levels. The longer definition is in what is verifiable execution provenance, and the mechanics are in how to verify an AI agent’s execution record.
Provetrail, a draft at 0.1.0, is not the only effort here: Dapr 1.18 can sign workflow histories step by step under each sidecar’s SPIFFE identity, as an opt-in. SCITT, the IETF architecture for transparency services, published as RFC 9943, is a separate effort. It records nothing about execution itself: it registers signed statements and issues receipts for them. Provetrail’s signed checkpoint follows SCITT’s COSE signed-statement form, and the spec lets a record carry a transparency receipt; registering records with a SCITT service is not yet specified.
Which one you need
- You publish images or media and want viewers to see where they came from: content provenance.
- You install or ship software and want to know it was built from the source you expect: build provenance.
- You train or report on data and need to trace a number back to its source: data provenance.
- You run AI agents and a customer, an auditor or a regulator wants evidence of what they did: execution provenance. How to produce tamper-proof evidence of AI agent actions walks through it.