Safe-only loading is a deserialization policy that limits object reconstruction to the minimum necessary data, usually weights or other constrained structures. It reduces the chance that a serialized file can instantiate arbitrary code paths inside a privileged process.
What Safe-Only Loading Changes
Safe-only loading narrows deserialization so the loader reconstructs only constrained, expected structures, rather than allowing a serialized file to instantiate broad object graphs or trigger arbitrary code paths inside a privileged runtime.
The practical shift is from “recreate whatever the file describes” to “recreate only what the application truly needs.” That makes the loading step less expressive, but also far less dangerous when the input is untrusted, malformed, or attacker-influenced.
Why the Policy Exists
Serialization formats are convenient because they preserve state, but that convenience becomes a liability when the format can encode executable behavior, gadget chains, or privileged object construction. Safe-only loading reduces the attack surface by refusing to treat deserialized content as a general object factory.
That matters most in systems where the parser, model loader, or application runtime runs with elevated privileges, has filesystem or network reach, or sits close to secrets, internal APIs, or orchestration controls. Restricting reconstruction to weights, tensors, or similarly bounded data structures prevents the file from carrying more authority than the application intended.
How Safe-Only Loading Is Implemented
In practice, safe-only loading is a policy decision enforced by the loader, the file format, or both. The loader may require an explicit allowlist of types, prohibit custom class resolution, disallow dynamic imports, or limit deserialization to primitive containers and pre-approved tensor-like objects.
The most robust implementations make the safe path the default and require a deliberate opt-in for any richer reconstruction. That design avoids relying on reviewers to spot dangerous code paths later, because the unsafe behavior never becomes available in the first place.
Safe-only loading is also a useful boundary for supply-chain hygiene. If a model artifact, checkpoint, or serialized bundle cannot express executable behavior, then downstream validation is simpler and the consuming application can treat the input more like data than code.
Where the Security Value Is Highest
The strongest benefits appear in environments that ingest third-party artifacts, reuse models from external sources, or load files into services that have access to internal networks, credentials, or production data. In those settings, deserialization is not just a convenience layer, it is a trust boundary.
Safe-only loading does not make serialization harmless, but it removes a common path from untrusted content to code execution. It also reduces the chance that a future library update or hidden object hook reintroduces dangerous behavior through a format that looked purely data-driven.
Teams that already rely on platform controls can pair this policy with stronger provenance and integrity checks. For example, source integrity and build provenance controls help establish where the artifact came from, while safe-only loading helps limit what the artifact can do when it is consumed. The same discipline is useful when model supply chain controls and artifact integrity matter, as reflected in SLSA and in broader software assurance practices such as OWASP SAMM.
Risk and Threat Considerations
Unsafe deserialization can turn a file into an execution vehicle, especially when the loader resolves arbitrary classes, invokes hooks, or accepts attacker-controlled object graphs. That is why safe-only loading is often treated as a control against code execution, privilege abuse, and malicious artifact handling.
Failure mechanism: A crafted serialized input exploits permissive object reconstruction, allowing gadget chains, constructor side effects, or unexpected method calls to run inside the consuming process.
Impact: The result can include remote code execution, data exposure, lateral movement, or compromise of a privileged application that trusted the file too much.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Integrity | Safe-only loading reduces artifact execution risk in model and software supply chains. |
| Recommendation — Require provenance checks before consuming serialized artifacts. | ||
| OWASP SAMM | Secure Build and Delivery Practices | Deserialization policy is part of secure software delivery and artifact handling. |
| Recommendation — Build secure loading rules into your delivery lifecycle. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Safe-only loading constrains untrusted serialized input before it is interpreted. |
| Recommendation — Validate and restrict deserialized input before object reconstruction. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Serialized artifacts often need integrity and controlled handling alongside secure processing. |
| Recommendation — Protect serialized artifacts with integrity and controlled handling rules. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Safe loading depends on knowing which deserializers and artifact types are permitted. |
| Recommendation — Inventory deserializers and restrict approved artifact formats. | ||
Practitioner Guidance
Why practitioners should care: Safe-only loading is one of those controls that should be treated as a default safety boundary, not an optional hardening step. If your systems load models, checkpoints, or other serialized artifacts from outside the immediate trust boundary, the loader policy becomes part of your security posture.
What to watch for: The main warning sign is any deserialization path that can reconstruct application objects, import modules, or execute callbacks as a side effect of loading. Those paths deserve the same scrutiny you would give to a parser that can execute code.
Practitioner takeaway: Prefer loaders that only accept constrained data structures, and reserve richer deserialization for narrowly controlled cases with explicit review.
Related resources from NHI Mgmt Group
- How can security teams tell whether Keras model loading is actually safe?
- How can security teams tell whether a module-loading path is still safe?
- How should security teams decide whether JIT access is safe for non-human identities?
- What is the difference between short-lived access and safe access for non-human identities?