Model and data securityAdvancedLesson 1737 min read

Provenance: signing models and the AI bill of materials

You cannot trust a model you cannot trace. Learn hashes, signing, build provenance and the AI bill of materials.

Lesson in motion

In 60 seconds

Provenance: signing models and the AI bill of materials

You cannot trust a model you cannot trace. Learn hashes, signing, build provenance and the AI bill of materials.

1/4
In simple words
A packet of food has a label: what is inside, who made it, when it expires. A good model should have a label like that too, so you know what went into it and who made it.
Provenance means knowing where something came from and what happened to it along the way. For AI, that covers the base model, the datasets, the code, the training run and every change after. It matches LLM03 Supply Chain in the OWASP Top 10 for LLM Applications.

Four tools that build trust

ToolAnswers the questionSimple description
Hash (for example SHA-256)Is this exactly the same file?A fingerprint of the file. Any change gives a different hash.
SignatureWho vouches for this file?A cryptographic proof that a known identity approved this exact file.
Build provenanceHow was it made?A signed record of the inputs, code and environment used to produce it.
Bill of materialsWhat is inside it?A list of the components: base model, datasets, libraries, licences.

Signing, in general terms

Sigstore is an open-source project that makes signing software easier, including keyless signing tied to an identity such as a work account or a build system, with public transparency logs. The same ideas are being applied to model files. You sign the model (or a manifest of hashes for all its files), and anyone can check that the signature is valid and who made it.
SLSA (Supply-chain Levels for Software Artifacts) is a framework for build integrity. It describes increasing levels of assurance about how an artifact was built, using provenance records produced by the build system. You can apply the same thinking to training runs: the pipeline, not a person's laptop, should produce and sign the model.

The AI bill of materials

An SBOM (software bill of materials) lists software components. An AI-BOM or ML-BOM extends this to models and data. The CycloneDX standard supports ML-BOMs, so you can describe models in a format tools can read.
FieldExample
Model name and versionsupport-intent-classifier v3.2
File hashesSHA-256 of each weight file
Base model and its sourceAn open model, exact revision, official repository
DatasetsNames, versions, hashes, owners, whether they contain personal data
Training code and environmentGit commit, container image digest, key library versions
LicencesModel licence, dataset licences, any use restrictions
Evaluation resultsAccuracy, safety and security tests passed, with dates
Owner and approvalTeam, approver, release date

Licences matter too

  • Open models come with many different licences. Some limit commercial use, user numbers or certain uses.
  • Datasets have their own terms, and some forbid commercial use.
  • A fine-tuned model may carry the obligations of both its base model and its data.
  • Track licences in the AI-BOM and have legal counsel review anything unclear.
  1. 1

    Record

    Capture sources, hashes and licences as data comes in.
  2. 2

    Build

    Train in a pipeline that writes provenance automatically.
  3. 3

    Sign

    Sign the model and its manifest from the pipeline identity.
  4. 4

    Verify

    Check signature and hashes before deploying or loading.
  5. 5

    Keep

    Store the AI-BOM with the model and update it on every change.
Note
Provenance and signatures prove where something came from. They do not prove it is good. A signed model from a careless or malicious source is still a bad model.

Watch and read more

Lab

A complete AI-BOM entry for one model, with verified hashes.

~30 min

The problem

Choose one model your team uses or plans to use (or a small open model you download for practice).

  1. Fill in every field from the lesson's table: name, version, file hashes, base model and source, datasets, training code and environment, licences, evaluations, owner and approval.
  2. Compute the hashes yourself and compare with any published values.
  3. Mark each field as known, partly known or unknown.
  4. For each unknown field, write who could provide the answer.
  5. Optional: look at the CycloneDX site and map your fields to its ML-BOM structure.
Starter codejson
{
  "model": { "name": "", "version": "", "owner": "" },
  "files": [ { "path": "", "sha256": "" } ],
  "base_model": { "name": "", "source": "", "revision": "" },
  "datasets": [ { "name": "", "version": "", "sha256": "", "personal_data": false, "licence": "" } ],
  "training": { "code_commit": "", "container_digest": "", "run_id": "" },
  "licences": [ "" ],
  "evaluations": [ { "name": "", "result": "", "date": "" } ],
  "approval": { "approved_by": "", "date": "" },
  "status_notes": ""
}

You are done when

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1Why should the training pipeline, not an engineer, sign the model?Reveal

If a person signs, the signature says "this person approved it", but not how it was built. A person's laptop can be compromised or used to sign an unreviewed file. When a controlled pipeline signs, the signature is tied to a known, reviewed process, and provenance records show the exact inputs. Human approval can then be a separate recorded step.

Q2Your base model's training data is not published. What can you still record and do?Reveal

Record the base model's exact source, revision, hashes, licence and published model card. Note clearly that its training data is unknown, and treat that as a risk: run your own evaluations for bias, harmful output, memorised data and unexpected triggers, and limit the uses you approve until you are comfortable.

Please sign in to continue.

Questions people ask

Do we need an AI-BOM if we only use a hosted model through an API?

You cannot see inside it, but you can still record what you use: provider, model name and version, data terms, region, and what data you send. Your AI inventory is the start of an AI-BOM.

Is a hash on a website enough?

It protects against corruption and some tampering in transit. It does not protect you if the website itself is compromised. A signature tied to a known identity, checked with a trusted tool, gives stronger assurance.

Who should maintain the AI-BOM?

Generate it automatically in the training and release pipeline, so it stays accurate. The model owner is responsible for its correctness, and security or GRC teams read it for audits and incidents.

Why does this help during an incident?

When a problem is found in a dataset, library or base model, you need to know quickly which of your models use it. Without a BOM, that search can take days. With one, it can take minutes.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Sign in to take the test and save your progress