RESEARCH PERSPECTIVE · AI SUPPLY CHAIN SECURITY

AI Models as Software:
Why Secure Loading Matters

A model can introduce risk before it produces its first prediction. Evaluating that risk requires separating file provenance, loading behavior and the behavior of the deployed model.

Maurizio Viviani
October 11, 2026 · Technical perspective based on public documentation

The risk begins at loading

Python's documentation warns that malicious pickle data can cause arbitrary code execution during unpickling. A model checkpoint that relies on this mechanism therefore deserves the scrutiny applied to executable software, even if its expected purpose is to supply numerical parameters. The filename and the apparent usefulness of the model do not establish the safety of its loader. ^[1]

The practical distinction is between accepting numerical content and accepting the operations used to reconstruct it. A security review should identify which loader is invoked, which dependencies are trusted and which permissions that loading process receives. This is an assessment of the deployment environment, not a conclusion about the model's predictive quality.

Existing controls address different boundaries

Hugging Face documents a repository scan that examines imports referenced in pickle files without executing those files. The same documentation explains that the scan is not a complete guarantee of safety. Its result is useful evidence within a wider review, rather than a substitute for understanding the loading environment. ^[2]

PyTorch documents a restricted loading mode, weights_only=True, which limits the functions and classes available during unpickling and prohibits dynamic imports in that mode. PyTorch also states that this restriction does not prevent denial of service and does not rule out every memory-corruption risk. Those limits belong beside any claim about what restricted loading achieves. ^[3]

Safetensors offers a format designed for safe tensor storage as an alternative to pickle. This addresses an important serialization boundary. Its documented purpose should not be expanded into a claim that the surrounding application, its dependencies or the model's outputs have all been validated. ^[4]

Questions that should remain distinct

The following questions organize a review of these public controls. They are an analytical checklist, not a new security protocol.

Evidence for one question does not automatically answer the others. Knowing who published a file does not establish that its loading process is harmless. Likewise, a safer serialization format is not a test of whether numerical parameters produce appropriate outputs. This distinction is a consequence of the different properties the cited controls address.

A useful standard for security claims

A defensible report should name the artifact, loader and relevant environment, identify the control applied, and describe the threat it is intended to reduce. It should also state what was left outside the assessment. This makes results comparable and helps an adopter understand whether a finding applies to its own deployment.

For AI supply chains, confidence begins with precise evidence about the transition from an acquired file to a running application. Secure loading, software security and reliable model behavior each require their own justification. Treating them as separate questions produces clearer research and more useful engineering decisions.