Model files can execute code at load time through deserialization, custom operators, or embedded payloads. That means the compromise can happen before an application starts, bypassing runtime defenses entirely. Risk rises when teams pull from public registries, trust third-party checkpoints, or assume model artifacts are passive inputs.
Why Model Files Are a Supply-Chain Control Problem, Not Just a Training Artifact
Model files are more risky than many teams expect because they are not always inert data. In practice, a checkpoint or serialized model can carry executable behaviour through deserialisation, custom operators, graph hooks, or bundled assets that influence load time. That shifts the question from “is the model accurate?” to “what does importing this artifact cause the environment to trust, execute, or expose?”
For AI supply chains, that matters because the highest-risk moment is often ingestion, not inference. A team may harden prompts, runtime APIs, and user-facing controls while leaving model acquisition, validation, and provenance checks far looser. Public registries and third-party checkpoints increase the chance that the organisation imports unreviewed code paths, unexpected dependencies, or hidden logic into build and deployment workflows. The relevant comparison is not with ordinary input files, but with software packages that can alter system behaviour before the application fully starts. In practice, many security teams discover that model files behave less like content and more like unvetted software components after they have already been promoted into a trusted pipeline.
For a current governance lens on AI risk and control expectations, NIST’s NIST IR 8596 Cyber AI Profile is a useful reference point because it frames AI as an environment where supply-chain integrity and control assurance both matter.
How Model Artefacts Behave in Real Pipelines
In practice, model risk begins with how the artifact is packaged and loaded. Some formats are simple weight containers, but others rely on serialisation mechanisms that can reconstruct objects, invoke helper functions, or trigger custom logic when the file is opened. The security issue is not limited to malicious intent. A benign-looking file can still create operational exposure if the loading process assumes trusted structure, auto-installs dependencies, or resolves code from external locations.
That is why model supply chains should be treated as a chain of trust with multiple handoffs: source, conversion, signing or validation, storage, retrieval, and load. Each step can introduce a different failure mode. A model downloaded from a registry may be legitimate but still bring in unsupported operators or hidden dependency requirements. A model converted from one framework to another may inherit unsafe parsing behaviour. A model embedded in a larger application may appear passive while still affecting startup behaviour, memory layout, or execution hooks.
- Repository trust is only the first control point. Provenance is useful, but it does not replace artifact inspection.
- Serialization format matters. Some formats are designed to restore objects, not just weights.
- Conversion tools can become the weakest link when they silently accept unsupported or unsafe structures.
- Runtime protection helps after load, but load-time abuse can happen before those controls engage.
Organisations should also distinguish between model integrity and environment integrity. A model can be mathematically valid and still be operationally unsafe if it reaches into file systems, package managers, or custom extensions during initialization. That is why model review needs to include dependency resolution, loading behaviour, and any code that executes before inference begins. The guidance breaks down when teams treat all model artifacts as static data and skip the same scrutiny they would apply to executable packages.
For supply-chain control expectations that extend beyond AI-specific concerns, the NIST Cybersecurity Framework 2.0 is relevant because it reinforces governance, protection, detection, and recovery as linked duties across the lifecycle.
Where the Usual Mental Model Breaks Down
Tighter model scrutiny often increases operational overhead, requiring teams to balance faster model adoption against stronger artifact assurance.
One common edge case is the gap between “open weights” and “open trust.” Public availability does not mean safe reuse, and community popularity does not mean the artifact is suitable for your loading environment. Another edge case is format conversion: a model may be safe in one framework but become riskier once repackaged, because the conversion step introduces new parsers, wrappers, or compatibility layers. Guidance is not fully settled on how much static inspection is enough across every model format, so teams should treat consensus as partial rather than assumed.
Another nuance is that the highest-risk model file is not always the most obviously suspicious one. Teams often focus on prompt injection and inference-time misuse, but the more serious failure may be a trusted model artifact that silently expands the application’s execution surface during deployment. That means provenance, code review, and artifact hygiene need to be aligned with the specific storage and loading mechanism, not only with the model’s expected output behaviour.
The practical limit is that no single control pattern covers every model format, registry, and conversion path. Teams that rely only on source reputation or only on runtime monitoring will miss one side of the problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | MAP — Map | Model files affect AI supply-chain trust and lifecycle risk. |
| MANAGE — Manage | The question is about governing risk in AI supply chains. | |
| MEASURE — Measure | Teams need assurance signals for artifact integrity and loading safety. | |
| Recommendation — Map model artifact trust boundaries and loading paths before approval. Manage model provenance, validation, and intake risk as part of AI governance. Measure artifact integrity checks and loading controls before deployment. | ||
| CIS Controls v8 | 15 — Service Provider Management | Third-party checkpoints and registries create supplier-risk exposure. |
| 16 — Application Software Security | Unsafe parsing and embedded logic in model files are software-safety issues. | |
| Recommendation — Assess third-party model sources and enforce acceptance criteria for imported artifacts. Validate model loaders and parsers like other security-sensitive software components. | ||
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Malicious model artifacts may hide harmful logic or payloads in packaged form. |
| Recommendation — Inspect model artifacts for hidden payloads and suspicious embedded behavior. | ||
Practitioner Guidance
What to prioritise: Treat model intake as a software supply-chain decision, not a data-download step. The first question should be whether the artifact can execute or instantiate behaviour during load, because that determines whether code-review discipline is needed before anything reaches production.
What to verify: Confirm the exact file format, loading library, dependency chain, and conversion history before trust is granted. If the model requires custom operators, deserialisation, or external package resolution, assume the assurance bar must be higher than for a plain weights file.
Common mistake: Teams often validate model quality after acquisition but never validate model behavior at ingestion. That leaves them exposed to a trusted artifact that changes the environment before monitoring, sandboxing, or runtime policy can intervene.
Practitioner takeaway: The decisive security question is not whether the model is “good,” but whether importing it changes what your system can execute, trust, or load before your normal protections are active.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
