LLM04: Supply Chain (Models, Adapters, MCP Servers)

How LLM04: Supply Chain (Models, Adapters, MCP Servers) works

An LLM deployment inherits trust from everything it loads: base weights, fine-tune checkpoints, LoRA adapters, quantized re-packs, serving frameworks, container images, and MCP servers whose tool definitions land directly in the model’s context. Some of those artifacts execute code at load time, and none of them pass through the application’s authentication or input validation.

The usual finding is not an exploit against the model but a pull that resolves to something nobody reviewed: an unpinned revision following a moving branch, a deleted organisation name re-registered by someone else, an alias promoted without review, a mirror serving a different blob than the registry recorded. The 2026 edition keeps the title Supply Chain and moves the entry down one place from LLM03:2025, because Excessive Agency climbed to third. Its scope widened to artifact provenance and the promotion boundary, malicious LoRA adapters, conversion, merge and quantization workflows - weights can be crafted so the full-precision model evaluates benignly while the quantized artifact misbehaves - and graph-level backdoors that survive formats treated as safe such as ONNX. Signing proves integrity and origin, not safety.

Scope note: OWASP assigns agentic supply-chain risk, MCP servers and tool registries included, to ASI04 Agentic Supply Chain Vulnerabilities in the Agentic Applications Top 10. The MCP Server And Tool Poisoning page is kept here because the pull, pin and verify questions are identical to those for model artifacts; pair it with the agentic list when the deployment is an agent rather than a model-as-component.

Keywords: ai bom, model provenance, artifact signing, lora adapter, mcp server trust, quantization divergence, model registry

Examples/Proof

• Load-time code execution
  • Feed a benign canary artifact through the loader the target uses and look for the canary file in the serving container; the Unsafe Model Artifact Deserialization page owns payload construction.
• Digest drift after promotion
  • Compare the repo id, commit sha and file digests the server loaded at startup against the registry record for that release.
• Floating references
  • Grep serving images and host config for pkg@latest, uvx installs, omitted revisions and untagged images; two launches resolving differently proves nothing is pinned.

Detection and Monitoring

• Load-time inventory
  • Log repo id, commit sha, file digests and adapter paths at process start; diff against the approved AI BOM.
• Verification outcome
  • Emit verified, skipped and failed as distinct events; alert on anything that is not verified.
• Tool catalog drift
  • Hash each MCP server’s tool names, descriptions and schemas per session and alert on change.

How to fix and prevent LLM04: Supply Chain (Models, Adapters, MCP Servers)

1. Pin to immutable references
   • Use commit shas and image digests, never branches or latest, and fail closed on a missing pin.
2. Verify signatures at load time
   • Check OpenSSF Model Signing or Sigstore attestations in the loader, not only in CI.
3. Prefer non-executing formats
   • Require safetensors, reject pickle-bearing files at ingest, and leave torch.load on its weights_only default.
4. Separate promotion identities
   • Give CI an identity that cannot move production aliases, and convert artifacts in a sandbox with no credentials and no egress.

Prevention Checklist

• AI BOM lists every model, adapter, dataset and MCP server with a digest
• Signature and digest verification enforced at load time, not just in CI
• No pickle artifacts and no trust_remote_code in production images
• Private mirror is the only egress path for model and package pulls
• MCP servers and tool definitions pinned, with re-approval on drift

Last updated 2026-08-19