Yes, in the sense that matters for security. TensorFlow's security policy says models are expressed as programs that TensorFlow executes, so using untrusted models or graphs is equivalent to running untrusted code. If you must run one, the guidance is to do it inside a sandbox.
Why a model is more than numbers
It is tempting to picture a model as a table of weights. A saved TensorFlow model also describes a computation graph: a set of operations, wired together, that the runtime carries out. An operation can read files, call other operations and in some cases reach outside the process.
That is the reason the project's guidance puts models in the same bucket as scripts. PyTorch's security policy uses almost the same sentence, saying running untrusted models is equivalent to running untrusted code and recommending a secure, isolated environment such as a sandbox.
What this changes in practice
| Old habit | Better habit |
|---|---|
| Download a model, load it on a dev laptop | Load unknown models in a throwaway container |
| Run inference with the service account that has cloud access | Give the inference process no credentials it does not need |
| Treat model files as data in storage | Track them as artifacts with source and hash |
| Review packages, skip models | Review both |
What a sandbox should look like
A sandbox for model evaluation does not need to be fancy. The goal is to limit what a malicious or buggy model can reach.
- A container or VM that is destroyed after use.
- No mounted home directory. Copy in only the model and test data.
- No cloud credentials and no access to the metadata service.
- Restricted network. Block outbound traffic unless the test needs it.
- Resource limits on CPU, memory and runtime so a bad model cannot stall the host.
- A non-root user inside the container.
docker run --rm --network none --read-only \
-v "$PWD/model:/model:ro" my-eval-image python eval.py
That example is a starting point. Adjust it for your runtime and your risk.
The multi-tenant case
The TensorFlow guidance calls out the scenario where a service runs models supplied by different users. In that case it recommends sandboxing the model execution. If your platform lets customers upload models, this is the control that decides whether one customer's model can touch another's data.
Do not forget the packages
Isolation handles the model. The environment around it still has packages with their own advisories, including the framework itself. Keep an inventory and update on a schedule. See our guide to dependency risk in ML projects for a starting method.
Where Safeguard fits
Safeguard provides SBOM generation and dependency scanning for the packages in your ML stack, plus reachability analysis and policy gates in pull requests. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a model from a well known source exempt from this advice?
The guidance is about untrusted models. A known source with a verified origin lowers the risk, but a sandbox is cheap insurance for first time loads.
Does a sandbox replace dependency updates?
No. It limits the damage from one class of problem. You still need to patch the framework and libraries.
Sources
Last reviewed: 19 October 2026.
