Only when there is no viable alternative and the input source is fully controlled, signed, and tightly isolated. For most production uses, inert formats are safer because they separate data from executable behaviour. Where object serialisation remains necessary, load paths should be sandboxed and treated like privileged code.
Why model-loading format matters in production
Pickle and cloudpickle are not just storage formats, they are code-capable serialisation mechanisms. That means loading an untrusted object can execute attacker-controlled behaviour during deserialisation, which makes the loading boundary part of your trusted computing base. For production model serving, the safer default is an inert format that preserves weights or tensors without rehydrating arbitrary Python objects.
The practical question is not whether a format is convenient, it is whether the loader can be forced to execute code, reach the network, touch the filesystem, or import unexpected modules. If the answer is yes, then the model artifact must be treated as executable content and gated accordingly. That is especially important when artifacts move across teams, environments, registries, or pipelines.
For a secure loading pattern, teams should separate the model payload from any runtime logic and make provenance verifiable before deployment. AI Supply Chain Security and AI-BOM Guide is useful here because model provenance, artifact integrity, and credential containment are the controls that decide whether the loader boundary can be trusted at all.
When pickle or cloudpickle creates unacceptable blast radius
In production, the main failure mode is not “bad predictions”, it is deserialisation abuse. A malicious or tampered pickle payload can trigger imports, object construction hooks, or other Python-level side effects before the model is even available to the application. Cloudpickle expands flexibility for dynamic Python objects, which can also expand the attack surface when teams use it to persist complex runtime state they do not fully understand.
This becomes especially dangerous when the artifact is retrieved from a shared bucket, artifact registry, notebook export, or external source where trust is assumed rather than enforced. If the source is not fully controlled, signed, and isolated, then the loader is effectively running privileged code on behalf of the artifact. That is why the safer operational answer is to prefer formats designed for data-only loading whenever the model architecture allows it.
Where serialisation cannot be avoided, the surrounding control environment matters as much as the file itself. The load path should be sandboxed, the runtime should have tightly scoped filesystem and network permissions, and the artifact should be treated as a sensitive supply-chain input rather than a passive blob.
Safer production pattern for model loading
A practical production standard is to choose the least expressive format that still preserves what the application needs. If the deployment only needs weights, tensors, or structured parameters, use a format that does not reconstruct arbitrary Python objects. Reserve pickle or cloudpickle for narrow cases where you own the full producer and consumer stack and have explicit controls around signing, validation, and isolation.
When teams do need Python object rehydration, the load boundary should be reviewed like any other privileged execution path. The host should not be able to fetch new code during load, the artifact source should be immutable, and the deployment process should verify that the exact artifact expected by the pipeline is the one actually loaded. That framing usually shifts the decision away from “which serializer is easier” toward “which serializer creates the smallest trusted surface”.
In broader supply-chain terms, the safest pattern is to keep executable behaviour in reviewed application code and keep the model artifact as data. That separation reduces the chance that a seemingly routine model refresh becomes a code execution event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Pickle loading can execute code if artifacts are tampered with. |
| Recommendation — Prefer inert model formats and sign artifacts before deserialisation. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Model files are supply-chain artifacts that need provenance and integrity. |
| Recommendation — Require provenance and integrity checks before loading production artifacts. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Production loaders should only accept approved model artifacts and dependencies. |
| Recommendation — Maintain an approved inventory of model artifacts and block unvetted loads. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Signed, verified artifacts reduce the risk of loading altered model files. |
| AC-6 — Least Privilege | Sandboxed loading depends on constraining what the deserialiser can access. | |
| Recommendation — Verify artifact integrity before deserialisation and deployment. Run loaders with least privilege and minimal host access. | ||
Practitioner Guidance
What to prioritise: Treat any pickle or cloudpickle load in production as a security decision, not a data-format decision. If the artifact can come from outside a tightly controlled build-and-sign pipeline, do not rely on Python deserialisation for trust.
What to verify: Confirm that the exact artifact is signed or otherwise integrity-protected, that the loader runs in a constrained environment, and that the process does not have unnecessary filesystem, network, or import reach. If those checks cannot be enforced, the format is too risky for production use.
Practitioner takeaway: The right default is to avoid executable serialisation where possible and to make any unavoidable deserialisation behave like privileged software delivery, with provenance, isolation, and least privilege all enforced together.
Related resources from NHI Mgmt Group
- How do IAM teams decide whether a brokered login model is safe for production use?
- How should teams use SHAP in production model governance?
- How do teams decide whether model-assisted review is good enough for production use?
- How do security and ML teams decide which drift metric to use for a production model?