Review local model artifacts before loading them

A local path is still a software trust boundary

Moving a downloaded model into a local folder does not make its contents trusted. A convenient loading call can read weights, select implementation code, and consume configuration; reviewing only the largest file misses part of that decision.

OWASP model operations guidance recommends checking third-party model integrity and provenance, controlling artifact access, and isolating model workloads. Start with an admission decision before loading, then separately plan any authorized runtime evaluation. The worksheet below examines invented manifest records only; no package has been downloaded or inspected.

Record the package and the intended loading path together

Create a protected inventory containing source identity, immutable revision, allowed relative paths, expected sizes, full cryptographic digests, declared purpose, and intended consumer for every file. Include tokenizer assets, configuration, shard indexes, adapters, custom code, and dependency records when present. Record who approved the baseline and how its authenticity was established.

Alongside it, record the exact loader package version, dependency lock or environment identity, entry point, custom-code setting, expected architecture, and network policy. Do not infer behavior from a filename extension. Compare the documentation and implementation for the version you would actually run before authorizing that path.

The cited Transformers loading guide is explicitly the main source documentation, not a promise about an installed release. It describes configuration-based class selection, local-directory loading, and custom models whose modeling code comes from outside Transformers. Its custom-model example uses trust_remote_code=True and a specific revision; that flag is a code-trust decision, not a routine compatibility repair.

Use a manifest-only admission matrix

Invent package Cedar-Small at revision REV-A. Its proposed inventory contains weights.safetensors, tokenizer.json, config.json, and an optional shard index. The fictional plan permits only a reviewed built-in implementation with custom repository code disabled. Labels H-W1 and H-T1 below are symbolic expected digests, not calculated hashes or downloadable artifacts.

These outcomes are invented operating rules, not findings about a repository or an executed scanner. “Eligible” is deliberately narrower than authorization to load. Missing provenance stays unknown; it does not establish that a package is malicious.

Keep data formats and executable extensions separate

The Transformers loading guide says it loads safetensors weights when available and distinguishes them from traditional pickle serialization. That documented preference does not make every surrounding tokenizer, configuration, dependency, or custom implementation trustworthy. Do not generalize one format’s properties into a guarantee for the whole loading process.

The separate customization guide shows configuration mappings and Python modeling files as part of a custom model package. A package that adds such code requires code and dependency review, even when its tensor data uses the intended format. Disabling a particular custom-code path also does not remove bugs or vulnerabilities from the installed runtime.

If loading would require relaxing an existing restriction, stop and obtain a separate review of that changed plan. Do not automatically enable remote code, broaden import permissions, or run a conversion utility merely because the first attempt would fail. This worksheet makes no version-specific PyTorch loading claim.

Verify provenance without confusing it with harmlessness

OWASP supply-chain guidance covers supplier assessment, reviewed versions, signatures, dependency inventory, and provenance. Use authenticated release information and an established trust policy to decide which producer and revision are acceptable. A digest copied from the same untrusted package cannot independently authenticate its source.

Matching bytes show consistency with the selected baseline; they do not show that the baseline is benign, licensed for the intended use, free of backdoors, or suitable for a task. A signature binds evidence to an accepted signer only under the verifier’s trust rules. Record those limits and keep behavioral evaluation as a separate stage.

Make the next step bounded and reviewable

For an authorized future evaluation, prepare a separate environment without production secrets or sensitive data, with restricted network access and explicit resource limits. Preserve the admitted artifact set against replacement between verification and use. Environment isolation reduces exposure; it is not proof that arbitrary code is safe.

Before that stage, propose a harmless worksheet check: have a second reviewer apply the matrix to invented inventories, including the acceptable baseline, changed digest, missing shard, and changed loader. Record expected decisions and disagreements. Do not create an executable payload or deserialize an unknown checkpoint to demonstrate the rule.

All admission and verification checks here are UNRUN. No downloads, installations, model loading, deserialization, model API calls, or artifact code execution occurred. Boundary is a prelaunch commercial model router with planned request-path policies; this article does not describe a shipped model scanner, local runtime sandbox, or artifact admission service.