Before You Load Model Weights, Verify the Whole Bundle

A checkpoint arrives with a plausible model card, familiar file extensions and a checksum. An engineer downloads it into a notebook, runs the suggested loading command and plans to review its behaviour afterwards. The security decision has already happened: the loader may have reconstructed executable objects, imported repository code or invoked a native runtime before the model produces its first answer.

The decision to make earlier is whether this exact bundle may be interpreted by this exact loader, inside this exact environment. A model name is too broad an approval target. Weights, architecture code, tokenizer, adapters, configuration, conversion tools and dependencies can each change what the machine will execute.

This guide covers teams acquiring and serving model artefacts themselves, including internal fine-tunes and community conversions. Hosted API customers have a different acquisition boundary. The source documents establish the mechanisms and verification semantics; the admission record and operating controls below are AIEngine's engineering synthesis. They provide an actionable review process, not a certification that a model is harmless.

Loading is the first execution boundary

Serialization turns in-memory objects into stored bytes. Deserialization reconstructs them. For some formats that reconstruction can include calling functions, which means the file is effectively a set of instructions to the loader.

Python's pickle documentation explicitly warns that malicious pickle data can execute arbitrary code during unpickling. Opening such a file to inspect its contents with an ordinary deserializer can therefore trigger the very behaviour the inspection is meant to assess. A renamed extension does not alter those semantics.

PyTorch's security policy similarly treats untrusted models as untrusted code. It recommends separating model weights from Python code and using isolation for untrusted models. It also warns that TorchScript inspection utilities may execute stored code. An operation called inspect, preview or convert is not automatically read-only in the security sense.

Move the first load out of a developer's everyday environment. That environment often contains repository credentials, cloud sessions, private datasets and writable package caches. Successful inference is weak evidence about what else happened during initialisation.

Classify everything the loader can reach

Ask for the complete inference bundle and its loading procedure. Start by listing files without executing repository scripts. Bound archive extraction by total size, nesting and permitted paths; reject path traversal and unexpected links. Static parsing and scanning tools need maintained versions and resource limits too.

Do not approve the largest file and leave the smaller ones floating. A tokenizer change can alter interpretation even when weight hashes match. An adapter requires a compatible base, while a configuration can redirect loading to code outside the apparent package.

The AI dependency inventory records where these components are deployed. Admission adds the preceding evidence: why this particular combination was permitted to run. Rights to use and redistribute remain a separate prerequisite, covered in the open-weight licence guide.

Verify identity against expectations you already trust

A digest answers whether two byte sequences match. It does not establish that either sequence came from the intended producer. If an attacker can replace both a download and the checksum beside it, comparing them can succeed perfectly.

Obtain expected identities through a controlled source. Preserve the canonical repository, immutable revision, individual file digests and any producer signature or attestation. A mutable branch name or release label is useful for discovery; resolve it to the exact material evaluated before promotion.

SLSA's artifact-verification guidance calls for verifying the provenance signature, matching its subject to the artifact digest and checking expectations such as builder identity, canonical source repository, build type and external parameters. The consumer must define those expectations; accepting whatever a supplied manifest says defeats the comparison.

When a producer supplies Sigstore signatures, Cosign verification supports checking a file's signature bundle against an expected certificate identity and OpenID Connect issuer. A signature from an unexpected identity should fail the producer policy even if the mathematics verifies. Avoid broad identity patterns merely to make a check pass.

Record missing provenance as missing. An internal signature can attest that your team admitted or converted a bundle; it cannot retroactively prove the original producer's training process. Equally, authentic provenance does not establish that the model's training data, behaviour or licence is suitable for the intended use.

Prefer constrained formats without making them trust certificates

Hugging Face describes Safetensors as a format for storing tensors safely compared with pickle. Prefer a tensor-only representation when the selected architecture and tooling support it. Separating numerical state from executable model definitions makes the code being authorised easier to identify and review.

The narrower format does not make the surrounding application trustworthy. Custom modelling code, native kernels, parsers and downstream operations still execute. Resource exhaustion, unexpected tensor shapes, incompatible configuration and malicious model behaviour also require controls outside the file format. The reviewed loader and application remain part of the admission decision.

PyTorch's serialization notes describe how weights_only=True restricts loading to a narrower set of tensor-related objects and prevents dynamic imports during unpickling. They also document limitations, including denial of service and possible memory corruption. Starting with version 2.6, the default changes to weights_only=True when pickle_module is not supplied; callers and wrappers can still alter the effective behaviour.

The April 2025 PyTorch advisory for CVE-2025-32434 is a concrete warning against trusting a flag without its implementation version. It documented remote code execution despite weights_only=True in versions through 2.5.1, patched in 2.6.0. That historical fix is not a recommendation to install an old release today: check current advisories and the maintained version actually deployed.

If a restricted load fails, record why. Do not automatically retry with unrestricted deserialization or approve every reported global. A compatibility error may require trusted code review, a different artefact or rejection. Make that escalation visible in the release record.

Treat custom code as a software acquisition

Hugging Face's model-loading documentation explains that custom models use code outside Transformers, require trust_remote_code=True to load through that path, and should be pinned to a specific revision. The same documentation cautions that repository malware scanning does not remove the need for care.

Treat the flag as permission to execute that reviewed code, not as a repair for an inconvenient loading error. Resolve any separately referenced code repository too. Pinning freezes a choice; reviewing the choice determines whether it is acceptable.

For code that is necessary, review import-time actions, file access, subprocess use, dynamic downloads, telemetry, package installation and native extension builds. Prefer bringing approved code into the ordinary dependency and build process. If a standard architecture implementation can load the same verified tensors, that can reduce the amount of newly acquired code, but confirm compatibility through evaluation.

Separate the downloader from the evaluator. The downloader may need narrowly scoped access to an approved repository; the evaluator normally needs only the downloaded material and benign test inputs. Remove acquisition credentials before executing the bundle, and deny access to production services, host mounts and shared writable caches. Apply the containment choices in the agent sandbox guide to the loader process as well as the eventual inference workload.

Conversion creates a second artefact and a second trust decision

Converting a checkpoint into a safer output format does not make opening the original safe. A converter may need to deserialize it first. Hugging Face's conversion documentation describes a service that downloads pickled weights, converts them and proposes the resulting files in a pull request. That workflow illustrates the transformation boundary; it does not establish the provenance of every independently uploaded conversion.

Run an approved conversion in a disposable, restricted environment with no sensitive inputs or production credentials. Give it read-only access to the candidate and a bounded output location. Record the original digests, converter code and runtime versions, transformation parameters, output digests and execution result.

Then validate the output independently. Check that tensor names, shapes, counts and data types fit the declared architecture, that all required shards resolve, and that unexpected files have not appeared. For a transformation intended to preserve numerical values, define the comparison that establishes preservation. For quantisation, which intentionally changes values, set quality and numerical-tolerance criteria appropriate to the application.

Do not promote the converter's whole working directory. Export only the expected outputs, recheck their digests and create a separate admission decision for the resulting bundle. If the conversion runtime was compromised, its output and its own claims may both be untrustworthy; isolation limits exposure but does not prove correctness.

Work through a community checkpoint request

Consider a hypothetical team evaluating a community reranker for an internal document search service. The repository supplies Safetensors weights, configuration, a tokenizer, a Python modelling file and a performance claim. This is a design exercise, not an AIEngine deployment or a measured result.

The initial request asks to load the repository with custom-code trust enabled. The admission reviewer resolves its revision and discovers that the configuration selects the accompanying Python class. The weight format therefore answers only one part of the review.

The team can now make a concrete choice:

• use a supported implementation if it represents the same architecture and passes equivalence checks;
• review and package the required custom code, including its dependencies; or
• reject the candidate if its provenance or execution requirements cannot be justified.

Suppose the reviewed code is accepted for isolated evaluation. The team tests loading, basic reranking and the expected resource envelope with benign data, then evaluates retrieval quality on an authorised dataset under the same permitted runtime. It records the complete bundle and runtime digest as the candidate baseline. The model change-control guide then governs promotion and rollback.

Production starts from an internal immutable copy. It verifies the approved file set before loading and has no fallback that silently fetches a newer revision when a file is absent. A new tokenizer, converter output or loader version reopens the relevant admission evidence even if the model's display name stays the same.

Test refusal and revocation, not only successful loading

A useful admission gate must demonstrate that it can reject the wrong material. Exercise it with benign test fixtures representing failures, without running unknown exploit samples in the ordinary build environment:

• alter a byte after approval and confirm the digest mismatch blocks loading;
• present a valid signature from the wrong identity and confirm policy rejection;
• replace the expected source or builder in an attestation and require failure;
• add an undeclared shard, code file or dependency and stop promotion;
• remove a required file and confirm there is no network fallback;
• request a disallowed custom loader and verify that no import occurs;
• attempt writes to shared caches and access to acquisition credentials; and
• revoke an admitted digest and confirm new replicas cannot load it.

Protect the interval between verification and use. Store approved material under immutable identities with controlled write access, and verify the actual deployment copy. A pathname that other processes can overwrite is an inadequate link between yesterday's review and today's load.

Measure the share of active bundles with complete file and runtime identities, the number of unresolved custom-code exceptions, time to identify deployments affected by a loader advisory, and time to prevent a revoked bundle from starting. Audit which already-running replicas need termination or replacement; blocking future loads does not unload a model already in memory.

The durable approval record names the bytes, their origin, the permitted interpreter, the environment and the evidence supporting the decision. Revisit it whenever one changes. That gives the team a defensible answer before loading begins, while preserving a separate obligation to evaluate what the admitted model actually does.