LLM Model Artifact Supply Chain in Production: Protecting Against Weight Tampering with Safetensors, Signatures, and Admission Scanning

The Problem: Model Weights Are Production Artifacts

Many teams treat LLM deployment as “download weights, plug into inference service, run a smoke test.” This is fast for experimentation but risky in production. Model repository files aren’t just parameter matrices—they include config.json, tokenizers, processors, adapters, quantization configs, custom code, inference examples, and notebooks. If any component is compromised, downstream inference, fine-tuning, evaluation pipelines, and offline batch processing are all affected.

Pickle-based model files deserve special attention. Hugging Face’s Pickle Scanning documentation clearly states that pickle can execute arbitrary code during deserialization, and recommends loading models only from trusted users and organizations, relying on signed commits, or using alternative formats like TensorFlow, JAX, or safetensors. The Hugging Face Hub also performs malware scanning and pickle import scanning on uploaded files, but the docs note that scanning is not 100% foolproof—the user must ultimately judge file safety.

Therefore, production teams should treat model weights, adapters, tokenizers, and configuration files as immutable model artifacts, not as ordinary download caches. This article focuses not on training security or output safety, but on supply chain governance before a model enters production.

Core Principle: Download ≠ Trust, Loadable ≠ Deployable

The model artifact supply chain can be broken down into four gates.

Gate 1: Format Admission

Prefer safetensors; restrict or ban pickle-prone weight files like .pkl, .pickle, .pt, .pth, and .bin. Hugging Face’s Safetensors documentation describes it as a simple format for safely storing tensors—safer than pickle, with fast loading and zero-copy support. The Hugging Face model release checklist also recommends uploading weights as safetensors over pickle or pth.

Gate 2: Source Admission

Models must be bound to a trusted source—e.g., an internal training pipeline, a controlled organization account, a specific commit, a protected tag, a signed commit, or a private registry. Recording just the model name is insufficient, as the same repository can be updated continuously. Production systems need to track repo, revision, commit_sha, file digest, and approval records.

Gate 3: Scanning Admission

Before a model file enters the registry, perform malware scanning, pickle import checks, file type whitelisting, anomalous size detection, license checks, external code reviews, and dependency scanning. Scan results shouldn’t just be logs—they should be part of the release gate.

Gate 4: Signature & Provenance Admission

A hash proves the file hasn’t changed; a signature proves the file came from a trusted publisher or build pipeline; provenance explains where, when, and how the artifact was produced. The SLSA provenance specification defines provenance as verifiable information describing where, when, and how an artifact was produced. Sigstore Cosign supports signing, verifying, and attesting OCI artifacts and SBOMs. These capabilities can be extended to model artifact registries.

A Practical Model Artifact Admission Workflow

A production workflow should have five states:

State	Meaning
incoming	Model has been submitted or synced but cannot be loaded by any production inference service
quarantine	Model is awaiting scanning or manual review
approved	Basic scanning, source verification, and approval have passed
staging	Model can enter shadow traffic, offline evaluation, or canary environments
production	Model can be formally routed to live requests

A minimal manifest could look like this:

artifact_id: llm-model-2026-07-05-001
artifact_type: base_model
source:
  provider: huggingface
  repo: example-org/example-model
  revision: 9f4c1d2a
downloaded_at: "2026-07-05T14:59:32-04:00"
files:
  - path: model-00001-of-00004.safetensors
    sha256: "<sha256>"
    size_bytes: 4891234567
  - path: tokenizer.json
    sha256: "<sha256>"
    size_bytes: 2345678
security:
  format_policy: safetensors_preferred
  pickle_files_detected: false
  malware_scan: passed
  license_check: passed
  signature_verified: true
  provenance_verified: true
approval:
  owner: platform-ai
  reviewer: security-review
  status: approved
  expires_at: "2026-10-05T00:00:00-04:00"
deployment:
  allowed_envs:
    - staging
    - production
  rollout_policy: canary

This manifest doesn’t need to be complex from the start, but it must answer four questions: Where did this model come from? Have the files been altered? Who approved it for production? Which environments is it allowed to run in?

Admission Policy: Codify Rules as Machine-Executable Gates

Many teams document model security rules but still rely on manual judgment during deployment. A more robust approach is to hardcode these rules into CI/CD, the model registry, or the inference platform’s admission controller.

Here’s a simplified policy logic:

from dataclasses import dataclass

@dataclass
class ModelArtifact:
    artifact_id: str
    files: list[str]
    source_trusted: bool
    malware_scan: str
    signature_verified: bool
    provenance_verified: bool
    license_check: str
    approved_envs: list[str]

RISKY_EXTENSIONS = (".pkl", ".pickle", ".pt", ".pth", ".bin")

def can_deploy(artifact: ModelArtifact, target_env: str) -> tuple[bool, str]:
    if target_env not in artifact.approved_envs:
        return False, "target environment is not approved"
    if not artifact.source_trusted:
        return False, "model source is not trusted"
    if any(file.endswith(RISKY_EXTENSIONS) for file in artifact.files):
        return False, "pickle-like model files require security exception"
    if artifact.malware_scan != "passed":
        return False, "malware scan has not passed"
    if artifact.license_check != "passed":
        return False, "license check has not passed"
    if not artifact.signature_verified:
        return False, "signature is missing or invalid"
    if not artifact.provenance_verified:
        return False, "provenance is missing or invalid"
    return True, "deployment allowed"

In a real system, you don’t have to use Python. You can implement these rules in OPA/Rego, Kubernetes admission webhooks, Argo Workflows, GitHub Actions, an internal release platform, or a model registry’s approval plugin. The key is: the inference service must check the model artifact’s status before starting, not download unknown files on the fly after the container boots.

Engineering Implementation: From “Model Cache” to “Model Registry”

In production, don’t let each inference service download models from the internet on its own. A more robust pipeline is:

1. A controlled sync job pulls a specific revision from an external model source.
2. Immediately compute sha256 and write it to the manifest.
3. Run malware scanning, pickle scanning, file extension checks, and size anomaly detection on all files.
4. Set up manual exception approval for high-risk files like .bin, .pt, .pth.
5. Generate signatures and provenance for qualified artifacts.
6. Push the model artifact to an internal read-only registry or object store.
7. Inference services pull only approved versions from the internal registry.
8. During canary releases, track requests by artifact_id or model_version.
9. During incidents, trace back to source, approval, signature, and deployment scope via the manifest.

This workflow adds some pre-deployment cost but provides a much more controlled release boundary. This is especially valuable when an organization simultaneously uses open-source models, private fine-tuned models, LoRA adapters, quantized models, and multimodal models—the number of artifacts grows quickly. Without artifact governance, it’s hard to know which version is reproducible, which can be rolled back, and which has a security exception.

How Signatures, SBOMs, and Provenance Work Together

Mechanism	Purpose	Implementation Advice
Hash (sha256)	Verify file content integrity	Compute on ingestion, re-verify on deployment
Signature	Confirm file was published by a trusted identity	Use GPG signed commits or Sigstore Cosign, bound to CI/CD identity
SBOM	Describe what the artifact contains	Beyond Python dependencies, include tokenizer, adapter, quantization config, runtime image, inference framework version
Provenance	Explain how the artifact was produced	Record training job, dataset version, base model version, fine-tuning script commit, build environment, output file digest

The value of signatures and provenance extends beyond security audits to reproducibility, rollback, and compliance.

Applicable Scenarios

This approach is suitable for:

• Organizations using open-source LLMs, Embedding models, Rerankers, VLMs, or ASR models internally
• Multiple teams sharing a single model registry
• Inference platforms that allow users to upload LoRA adapters or fine-tuned models
• Models requiring multi-party approval from security, legal, compliance, and platform teams
• Production services needing version-based canary releases, rollbacks, and incident tracking
• Audit requirements to explain the source, signature, approval, and deployment scope of a specific model version

For personal experiments or short-term benchmarks, you can skip full signing/provenance, but you should at least pin the revision, verify the hash, prefer safetensors, and avoid loading untrusted pickle files.

Common Misconceptions

Misconception 1: “From a well-known platform = safe”

External platform scanning is an important defense, but not a substitute for your own production admission. Hugging Face’s documentation states that the Hub triggers file scanning on every commit and shows pickle imports, but also notes that scanning is not 100% foolproof. Organizations still need secondary admission based on their own risk boundaries.

Misconception 2: “Safetensors solves all model security problems”

Safetensors addresses one class of high-risk serialization issues. It cannot prove a model has no backdoors, that training data is compliant, or that model outputs are safe. It should be part of format admission, not the entire security solution.

Misconception 3: “Recording just the model name is enough”

A model name is a mutable reference, not an immutable proof. Production systems should record the commit, digest, signature, provenance, approval, and deployment environment. Otherwise, during incident post-mortems, it’s hard to determine exactly which file was loaded.

Misconception 4: “If scanning passes, it’s safe for full rollout”

Scanning only reduces file-level risk. Model deployment still requires offline evaluation, shadow traffic, canary releases, output safety monitoring, and rollback strategies. Supply chain gates answer “is this artifact allowed into production?”—not “is this model guaranteed to perform correctly for the business?”

Pre-Deployment Checklist

Before going live, at least confirm these items:

• Do the model, adapter, tokenizer, and config all have sha256 hashes?
• Is the external source revision pinned, not using a floating latest?
• Are safetensors preferred?
• Are pickle-like files blocked or subject to approval?
• Has malware scanning and pickle import scanning been completed?
• Have licenses and model usage restrictions been checked?
• Have signatures or signed commits been verified?
• Has provenance been generated, or at least the build source recorded?
• Has the artifact been pushed to an internal read-only registry?
• Is the inference service prohibited from downloading models from the public internet at runtime?
• Are canary releases, rollbacks, and request tracking by artifact_id in place?
• Do security exceptions have expiration dates and designated reviewers?

Conclusion

Model artifact supply chain governance is not a one-time project—it’s a continuously operating engineering mechanism. From format admission, source verification, scanning, and signatures to an internal registry, each gate reduces the risk of “not knowing what was loaded in production.” When a team manages dozens of open-source models, private fine-tuned models, LoRA adapters, and quantized variants simultaneously, the “bare loading” approach—without manifests, signatures, or admission records—will eventually become a source of operational incidents. Treating models as immutable artifacts, codifying admission rules, and binding signatures and provenance to CI/CD pipelines will pay off fully the first time you need a security-driven rollback.

---

References

• Hugging Face Hub: Pickle Scanning
• Hugging Face: Safetensors
• Hugging Face Hub: Malware Scanning
• Hugging Face Hub: Model Release Checklist
• Sigstore Cosign: Signing Other Types
• SLSA Provenance Specification
• SafePickle: Robust and Generic ML Detection of Malicious Pickle-based ML Models