Skip to main content

The model supply chain

A model is an executable artifact you did not build, from a source you do not control, loaded into a process with access to your data. Every discipline the industry has learned about software supply chains applies, and almost nobody applies them to model weights.

This is the part of the AI story that is under-sold, so it is worth stating plainly: the platform treats a model the way it treats a dependency, a package and a signed release, because that is what it is.

On the way in​

ControlWhat it does
SBOM generationA software bill of materials for the artifact and what it carries
Dependency scanningThe dependencies a model artifact drags in
Model source validationWhere the artifact came from, checked rather than assumed
AttestationAttestation material captured and managed with the artifact
CompositionThe composed view of what an artifact actually is

These run on the acquire step, which is the one place in the provisioning pipeline where egress is legitimate and is therefore explicitly bounded by a network gate. Everything downstream of acquire runs with no network at all.

The registry, and what it can refuse​

Once an artifact exists, it is governed by a registry whose components are mostly named after refusals.

Figure: an artifact is scanned, has its provenance recorded, crosses a deployment gate with an approval broadcast, and is admitted by a governed loader that checks a signed manifest. A scan finding or a refused gate sends it to quarantine rather than into service, and a revocation snapshot withdraws a model already serving.

Table equivalent

ComponentWhat it is for
Model scannerInspects an artifact before it is trusted
Model quarantineWhere a failed artifact goes, rather than into service
Model provenanceWhere this artifact came from and what it was derived from
Deployment gateThe decision point before a model may be deployed
Approval broadcasterPropagates an approval decision rather than leaving it local
Artifact registryThe registry for local model formats and their manifests
Model watermarkMarking, so output can be attributed back to the model
Revocation snapshotWithdrawing a model that should no longer serve

Quarantine is the load-bearing one. A scanner that produces a report is advisory. A scanner whose finding routes the artifact somewhere it cannot be loaded from is a control.

At load time​

Serving is not the absence of a check. An in-process local runtime executes the artifact behind a signed-manifest admission gate, so an unsigned or altered artifact is not loaded rather than loaded with a warning.

The full chain is therefore: acquire under a bounded network gate, scan, record provenance, sign, stage, install, deploy, and refuse at admission if the manifest does not verify.

Adversarial robustness​

Two capabilities sit beside the supply chain and concern the model's behaviour rather than its bytes:

  • Adversarial drift detection, so a model's behaviour moving under adversarial pressure is a detected event.
  • A robustness tester, for exercising a model against adversarial input deliberately rather than waiting to observe it.

Output provenance​

  • Model watermarking, so generated content can be attributed.
  • An inference audit, recording the call.
  • An origin policy governing where an inference may come from, which is the control that makes "this answer was produced locally" checkable rather than assumed.

Why this matters commercially​

The question to ask any AI platform is not "which models do you support." It is:

What do you check before you load a model artifact, what happens to one that fails the check, and how do you withdraw one that is already serving?

Most platforms answer the first with "nothing", the second with "it loads anyway", and the third with "redeploy". A model supply chain with a scanner, a quarantine, a deployment gate, a signed-manifest admission check and a revocation snapshot is a different conversation, and it is the one a security team has to have before an AI program is approved.