Verify model files and code

Model files come from a supply chain. They are software artifacts, not magic blobs.

Prefer original publishers or established maintainers. Check the repository identity, source model, revision, license, conversion notes, and file hashes when available.

Safetensors avoids the arbitrary-code behavior of Python pickle files. GGUF stores tensors and metadata for inference. Safe data formats reduce one risk, but a model repository may also ask you to run custom code or installation scripts.

Be careful with options such as trust_remote_code. They mean you are allowing code supplied by the repository to execute. Inspect and pin that code before using it with sensitive data.

A chat template can also change behavior. A conversion that uses the wrong tokenizer or template may produce poor results even when the weight file itself is intact. Supply-chain debugging includes template mismatches, not only malware scares.

Record the artifact hash and runtime version for important deployments. If a repository changes later, you can still identify what you tested.

Community quantizations add another maintainer to the chain. Note who converted the file, from which base revision, and whether anyone reported corruption or tampering.

My advice is to treat model upgrades like dependency upgrades: diff the metadata, rerun evaluations, and keep the previous artifact until the new one proves stable.

When Ollama pulls a model, you still trust Ollama’s packaging pipeline and the upstream registry. Local inference reduces remote inference risk. It does not eliminate trust decisions.

Try this on your own project: save the output of ollama list and any published hash from the model page in your operating notes. Future upgrades start from that pinned pair.