Security teams have spent a decade hardening the software supply chain: signed packages, reproducible builds, dependency scanning. AI models have joined that chain, and they bring their own problems. A model is a large binary that is often downloaded from a public hub, loaded by code that may execute what it finds, and served by machines whose identity the caller rarely checks.
The OWASP Top 10 for LLM Applications lists supply chain risk as a top-tier concern, covering vulnerable pre-trained models, tampered or poisoned weights and weak provenance. This article sets out a layered control set, from the file on disk to the machine answering a request.
Layer 1: refuse formats that execute code
The most direct attack is a model file that runs code when loaded. In 2024 JFrog reported finding around 100 models on a public hub with malicious functionality, using Python's pickle deserialisation to execute code when a PyTorch model was loaded; one opened a reverse shell to an external address.
Controls:
- Accept only formats that store tensors as data, such as safetensors or GGUF, and check their headers for internal consistency.
- Refuse pickle, including pickle embedded in archive formats, regardless of file name.
- Treat unknown large binaries as suspect by default.
Layer 2: know exactly which bytes you have
A model name is not an identity. The same repository name can point to different weights over time, and mirrors can diverge.
Controls:
- Pin every file by hash at a specific revision, and refuse a download whose bytes do not match.
- Build a manifest for each model: every file, its size and its hash, combined into a single root hash that names the model.
- Corroborate across origins. A hash observed independently at the creator's own publication, at a hub revision and at a mirror is far harder to fake than a hash from one source.
- Check again at load time, not only at download. Files on disk can change.
Layer 3: sign what you publish
Signatures bind a model to whoever vouches for it. In April 2025 the OpenSSF released model signing v1.0, a library and command-line tool for signing and verifying models of any format and size, defaulting to Sigstore with signatures recorded in a public transparency log.
The same discipline applies to the serving software. Inference engines change often and run with access to everything the model sees; release binaries should be signed, and operators should verify size and hashes before installing.
Layer 4: protect the data around the model
Training and fine-tuning data is part of the supply chain too. The May 2025 joint guidance led by the NSA's AI Security Center with CISA, the FBI and partner agencies, announced by CISA, focuses on data supply chain risks, maliciously modified (poisoned) data and data drift across the AI life cycle. Hashes and signatures over datasets, recorded alongside the model they produced, extend provenance from weights back to inputs.
Layer 5: verify the machine that serves
A perfectly verified model file proves nothing if the caller cannot tell which machine served the answer, or whether that machine loaded the verified file. Controls:
- Hardware-held serving identity. The serving machine signs each response with a key held in a TPM or secure enclave, so responses are attributable to a specific machine.
- Receipts that name the model. The signed response includes the model's hash, not just its name.
- Attested execution for sensitive work. In a confidential VM, the attestation report states which software image is running; when the report also commits to the verified model manifests, the caller has evidence of both the code and the weights.
- Revocation. Certifications, scans and keys need a way to be withdrawn that every verifier sees.
A control matrix
| Threat | Control | Evidence |
|---|---|---|
| Code execution on load | Safe formats only; refuse pickle | Scan result per file |
| Swapped or tampered weights | Hash pinning, multi-origin manifests, load-time checks | Manifest root, load report |
| Unverified publisher | Signed catalog entries and model signatures | Signature, publisher identity |
| Compromised serving software | Signed releases, verified install | Release signature, installed hashes |
| Impostor serving machine | Hardware-held keys, signed receipts | Receipt naming machine and model hash |
| Sensitive data exposure in serving | Confidential computing with attestation | Attestation report |
Regional notes
US agencies and critical-infrastructure operators are directly addressed by the joint data security guidance. In the EU, the AI Act's obligations for general-purpose model providers include technical documentation, and NIS2 and the Cyber Resilience Act add supply-chain and vulnerability duties for many operators and products. The UK's NCSC co-signed the 2025 data security guidance. Across regions, the controls above are the practical common ground.
What this means for security teams and infrastructure operators
Bring models under the same supply-chain controls as code, then go one step further: require evidence from the serving machine, not just from the build.
Where Tenzro fits
Tenzro is an open network of independent operators serving AI, so it has to treat every model and every machine as untrusted until verified. Built today:
- Ingest scanning. Safetensors and GGUF headers are checked for consistency; pickle, including inside PyTorch archives and NumPy object arrays, is refused whatever the file is called; unknown binaries above 16 MiB are refused.
- Model manifests and multi-origin corroboration. A model is named by the BLAKE3 Merkle root of a manifest of every file. It counts as verified only when every file is confirmed by at least two observers across at least two distinct origins with no contradicting signed observation.
- Load-time checks. Each file is hashed before weights load and checked against the catalog pin and the verified manifest; a mismatch refuses the load. On TEE hardware, the attestation commits to the verified manifest roots.
- Signed, bonded catalog. Catalog entries are signed by publishers who post a bond; an entry whose pinned hash does not match its source can be challenged, and an upheld fault slashes the publisher's bond and removes the entry. Gated weights are never redistributed between peers.
- Signed releases and credentials. Node releases are signed and verified before install. Anyone can issue signed certifications, ratings or safety-scan credentials about a model or operator, with revocation lists every node checks.
- Signed receipts. Served answers carry a receipt signed under the machine's hardware identity, naming the catalog model hash and engine.
The network is live in preview. See tenzro.com.
Sources
- JFrog: Data scientists targeted by malicious Hugging Face ML models with silent backdoor (2024)
- OWASP GenAI Security Project: LLM03:2025 Supply Chain
- Google Security Blog: Taming the Wild West of ML, Practical Model Signing with Sigstore (April 2025)
- CISA: New best practices guide for securing AI data released (May 2025)
- Hugging Face: Safetensors documentation



