Security teams detect model serialisation attacks by treating deserialised model files as untrusted input and checking them for embedded code or unexpected object types. Review which serialisation formats are permitted, load artefacts only in sandboxed environments, and monitor for execution during deserialisation. Prefer formats and workflows that do not execute code on load.
What makes a model serialisation attack detectable?
Detection starts with assuming that a model file can behave like an executable payload, not just passive data. The practical signal is anything that should not happen during load, such as code execution, suspicious object construction, filesystem access, network activity, or a deserialisation path that accepts formats known to preserve executable behaviour.
Teams should also look for mismatch between the expected artefact and the object graph actually restored. If a model package contains unexpected classes, functions, hooks, or nested objects, that is a stronger indicator than simple file type inspection alone. Detection is strongest when it combines artefact inspection, runtime telemetry, and strict allowlists for serialisation formats.
Model serialisation attacks are easier to spot when the pipeline is designed so that loading is observable. That means capturing process execution, child processes, outbound connections, and any writes made during deserialisation, then flagging behaviour that is inconsistent with a normal inference-only load.
How should teams inspect model files without triggering the payload?
Inspection should happen in a controlled environment where the artefact can be analysed before full trust is granted. A safe workflow is to treat new or third-party model files as untrusted input, open them in a sandbox, and compare the declared serialisation format with what is actually present inside the file.
Static checks can identify common warning signs, such as embedded bytecode, pickled object references, unexpected code objects, or references to libraries that the model should not need at load time. When a team uses formats that are meant to be data-only, the review should confirm that the loading library does not silently reintroduce code execution through custom handlers or hooks.
For teams that manage model distribution at scale, format policy matters as much as inspection. A narrow set of approved formats reduces the chance that a poisoned artefact will enter the environment, and it makes alerting much easier because any nonconforming file becomes an investigation item rather than a routine exception.
What runtime signals matter most during deserialisation?
Runtime monitoring should focus on behaviour that indicates the loader is doing more than reconstructing state. The most useful signals are process spawning, unexpected module imports, shell invocation, file drops, network beacons, and privilege changes during the load phase. Those events are especially suspicious when they appear before the model is ever used for inference.
It is also useful to monitor where deserialisation occurs. Loading should be isolated from production service identities, high-value credentials, and broad filesystem permissions. If a malicious object can only run inside a low-trust sandbox, the detection problem becomes more manageable because the compromise has a narrower blast radius and a clearer audit trail.
The State of NHI & AI Agent Breach Report 2026 is a useful reminder that attackers often rely on stolen secrets or service access to turn an initial foothold into broader compromise, which is why load-time monitoring should be paired with identity and access containment.
Risk and Threat Considerations
Model serialisation attacks matter because the load step can become a hidden execution channel. If a poisoned artefact is allowed to deserialize in a trusted runtime, an attacker may gain code execution, data access, or a foothold for lateral movement before any model output is inspected.
Failure mechanism: The attack succeeds when the deserialiser reconstructs attacker-controlled objects or handlers instead of treating the file as inert data, especially in environments that permit unsafe formats or load artefacts with excessive privilege.
Impact: A successful load can expose secrets, alter model behaviour, create persistence in the ML pipeline, or let an attacker pivot into surrounding infrastructure through the account or service that performs the load.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1027 — Obfuscated Files or Information | Poisoned model files hide malicious content inside an artefact. |
| Recommendation — Inspect loaded artefacts for hidden payloads and suspicious embedded objects. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Load-time monitoring is needed to spot unexpected execution or network activity. |
| Recommendation — Monitor model-loading hosts for anomalous process, file, and network activity. | ||
| CIS Controls v8 | CIS-10 — Data Recovery | Safe model handling depends on isolating and restoring trusted artefacts cleanly after compromise. |
| Recommendation — Maintain clean recovery paths for repositories that store model artefacts. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Deserialisation attacks are detected through monitoring of runtime behaviour during load. |
| Recommendation — Instrument model-loading systems to alert on unexpected execution and outbound activity. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The issue is a dangerous data-to-code boundary in how artefacts are loaded. |
| Recommendation — Design loaders so deserialised model data cannot trigger code execution. | ||
Practitioner Guidance
What to prioritise: Prioritise the trust boundary around model loading, not just the model registry. The key question is whether an artefact can execute anything at parse time, because that is where detection and containment matter most.
What to verify: Verify that approved formats are truly non-executable in your toolchain, that sandboxing is enforced for first-time loads, and that telemetry captures process, network, and file activity during deserialisation. If any of those controls are optional, treat the pipeline as exposed.
Decision rule: If the artefact was produced outside your control or arrives in a format that can preserve executable state, load it only in isolation and inspect the object structure before promotion. If you cannot explain why the loader needs execution capability, do not trust the format for routine ingestion.
Practitioner takeaway: The best detection strategy is to make deserialisation observable and boring, because anything that can execute during load should be assumed hostile until proven otherwise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org