What is LLM supply chain security?

It is the practice of verifying every component an LLM system depends on: base weights, fine-tunes and adapters, tokenizers, training and retrieval corpora, inference servers, orchestration frameworks, tool and MCP servers, prompt templates, and the provider API. Eight of those are artifacts that enter the environment and can be verified at build time through provenance and signing. The provider API is contacted fresh on every request and can only be constrained at the call.

How do you verify model provenance?

Restrict artifact formats to safetensors so that loading a model is a data operation rather than a code-execution primitive. Require signatures and record the hash of every weight file, adapter, and tokenizer that enters the environment, together with its source. Record which model artifacts are permitted in which environments, and enforce that at load time in the inference platform. Then close the runtime half by enforcing which model endpoints and versions each identity may call.

Are model weights a supply chain risk?

Yes, in two distinct ways. Pickle-backed weight formats execute arbitrary code on load, which makes an untrusted weight file an execution vector regardless of the model's behavior. Separately, a fine-tune or adapter can change refusal behavior across the model without changing any code around it, which makes it a behavioral risk that code review never catches. Both are handled at the artifact layer, through format restriction, signing, and provenance.

What is the difference between SBOM and AIBOM?

A software bill of materials enumerates code dependencies. An AI bill of materials adds the components a dependency tree never contains: model artifacts and their versions, adapters and fine-tunes, tokenizers, the corpora behind a retrieval index, the inference runtime, prompt templates, and the external model endpoints the system calls. The last of those is the entry an SBOM has no place for and the one an enforcement layer at the request boundary can keep accurate in real time.

Can a gateway prevent a poisoned model from being deployed?

No, and the distinction is worth keeping sharp. Preventing a poisoned artifact from reaching production is a build-time control: signature verification, format restriction, provenance, and isolation of the loading process. What the gateway prevents is an identity reaching a model or provider that policy has not authorized, which stops an unapproved fine-tune from being called even when it has been deployed somewhere. It also records the model behind every response, so a poisoned model's outputs can be found and reversed rather than inferred.

LLM Supply Chain Security: Nine Components, and the Only One You Can Enforce at Runtime

Ask a platform team to produce the software bill of materials for an LLM application and you will get the Python dependency tree. That tree describes the smallest part of the actual supply chain. The model weights are not in it. Neither are the LoRA adapter someone fine-tuned in March, the tokenizer that ships alongside the weights, the vector index built from a corpus nobody has reviewed since it was seeded, or the third-party tool server that the agent calls forty times an hour.

Nine components carry supply-chain risk in a production LLM system. Eight of them are verified before the system runs. Exactly one is verified while it runs, and knowing which is which decides where the enterprise's controls go.

The nine components

1. Base model weights. Distributed as files, frequently in Python pickle-backed formats that execute arbitrary code on load. A weight file downloaded from a public hub is a code-execution primitive with a data-file extension. The controls are format restriction to safetensors, signature verification, and isolation of the loading process.

2. Fine-tunes and adapters. A LoRA adapter is small, cheap to produce, trivial to share, and capable of changing refusal behavior across the whole model. Stanford Trustworthy AI research summarized in the AIUC-1 Consortium briefing found refusal behaviors degraded significantly under targeted fine-tuning (Help Net Security). An adapter is a security-relevant artifact and belongs under the same provenance rules as the base weights.

3. Tokenizers and configuration files. They ship in the same bundle, they are loaded by the same code path, and nobody reads them. A tokenizer with a modified vocabulary changes what the model sees without changing the weights at all.

4. Training and RAG corpora. Poisoning at training time is the classic attack and requires access most attackers lack. Poisoning the retrieval corpus requires only the ability to write a document that will later be indexed, which in most enterprises means a wiki page or a shared drive. The stored document then delivers an indirect injection every time it is retrieved, which MITRE ATLAS catalogs as AML.T0051.001.

5. Inference servers. vLLM, Ollama, LMDeploy, TGI, and the rest. These are the components taking CVEs at pace. LMDeploy's CVE-2026-33626 saw exploitation roughly 13 hours after advisory. They are network services and belong under the same patch and exposure discipline as any other network service, which is precisely the discipline they usually escape by arriving through a data science team.

6. Orchestration frameworks. LangChain, LlamaIndex, Langflow, marimo, LiteLLM. CVE-2026-39987 in marimo gave pre-auth RCE. Langflow's CVE-2026-55255, a CVSS 9.9 cross-tenant IDOR that exposes embedded provider keys and cloud credentials, reached active exploitation on July 8, 2026 (Help Net Security). These frameworks hold the credentials for everything downstream of them, which makes them the highest-value component in the list.

7. Tool and MCP servers. Researchers disclosed more than 40 CVEs against Model Context Protocol implementations between January and April 2026, and the CSA and OX Security research note of April 20 traced a common root to configuration-to-command execution across the SDKs, with an affected supply chain spanning an estimated 150 million downloads (CSA Labs). A tool description is also model-visible text, which makes it an injection surface as well as a code surface.

8. Prompt templates. They live in the repository, they are edited by whoever is iterating on quality, and they are rarely reviewed as security artifacts. A system prompt that instructs the model to trust retrieved content is a supply-chain defect written in English.

9. The provider API. The one component the enterprise never possesses. You call api.openai.com and receive a response from a model whose exact weights, safety configuration, and version routing are the provider's decision. Model providers secure the model. The enterprise owns how AI is used inside its environment, and owns the liability for the outcome. When The Register asked Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday how much liability they accept for AI agent decisions, Microsoft and SAP declined to comment and the rest did not respond (The Register).

Eight are build-time. One is runtime.

Components 1 through 8 are all verified before or during deployment. Provenance, signing, format restriction, dependency pinning, CVE tracking, and code review are the instruments, and they work at the point where the artifact enters the environment. An AI bill of materials records what entered and when, which is why the AIBOM concept is worth building rather than buying; I go through its contents in AI bill of materials explained.

Component 9 has no build-time gate at all. The provider API is contacted fresh on every request, and what answers is decided by the provider's routing at that moment. The only place an enterprise can express a requirement about it is the call itself.

State that as a control and it becomes concrete: which provider, which model, which version, and which region a given identity is permitted to reach, evaluated on every request, with the answer recorded. A team that pins gpt-4o-2026-05 in policy at the request boundary is doing dependency pinning on a component that has no lockfile. When an application starts calling an unapproved provider, an unreviewed fine-tune hosted somewhere new, or a model version that has not been through evaluation, the call is refused at the boundary rather than discovered in a bill later.

The honest boundary

This is where most vendor content in this category overclaims, so I will be plain. An HTTP enforcement layer inspects requests to model endpoints. It never reads a weight file, never validates a signature on an adapter, and never sees the pickle payload that executed when the inference server loaded a model. Components 1 through 8 are owned by artifact provenance, patching, and workload isolation, and no proxy substitutes for them.

What the boundary adds to the supply-chain program is three things. It enforces which upstream components an identity may reach, which is the runtime half of dependency control. It observes the calls a compromised component makes, since a poisoned framework still has to reach a model to be useful to an attacker. And it produces the per-decision record that ties a bad output back to the exact model and version that produced it, which is what makes a corrupted response traceable rather than merely suspected.

The regulatory pull

EU AI Act Article 12 requires automatic recording of events over the lifetime of a high-risk system to ensure traceability, including timestamps, input data, and identification of the natural persons involved (Practical AI Act), and Article 99 sets penalties at €15 million or 3% of global annual turnover (EU AI Act Article 99). Article 11 and Annex IV push in the same direction on technical documentation of the system's components. A record that names the model and version behind every decision satisfies part of both obligations as a byproduct of enforcement.

DeepInspect

This is the gap DeepInspect closes on component 9. DeepInspect is a stateless proxy at the AI request boundary, between authenticated users or agents and any HTTP-based LLM endpoint. Model authorization is policy: which providers, models, and versions a given identity or role may reach, evaluated on every call and enforced inline with a fail-closed default, at under 50 ms of overhead in internal testing.

Every decision writes a signed record naming the identity, the provider, the model and version, the policy in force, and the outcome, committed before the response returns to the calling application. That gives the enterprise a runtime bill of materials for its AI traffic, produced continuously by a component the applications under review do not control, alongside the build-time bill its artifact pipeline produces. The proxy is model-agnostic, so the same policy covers OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints.

If you have a software bill of materials and no idea which models your applications actually called last week, book an AI readiness assessment.