Yes. PyTorch's security policy says in bold that PyTorch models are programs, and that running an untrusted model is equivalent to running untrusted code. It recommends sandboxes for untrusted models, safer weight formats where possible, and distributing model weights and Python code separately.
What the policy actually says
The PyTorch SECURITY file has a section called Using PyTorch Securely. Its opening line states that PyTorch models are programs, so security needs real attention. It also says none of the topics in that section are treated as vulnerabilities in PyTorch itself. They are guidance for users.
That second point matters. If a malicious model file runs code when loaded, the project treats that as expected behavior of the format, not a bug to patch. Responsibility moves to whoever loads the file.
Four ideas to take from it
- Weights and code travel separately. The policy recommends distributing model weights and the Python code for the model independently, and being careful about where the code comes from. It suggests checking provenance or checksums, and warns against running any pip installed package blindly.
- Untrusted means unknown origin. The policy defines untrusted models as those created by unknown developers or using data from unknown sources. It adds that trustworthiness is not binary, so match caution to the model and your risk tolerance.
- Use a sandbox for untrusted models. It says to prefer running them in an isolated environment such as a container or virtual machine.
- Format matters. The policy says Safetensors gives the most safety but is the most restricted in what it supports, while torch.load has a significantly larger attack surface and is more flexible.
A decision table
| Situation | Reasonable handling |
|---|---|
| Weights you trained, stored in a bucket you control | Normal loading, with access control on the bucket |
| Weights from an unknown publisher, available as Safetensors | Prefer that file, pin the revision, load in a restricted environment |
| Weights only as a pickle based checkpoint | Treat as code. Load in a sandbox with no network and no secrets, or convert there first |
| A TorchScript or mobile model file | Treat like locally executable code from an unknown source |
The policy is explicit about TorchScript: only run those models if you trust the provider. It even notes that some introspection tools may execute partial or full code stored in those models.
Turn the policy into a team rule
Write one paragraph for your engineering handbook.
- Allowed formats for weights loaded in production: name them.
- Required for anything else: sandbox, no network, no credentials in the environment, reviewed by a named person.
- Where model files may come from: an internal registry or a short list of publishers.
Then enforce it. A CI check can fail a pull request that adds a checkpoint file of a disallowed type, or a loader call that points to an external download.
git diff --name-only origin/main... | grep -E '\.(pkl|pickle|pt|pth|ckpt|bin)$'
Any match goes to a human before merge.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a gate blocks a change before it merges, which is where a file type rule belongs.
Quick check
Is a Safetensors file risk free?
No. The PyTorch policy says even safer formats can cause problems through unexpected inputs, such as denial of service, so validate what goes into the downstream system.
Does a clean marketplace scan make a model trusted?
It is one signal, not a verdict. The policy says trust is not binary, so combine it with the publisher, the format and a sandbox.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning plus policies and gates, which can flag the libraries your model loading code depends on and block risky changes in CI. A free scan shows your Python dependency tree.
Sources
- PyTorch SECURITY.md, read 19 October 2026.
Last reviewed: 19 October 2026.
