Most enterprises spent the last five years building software supply chain controls: signed artefacts, dependency scanning, SBOMs, provenance attestation. Almost none of them apply the same discipline to the models sitting inside their AI platform. A fine-tuned model is a build artefact like any other, produced from a base checkpoint, a training dataset and a pipeline of transformations, and every one of those inputs can be tampered with, substituted or simply unknown. Treating a model as a trusted black box because it came from a reputable-sounding source is the exact mistake software supply chain security spent a decade correcting for code.
A model has a supply chain whether you track it or not
A production model typically traces back through a base checkpoint pulled from a public hub, one or more fine-tuning or adapter layers built in-house or by a vendor, and a serving pipeline that wraps it with prompts, tools and guardrails. Each link can be compromised independently: a poisoned base checkpoint, a fine-tuning dataset seeded with adversarial examples, or a serving configuration quietly swapped for one with weaker safety settings. Without provenance tracking, none of this is visible until behaviour in production forces someone to go looking, by which point the question is not just "what changed" but "how long has this been running."
The pattern that repeats across organisations we work with is that model provenance is tracked informally, if at all, usually as a filename convention or a note in a wiki that nobody updates once the model is deployed. That is the equivalent of managing production software dependencies with no lockfile, and it fails for the same reasons: nobody can answer "what exactly is running" with confidence when it matters most.
Treat checkpoints and datasets as signed, versioned artefacts
Require every base checkpoint entering the platform to carry a verifiable source, hash and licence, checked at ingestion rather than trusted on faith because it came from a well-known repository. Store that provenance record alongside the model in the registry, not in a separate document that drifts out of sync. The same applies to fine-tuning datasets: version them, hash them, and record which model versions were built from which dataset version, so a data quality problem or a suspected poisoning attempt can be traced to every model it touched.
Sign models before they are promoted to production, and verify that signature at deployment time, the same way a container image signature is verified before it reaches a cluster. This closes the gap where a model artefact can be substituted between the registry and the serving environment without anyone noticing, which is a realistic attack path once model registries become as valuable a target as source repositories already are.
Extend SBOM thinking to model bill of materials
A software bill of materials tells you what libraries and versions are inside an application. A model bill of materials should tell you the base checkpoint and version, every fine-tuning or adapter step applied, the datasets involved, and the evaluation results that qualified it for production. Generate this automatically as part of the model build pipeline rather than compiling it by hand after the fact, because manually maintained provenance records stop being trustworthy the first time someone is in a hurry.
This record earns its keep the day a base model vendor discloses a vulnerability or a training dataset is found to be compromised. Instead of an open-ended audit across every deployed model, a model bill of materials turns that into a direct query: which production models were built from the affected checkpoint or dataset, and can be answered in minutes rather than weeks.
- Record verifiable source, hash and licence for every base checkpoint before it enters the platform.
- Version and hash fine-tuning datasets, and link them to the model versions built from them.
- Sign models before production promotion, and verify signatures at deployment time.
- Generate a model bill of materials automatically as part of the build pipeline, not by hand afterwards.
- Give security and platform teams a way to query which production models trace back to a specific checkpoint or dataset.
- Extend existing software supply chain tooling and ownership to cover model artefacts rather than building a parallel, disconnected process.
Fold model provenance into existing supply chain ownership
The organisations making fastest progress are not standing up a separate "AI supply chain security" function from scratch. They are extending the ownership, tooling and incident response that already exists for software supply chain security to cover model artefacts, because the failure modes, tampering, substitution, unverified provenance, are the same shape even though the artefact is different. This also avoids the common trap of AI platform teams building their own registry and signing scheme in isolation, disconnected from the security tooling the rest of the organisation already trusts and monitors.
Where a dedicated capability is worth building is the model-specific evaluation gate: automated checks that a model meets safety and performance thresholds before promotion, which has no direct equivalent in software supply chains and needs to sit alongside signing and provenance rather than instead of it.
Common pitfalls
The most common failure is treating a well-known public checkpoint as inherently trustworthy and skipping provenance checks for it, which ignores that popularity makes a checkpoint a more attractive target, not a safer one. A second is building model provenance tracking as a manual, after-the-fact record that nobody keeps current once the pressure of a release schedule sets in. A third is standing up model supply chain security as an isolated initiative disconnected from the software supply chain controls and ownership the organisation has already invested in.
Teams also under-invest in verifying signatures at the point of deployment, treating signing as a checkbox at build time rather than an enforced gate that would actually catch a substituted artefact before it reaches production traffic.
Model weights and fine-tuning pipelines are production artefacts, and they need the same provenance, signing and bill-of-materials discipline that software supply chains were forced to adopt after the last decade of incidents. Need help extending supply chain security to cover your AI platform? Email sales@halfteck.com.