What matters in AI.

Subscribe

Learn / AI security

Definition · AI security

Model provenance

Model provenance is the verifiable history of where a machine learning model came from: which earlier models its weights were derived from, and how they were changed by fine-tuning, distillation, quantization or merging. It lets a team deploying a third-party model check the model's origin instead of trusting the name it was published under.

Last reviewed

Key points

  • A model can be derived from another by fine-tuning, distillation, quantization or merging, and each step makes a new checkpoint. Model provenance is the chain that links a model to the models it came from.
  • OWASP's 2025 LLM Top 10 says published models carry no strong provenance assurances. A model card describes a model but offers no guarantee of where it came from.
  • Metadata naming a parent model is easy to fake. Cisco argues that robust provenance detection has to rely on the weights themselves.
  • A signature proves a model file is unchanged since a named identity signed it. It says nothing about how the weights were made before that.

What the history records

Cisco notes that foundation models get fine-tuned, distilled, quantized, merged and repackaged, and that each step produces a new model checkpoint. Its Model Provenance Constitution counts each of these as a link to the parent: Fine tuning, distillation, quantization and merging, along with pruning (removing layers or parameters) and plain copies or format conversions. A merged model is linked to every parent that went into it. Model provenance is the whole chain.

On Hugging Face, a publisher can declare the direct parents. The base_model field in the model card names one or more base models, and the Hub infers whether the model is a fine-tune, adapter, quantization or merge.

Training data has its own record, AI dataset provenance. What an agent writes to memory has another, memory provenance.

Why it matters

A model’s name is not evidence of its origin. The OWASP LLM Top 10 for 2025 lists weak model provenance as a supply chain risk: “Currently there are no strong provenance assurances in published models.” Model cards “offer no guarantees on the origin of the model”. An attacker can take over a supplier’s account on a model hub, or publish a look-alike, and use social engineering to get it adopted. That is one route to AI supply chain compromise.

Provenance is also where later questions start. Does a deployed model inherit a known vulnerability from its parent? Does a third-party checkpoint trigger a licensing obligation? Cisco says both turn on one question: “is this model a derivative of that one?” Its constitution adds that the answer settles the facts, not the law: “The factual derivation question is separate from the legal obligation question.”

How a claim of origin gets checked

Cisco’s constitution accepts three kinds of evidence for a link between two models: official documentation naming the parent and the mechanism, checks on the checkpoints such as hashes, layer-by-layer comparison or reproducible derivation scripts, and peer-reviewed third-party analysis. Similar architecture and naming conventions are not enough.

Metadata is the weak point. Cisco’s threat model rates faking a derivation link “Trivial at the metadata surface” and says robust detection must rely on the weights. Cisco says its Model Provenance Kit fingerprints models at the weight level. Its constitution also warns that after fine-tuning on a very large amount of unrelated data the detectable signal can fall to near zero.

Signing answers a narrower question. Sigstore’s model-transparency project signs a list of the model’s file hashes. A valid signature from a trusted identity shows “the model hasn’t been tampered with after training”. It says nothing about how the weights were made. OWASP recommends signing and file hashes “to compensate for the lack of strong model provenance”. See verify AI artifacts.

Where definitions disagree

Cisco says definitions of a derivation relationship vary across licensors, standards bodies, research groups and AI labs, so one reviewer can call two models related and another call them independent. Its constitution takes a narrow reading: provenance is “the verifiable derivation history of a model’s trained weights”. Shared architecture, family name, organisation or training data do not, on their own, make two models related. Data provenance and authorship attribution are out of its scope.

SLSA, the software supply chain framework, defines provenance for software artifacts and centres it on the process. Its build provenance is “an attestation that a particular build platform produced a set of software artifacts”, and it records which platform ran the build. Cisco’s definition looks only at the weights, and leaves authorship attribution out of scope.

Questions and answers

Is a signed model the same as a model with provenance?

No. A signature covers the model's files and names who signed them. The sigstore model-transparency project says verification shows "the model hasn't been tampered with after training". It does not show which model the weights were derived from or what was done to them before signing. OWASP recommends signing and file hashes "to compensate for the lack of strong model provenance", not as provenance itself.

What is the difference between model lineage and model provenance?

The words overlap and are used loosely. Cisco's constitution uses weight lineage for the chain of derivation between models, the same thing it calls model provenance. Wiz uses model lineage for something inside one organisation, "tracing a model from training data, through pipelines, into production endpoints", and lists model provenance separately as recording "where each model came from and how it was changed".

Does a Hugging Face base_model field prove where a model came from?

No. It records what the publisher declared. OWASP's point applies: model cards "offer no guarantees on the origin of the model". Cisco's constitution rates faking a derivation link as "Trivial at the metadata surface". It accepts as evidence official documentation naming the parent, checks on the checkpoints themselves, or peer-reviewed third-party analysis.

Sources

  1. Model Provenance Constitution, Section 2Cisco AI Defense
  2. Defining Model Provenance: A Constitution for AI Supply Chain Safety and SecurityCisco, 30 Apr 2026
  3. LLM03:2025 Supply ChainOWASP
  4. Model Cards, Hugging Face Hub documentationHugging Face
  5. sigstore/model-transparency READMESigstore
  6. SLSA specification v1.2, ProvenanceOpenSSF
  7. SLSA specification v1.2, Build ProvenanceOpenSSF
  8. AI model security scanning: Best practices for cloud securityWiz, 23 Dec 2025