Join our Newsletter — 33% off our NHI Course

What breaks when machine learning model files are treated as safe to deserialize by default?

When model files are deserialized without controls, the trust boundary collapses at load time. Attackers can abuse pickle style reconstruction, embed code execution paths, or hide payloads in tensor data that survives basic scanning. The result is that malware can execute during model loading, before security tools and operators have a chance to inspect runtime behaviour.

What actually breaks at load time

The core failure is that the file is no longer just data, it becomes executable trust material. If a model format supports object reconstruction, dynamic imports, or custom deserialisation hooks, then loading can trigger behaviour before the model is even used. That means integrity checks, sandboxing, and runtime policy all need to happen before deserialisation, not after.

This is why “safe by default” matters so much for model artefacts. Treating them as inert blobs encourages teams to skip provenance checks, assume the file is passive, and allow a loader to execute logic with the privileges of the training or inference process. Once that happens, the attack surface shifts from model behaviour to the loading path itself.

For practitioners, the important distinction is between format parsing and object recovery. A parser that reads tensors is one thing; a deserialiser that can rebuild arbitrary objects, invoke constructors, or hydrate embedded code paths is another. When the latter is enabled implicitly, the trust boundary fails at the point most teams least expect it.

Why this becomes a supply-chain and code-execution problem

Model files are often shared across repositories, notebooks, CI pipelines, and internal registries, so a malicious artefact can enter the environment through what looks like normal ML distribution. In practice, that makes the load step a supply-chain choke point. A single unsafe deserialisation path can turn model import into remote code execution, credential exposure, or lateral movement inside the ML platform.

Hidden payloads are especially dangerous because they can survive simplistic scanning. A file may look like a valid tensor bundle or checkpoint while still carrying reconstruction logic, embedded object graphs, or payloads that activate only when a specific loader is used. That means defenders need to care about the loader, the format, and the source chain together, not just the model contents in isolation.

This is also where provenance becomes operationally important. A trusted team, trusted storage bucket, or trusted notebook does not make a file safe to deserialize. The question is whether the artefact was produced in a format that can safely be consumed without executing attacker-controlled logic. If not, the file must be handled as untrusted code-adjacent input.

Risk and Threat Considerations

Unsafe model deserialisation creates a high-confidence execution path for attackers because the compromise happens before the model reaches normal inspection, logging, or runtime policy enforcement. The practical risk is not limited to one malicious checkpoint, it is the ability to turn routine model loading into an initial access and execution mechanism.

Failure mechanism: A loader that reconstructs objects, invokes hooks, or trusts embedded metadata gives attacker-controlled content a way to execute during deserialisation, before later controls can intervene.

Impact: The result can include code execution, secret theft, poisoning of the inference environment, and compromise of surrounding CI, notebook, or deployment systems that handle the artefact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1059 — Command and Scripting Interpreter Unsafe deserialisation can hand attackers an execution path during load.
Recommendation — Restrict loaders so untrusted model artefacts cannot reach execution-capable code paths.
CIS Controls v8 8 — Audit Log Management Model loading needs auditability to detect suspicious artefact execution and provenance abuse.
10 — Malware Defenses Malicious payloads can hide inside model artefacts and activate at load time.
Recommendation — Log model import and deserialisation events so anomalous loads are traceable. Scan and quarantine model files before they reach deserialisation workflows.
NIST CSF 2.0 PR.DS — Data Security Model artefacts need protection from unsafe handling and tampering before use.
PR.PT — Protective Technology Safe loaders and isolation are protective technologies for blocking load-time execution.
Recommendation — Classify model files as sensitive artefacts and enforce safe handling controls. Use protected loading environments and restricted deserialisers for model artefacts.
OWASP Agentic AI Top 10 A5 — Supply Chain Vulnerabilities Model files distributed through pipelines behave like supply-chain artefacts with hidden payload risk.
Recommendation — Verify model provenance and reject artefacts that require unsafe deserialisation.

Practitioner Guidance

What to verify: Confirm that every model format in use has a documented safe-loading path, and that default loader behaviour does not permit arbitrary object reconstruction. If the framework requires a special safe mode or restricted format, make that the only approved path for untrusted artefacts.

What practitioners underestimate: Teams often focus on model accuracy, provenance labels, or virus scanning, but those do not neutralise loader semantics. If the deserialiser can execute logic, the critical control is the loading mechanism itself, followed by format restriction and isolation of the process that performs the load.

Practitioner takeaway: Treat model deserialisation as an execution boundary, not a file-read operation, and require a loader design that prevents attacker-controlled reconstruction from ever reaching application privilege.