The Artifact Threat Model: What a Downloaded Checkpoint Can Do at Load Time

The most normalized dangerous operation in machine learning is loading a model. A developer finds a checkpoint on a hub, calls a load function, and a file authored by a stranger becomes part of their running process — often with no more scrutiny than a copy-paste. The comfortable assumption is that a model file is just weights, a big array of numbers. For some formats that is true; for others it is dangerously false, because the file format can encode instructions that run when the file is loaded. Even for safe formats, the checkpoint is a dependency you pulled from the internet and are about to trust with your process, your data, and your users. The artifact threat model asks the question that single load call skips: what can this file do to me?

A checkpoint is a software dependency

The foundational reframing is that a model checkpoint is not data you consume but a dependency you execute against, with the same supply-chain risks as any library you import. Gu and colleagues framed the machine-learning supply chain as an attack surface for exactly this reason: the artifacts flowing through it — datasets, and here checkpoints — can carry attacker intent that activates in the consumer's environment. A checkpoint pulled from a hub is analogous to a package pulled from a registry, and the security lessons of software supply chains apply directly.

This matters because the tooling makes loading frictionless and the risk invisible. A load call abstracts away what the format actually does on load, so a developer cannot see whether they are deserializing trusted numbers or executing untrusted code. NIST's supply-chain guidance (SP 800-161) and secure-development framework (SP 800-218) exist because this invisibility is where supply-chain compromise thrives — the consumer trusts the artifact by default and never verifies the chain that produced it.

The defensive stance that follows is to treat every checkpoint as an untrusted dependency until proven otherwise: know its origin, verify its integrity and authenticity, load it with a format that cannot execute code, and sandbox the load. The rest of this article develops the trust chain that makes each of those checks meaningful.

The load-time attack surface

The sharpest risk is that loading a checkpoint can execute code. Some widely-used serialization formats embed not just data but instructions for reconstructing objects, and reconstructing those objects runs code chosen by whoever wrote the file. A malicious checkpoint in such a format can therefore carry a payload that executes the moment it is loaded, in the process and with the privileges of the loader — before the model is ever used for inference. This is not a model-behavior attack; it is straightforward remote code execution delivered through a file that looks like weights.

The consequence is that the load step, not the inference step, is the first and often most severe attack surface. An attacker who gets a developer or a pipeline to load their checkpoint can run arbitrary code: exfiltrate secrets and data, install persistence, pivot into the network, or tamper with the environment. Because loading happens early and automatically in many pipelines (a CI job pulls a model, a serving process loads it on startup), the payload runs in privileged, trusted contexts.

The primary defense is to eliminate the code-execution path by using serialization formats that carry only data and cannot execute code on load — the safetensors format was designed precisely for this, storing tensors without any object-reconstruction mechanism. Preferring such formats converts the load step from a code-execution surface into a pure data read, removing the most dangerous class of artifact attack at its root.

Beyond code execution: the whole artifact

Even with a safe format, the checkpoint is more than tensors. It travels with configuration, tokenizer files, and metadata, and a loader often trusts all of it. A malicious or tampered config can set unsafe defaults, point the loader at attacker-controlled resources, or enable code paths the developer did not intend. The weights themselves may be backdoored (the data-poisoning threat model), carrying hidden behavior that activates on a trigger even though the file executed nothing on load. The artifact is a bundle, and each part is a potential vector.

This broadens the threat model from a single code-execution bug to the integrity of the whole package. A safe format removes the load-time code path but does not vouch for the weights being unbackdoored, the config being benign, or the tokenizer being untampered. So verifying the artifact means verifying the whole bundle's authenticity and integrity — that it is the exact, unaltered artifact a trusted author published — not merely that its format is safe.

The defense is authenticity and integrity across the bundle: cryptographic signatures over the whole artifact so tampering is detectable, provenance attesting who built it and how, and validation of config and tokenizer against expected values. This is the same supply-chain integrity model applied to every file the checkpoint brings, not just the weights.

The trust chain from hub to process

To verify an artifact you must reason about the chain it traveled. It starts with the author, who may be malicious or whose account may be compromised. It passes through a hub, which distributes it and may or may not authenticate the publisher. It is downloaded into your environment, where a transport or a name-resolution error could substitute a different artifact. And it is loaded by your process, which by default trusts whatever bytes it received. Each hop is a place the artifact you get can differ from the artifact you intended.

Naming the chain turns verification into concrete checks: authenticate the publisher (is this really the author you trust?), verify integrity in transit and at rest (is this the exact bytes they published?), pin the identity and version (are you loading the artifact you meant, not a same-named impostor?), and load safely and sandboxed (if any check is wrong, can the artifact still not harm you?). NIST's SSDF and supply-chain practices formalize these into levels of assurance that model artifacts can adopt.

The unifying principle is that trust must be established, not assumed, at each hop. The default pipeline assumes the author is honest, the hub is faithful, the download is intact, and the load is safe — four assumptions an attacker needs only one of to break. Verifying each converts a chain of assumptions into a chain of checks.

Defending the artifact

The controls compose into a safe model-loading pipeline. Prefer data-only formats so loading cannot execute code. Verify a cryptographic signature over the whole artifact against a trusted publisher key so tampering and impostors are caught. Pin the exact artifact identity and version so a same-named substitute is rejected. Load in a sandboxed, least-privilege environment so that even if a check is bypassed or a code-executing format is unavoidable, the blast radius is contained. And behaviorally test the model for backdoors before trusting it, since a safe load does not guarantee safe weights.

The unifying principle is that a model artifact is a software dependency and deserves the same supply-chain rigor: known provenance, verified integrity, pinned versions, safe deserialization, and sandboxed execution. None of these is exotic — they are the standard defenses for untrusted dependencies — but they are routinely skipped for model files because the tooling makes loading feel like reading data rather than importing code. Applying them closes the artifact attack surface.

The synthesis, grounded in Gu and colleagues and NIST's supply-chain and secure-development guidance, is that loading an unverified checkpoint can hand an attacker code execution or a backdoored model, so the artifact must be treated as untrusted until authenticated, verified, safely loaded, and sandboxed. The single frictionless load call is the operation to distrust; wrapping it in supply-chain verification is what makes downloading a model as safe as it feels.

Why this matters for agents

Agent stacks pull models constantly — a base model, adapters, embedding models, rerankers — often automatically in CI or at service startup, and each is an artifact loaded into a privileged process. If any is a malicious checkpoint in a code-executing format, or a tampered bundle from a compromised publisher, the agent's infrastructure is compromised at load time, before the agent does anything. The autonomy and integration of agent systems means a single unverified model load can expose credentials, data stores, and tool access.

The organizing lesson is that model provenance and safe loading are infrastructure security, not model quality. An agent team must treat every checkpoint as an untrusted dependency: pull only from authenticated publishers, verify signatures and pin versions, prefer data-only formats, sandbox the load, and test for backdoors. Gu and colleagues' framing of the model supply chain and NIST's supply-chain practices say the same thing to agent builders as to any software team — the artifact you download and load is code you are trusting, so verify it before you run it.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

model_artifact_policy:
  format:
    prefer: data_only        # e.g. safetensors
    code_executing_formats: forbidden_from_untrusted
  integrity:
    signature_verification: required
    trusted_publisher_keys: pinned
    version_pinning: exact
  loading:
    sandbox: least_privilege
    network_egress: deny_by_default
  validation:
    config_tokenizer_checks: required
    backdoor_behavioral_test: required

# DEFENSIVE PRE-CHECK — never load until these pass
function safe_to_load(artifact):
    assert format_is_data_only(artifact), "code-executing format"
    assert verify_signature(artifact, trusted_keys), "bad signature"
    assert pinned_version_matches(artifact), "version mismatch"
    validate_config_and_tokenizer(artifact)
    return True
# Only then load, and do it in a sandbox with egress denied.

Glossary

Checkpoint

A serialized model artifact (weights plus associated files) downloaded and loaded to run a model.

Load-time attack surface

The risk that loading a checkpoint executes code or trusts tampered configuration before any inference.

Deserialization

Reconstructing objects from a serialized file; in some formats this runs code chosen by the file's author.

safetensors

A serialization format that stores tensors as pure data with no code-execution path on load.

Trust chain

The sequence author to hub to download to load, each hop a place the received artifact can differ from the intended one.

Provenance

Authenticated metadata attesting who built an artifact and how, enabling verification of its origin.

Artifact bundle

The full set of files a checkpoint carries — weights, config, tokenizer, metadata — each a potential vector.

Sandboxed load

Loading a checkpoint in a least-privilege, isolated environment so a malicious artifact's impact is contained.

References

1. Gu et al., BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain (arXiv 1708.06733)
2. NIST SP 800-218, Secure Software Development Framework (SSDF)
3. NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
4. NIST AI 100-2 e2023, Adversarial Machine Learning: A Taxonomy and Terminology
5. safetensors format specification (Hugging Face)
6. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)