AIBOM & Model Signing: Knowing What's Actually in Your AI

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 24)

▶ Watch on YouTube & subscribe to The Stack Underflow

Somewhere between the model hub and your production inference endpoint, a lot of artifacts cross your trust boundary — model weights, datasets, Python packages, and MCP server binaries, often from a dozen different sources. Most teams cannot answer a deceptively simple question: what, exactly, is loaded at runtime right now, and did any of it change since you last checked? That gap is not a theoretical concern. In March 2026, attackers compromised LiteLLM — a widely-used LLM proxy gateway — through a single poisoned PyPI package, exposing more than 40,000 AI pipelines in 40 minutes (OWASP LLM03:2025).

If you cannot enumerate your AI supply chain, you cannot verify it, and you cannot recall a compromised artifact when one surfaces. This tutorial is the defender’s answer: build an AIBOM (an AI Bill of Materials), sign and verify every artifact before it loads, scan model files for unsafe deserialization, and fail closed on anything unsigned or unlisted.

The one-sentence version: You cannot secure a supply chain you cannot list — an AIBOM gives you the inventory, model signing gives you the gate, and fail-closed loading means unknown artifacts never cross the boundary.

Why the AI supply chain is uniquely hard to see

Traditional software has SBOMs (Software Bills of Materials). An SBOM is a machine-readable list of every library, package, and dependency in an application. SBOMs are now required by executive order for US federal software procurement, and most package managers can generate one automatically.

AI systems break the SBOM model in three ways:

An AIBOM extends the SBOM idea to cover the AI-specific layer. Every row in an AIBOM answers: what artifact, which version, what hash, where did it come from, and is there a valid signature?

AIBOM — AI Bill of Materials
─────────────────────────────────────────────────────────────────────
TYPE        NAME                VERSION   HASH (sha256)      SIG
─────────────────────────────────────────────────────────────────────
MODEL       org/llama3-8b       v3.1      a4f7c9...d2e1      ✓
DATASET     common-crawl-2025   v25.04    bc09f1...8a3c      ✓
PACKAGE     transformers        4.42.0    71de3b...9f0a      ✓
MCP SERVER  tool-srv            v0.9      cc5d11...43b7      ✓
─────────────────────────────────────────────────────────────────────

Two payoffs fall out of this list immediately. Provenance — you know what is actually loaded — and a recall path — when an artifact is found compromised, you know exactly which deployments ran it and what to pull.

The AIBOM maps squarely to OWASP LLM03:2025 (Supply Chain Vulnerabilities) and to MITRE ATLAS technique AML.T0010 (AI Supply Chain Compromise), added in v5.1.0 (November 2025). Under NIST AI RMF, maintaining this kind of inventory falls in the Govern and Map functions: you cannot govern what you have not enumerated.

The attack the AIBOM defends against

Before building the gate, understand what it is blocking. The AI supply chain attack flow works like this:

  Attacker                      Artifact Hub / Registry
  ────────                      ──────────────────────
  1. Tamper with model weights  →  upload to public repo
     OR poison a dataset slice  →  push to dataset registry
     OR compromise a package    →  push to PyPI / npm
     OR register a rogue MCP    →  publish to MCP marketplace

  Your AI app (at load time)
  ──────────────────────────
  2. Pull artifact  ←─────────────── no hash check
  3. Load artifact  ←─────────────── no signature verify
  4. Artifact runs  ←─────────────── malicious payload executes

No signature pinning means the tampered artifact looks identical to the legitimate one — same name, same version tag, different bytes. Without a hash check, you will never know. This is the gap the AIBOM + signing gate closes.

Sign and verify: pinning hashes and checking signatures

Model signing means that every artifact carries a cryptographic signature, and you verify that signature before the artifact is allowed to load. The practical implementation in 2025–2026 uses Sigstore — the same open-source infrastructure already used for container and package signing. The sigstore/model-transparency project (v1.0, 2025) provides a model-signing PyPI package that attaches a Sigstore bundle to a model directory, covering every weight file with a hash manifest that is then signed (Red Hat Emerging Technologies, April 2025).

The verification flow:

  Artifact arrives at load boundary
           │
           ▼
  1. RECOMPUTE hash of artifact bytes
           │
           ▼
  2. COMPARE to hash recorded in AIBOM
           │
     match? ──► NO  ──► BLOCK (fail closed) ─► alert
           │
          YES
           │
           ▼
  3. VERIFY cryptographic signature
     (sigstore bundle / cosign)
           │
     valid? ──► NO  ──► BLOCK (fail closed) ─► alert
           │
          YES
           │
           ▼
  4. LOAD artifact

The mechanism is exactly what package signing does for pip or npm — it just extends to model weights, datasets, and MCP server binaries. For public model releases, keyless signing (OIDC-tied, via Sigstore) is usually the right default: it removes the private-key management problem and creates an audit trail tied to a real identity.

The critical policy — inherited directly from Zero-Trust principles — is: allow known good, block everything else. If an artifact is not in the AIBOM, or its signature does not verify, it fails closed. It does not load.

Scanning model files for unsafe deserialization

Signature verification tells you the artifact has not been tampered with since it was signed. It does not tell you whether the artifact was malicious when it was signed. For model weight files, there is a separate hazard: unsafe deserialization.

Some model serialization formats — most famously Python’s pickle format, which PyTorch’s torch.load() uses by default — execute arbitrary Python code during deserialization. An attacker who controls a model file can embed a payload that runs at load time, before any inference code sees it.

This is not theoretical. Recent CVEs include:

• CVE-2025-67729 (lmdeploy): torch.load() called without weights_only=True allowed arbitrary code execution when loading a crafted checkpoint (GitHub Advisory Database, 2025).
• CVE-2025-32434 (PyTorch): Even weights_only=True — the recommended mitigation — was bypassed for remote code execution (CVSS 9.8), fixed in PyTorch 2.6.0.
• CVE-2026-24162 (NVIDIA Transformers4Rec): Pickle deserialization via torch.load() allowed arbitrary object construction (DailyCVE, June 2026).
• CVE-2026-54499 (Stanza): Safe-load fallback logic re-invoked weights_only=False, enabling full pickle execution without restriction.

The defense layer is a model scanner — a tool that inspects the serialization format before the file is loaded by the ML runtime. picklescan (with the caveat that bypass techniques exist; Sonatype documented four bypasses in 2025) and format conversion to safer serialization (e.g., safetensors) are the two main approaches. Safer formats like safetensors strip executable content by design and should be preferred for new model artifacts.

  Load path
  ─────────────────────────────────────────────────────────
  Model file  ──►  [SCANNER: unsafe deserialization check]
                          │
               found unsafe ops? ──► BLOCK (fail closed)
                          │
                        clean
                          │
                          ▼
               [SIGNATURE VERIFY gate]
                          │
                          ▼
               ML runtime loads model
  ─────────────────────────────────────────────────────────

How to defend: four layered gates

The defense stacks four moves. Each one stops a different failure mode.

AIBOM tooling in practice. The aibomgen research tool (arXiv 2501.05703, January 2025) demonstrated automated AIBOM generation covering training pipeline artifacts. JFrog’s AIBOM guidance (2025) recommends coupling model-registry scanning directly to the AIBOM update pipeline so that every new artifact version triggers a hash-and-sign step before it can be pulled by any downstream deployment.

Recall path. When a new CVE or compromise disclosure arrives for an artifact you depend on, the AIBOM row for that artifact shows every deployment that loaded it. You pin forward to a clean version or pull the deployment until a verified replacement is available. Without the AIBOM, you are issuing a “who knows if they’re running it?” broadcast — the kind that takes days to resolve.

Common misconceptions

• “SBOMs cover everything an AI system uses.” A traditional SBOM covers software packages and libraries. It cannot represent model weights (opaque binary artifacts), dataset versions (data lineage), or dynamically-loaded MCP servers. The AIBOM is specifically the extension that fills those gaps. Use both together.

• “Downloading from an official model hub means the artifact is safe.” Official repositories do not guarantee the artifact was not tampered with after upload, and they do not verify the artifact’s origin in the sense of cryptographic provenance. Supply-chain attacks target the upload side. Hash pinning and signature verification are your checks, not the hub’s reputation.

• “Scanning for pickle is enough to detect malicious models.” Sonatype disclosed four bypasses of picklescan in 2025 alone. Scanning is a layer, not a guarantee. The right long-term answer is migrating to serialization formats that do not support code execution at load — safetensors is the current recommendation for PyTorch models.

• “Fail-closed is too disruptive for production.” Fail-closed on unsigned artifacts is disruptive the first time you enforce it, because it surfaces everything in your supply chain that was never signed. That surface area is exactly what you need to see. Enforce it in a staging environment first, build the signing pipeline, then promote to production. Discovering unsigned artifacts in staging is the point of the exercise.

Frequently asked questions

What is the difference between an SBOM and an AIBOM? An SBOM (Software Bill of Materials) lists software packages, libraries, and dependencies — the kind of artifacts that appear in package manifests. An AIBOM extends that concept to the AI-specific layer: model weights, datasets, training pipeline artifacts, and dynamically-loaded tools like MCP servers. Neither replaces the other. A complete AI supply chain inventory requires both: the SBOM for the code stack, the AIBOM for the AI artifact stack.

How does model signing work in practice today? The most mature implementation is the sigstore/model-transparency project, which provides a model-signing package on PyPI. It computes hashes of every file in a model directory, assembles a signed manifest, and stores the Sigstore bundle alongside the model. Verification recomputes the hashes and checks the signature against the Sigstore transparency log. For teams already using cosign for container signing, the workflow is nearly identical. Hugging Face and Kaggle integrations are in active development.

What serialization formats are safer than pickle? Safetensors (developed by Hugging Face) is the current standard recommendation for PyTorch model weights. It stores only tensor data in a format that cannot execute code on load, making the entire class of unsafe-deserialization attacks structurally impossible. ONNX with external data and TensorFlow’s SavedModel format have similar properties. The migration cost is a one-time conversion step; the security gain is permanent for that artifact class.

What frameworks require or recommend AIBOMs? OWASP LLM03:2025 (Supply Chain Vulnerabilities) calls for verifying artifacts and maintaining provenance records. NIST AI RMF maps artifact inventory to the Govern and Map functions. The EU AI Act (in force for high-risk systems from 2025–2026) requires technical documentation that covers data governance and model provenance — an AIBOM satisfies large parts of that requirement. US DoD AI security directives also reference SBOM/AIBOM requirements for AI-enabled systems.

If an artifact passes signature verification, does that mean it is safe? Not necessarily. Signature verification proves the artifact has not been tampered with since it was signed by the key or identity you trust. It does not prove the artifact was benign when it was signed. A threat actor who controls the signing key, or who introduced a backdoor before the signing step, can produce a validly-signed malicious artifact. This is why scanning (checking for unsafe deserialization, known malicious patterns) is a separate, complementary layer — not a redundant one.

How does this interact with the MCP supply chain? MCP servers are dynamically-loaded tools that give agents access to file systems, APIs, and network calls — high-privilege capabilities that make them high-value tamper targets. The AIBOM row for an MCP server should include its binary hash and a verified source. At load time, the same signature-verification and fail-closed policy applies: an MCP server binary that is not in the AIBOM, or whose hash does not match, does not load. See The AI Supply Chain and Securing MCP for the full attack flow.

Where this fits in the series

This tutorial is the defender’s companion to The AI Supply Chain and Securing MCP, which covers how the attack enters. Together they complete the supply-chain picture for stage S3 (Deploy/Supply) in the AI attack surface model.

The AIBOM and signing gates assume you have already mapped your threat surface — How to Threat Model an AI System covers the ATLAS/OWASP/NIST methodology for doing that systematically. And for the broader principle that all of this defends on — allowing only known-good artifacts and failing closed on everything else — see Zero Trust for AI.

Once the model artifacts are verified and loaded, the next attack surface opens: the tools and autonomy you hand to an agent. That is where excessive agency, memory poisoning, and tool misuse take over — starting with Excessive Agency: When an AI Agent Does Too Much.

Browse all tutorials to follow the full series.