AI agent testing exposes unsafe deserialization risks in ML systems

At a glance

What this is: This is an AI security analysis showing how an autonomous testing agent uncovered a critical deserialization flaw in ML infrastructure by turning a harmless-looking pickle path into remote code execution.

Why it matters: It matters because identity and access controls around AI pipelines are only as strong as the trust placed in model files, caches, and internal APIs that can execute code with service privileges.

By the numbers:

• Equixly reports that CVE-2026-0773 is a critical remote code execution vulnerability with a CVSS score of 9.8.
• CVE-2025-32434 remained exploitable even with weights_only=True, able even with weights_only=True, showing one “safe” mode still failed.

👉 Read Equixly's analysis of the CVE-2026-0773 AI security finding

Context

AI model pipelines often blur the boundary between data and code, which makes unsafe deserialization one of the most underestimated failure modes in AI security. When a framework loads pickled objects, it may also execute attacker-controlled logic with the privileges of the service doing the loading, turning a model artifact, cache file, or internal API payload into a code execution path.

The article’s central concern is not the specific CVE alone, but the wider governance gap around trust in machine learning infrastructure. For IAM and NHI teams, the intersection is clear: service accounts, tokens, and cloud credentials used by ML pipelines become the downstream prize once an attacker reaches a deserialization sink, and that is now a familiar pattern rather than an edge case.

Key questions

Q: What breaks when ML systems deserialize untrusted model files?

A: Untrusted deserialization turns a data-loading step into code execution, because the loader may reconstruct attacker-controlled objects and run embedded logic. That can expose secrets, alter model behaviour, or let an attacker pivot into the workload’s cloud permissions. The safe assumption is that any pickle-like loader is an execution boundary, not a parsing boundary.

Q: Why do AI pipelines expose more credential risk than traditional software development?

A: AI pipelines create more identities, more integrations, and more temporary execution paths than conventional software delivery. Each model, agent, notebook, and orchestration step can generate a new token or secret, and those artefacts often propagate into places security teams do not monitor. The result is identity sprawl, not just poor hygiene.

Q: How do security teams know if model loading is operating outside its intended boundary?

A: Look for model artefacts that are writable by multiple systems, loaded from shared storage, or accepted through network-exposed APIs without signing or origin checks. Another warning sign is any workflow that needs pickle or cloudpickle for convenience rather than necessity. Those are signals that the boundary is already too permissive.

Q: Who is accountable when a model file leads to code execution?

A: Accountability sits with the teams that approved the artefact format, the runtime that loaded it, and the owners of the service account that executed it. If the organisation treats model files as harmless data, the control failure is governance, not just development hygiene. That is where policy, provenance, and privilege scope must be enforced.

Technical breakdown

Why pickle and cloudpickle can become execution paths

Pickle is a Python serialization format that reconstructs objects by invoking methods such as __reduce__. That design is efficient, but it also means an attacker can embed a callable and arguments inside the serialized payload, so deserialization becomes code execution rather than simple parsing. Cloudpickle broadens the surface by supporting lambdas, closures, and dynamically defined functions, which is useful for developers and equally useful for attackers. In ML systems, this risk appears in model loading, cached embeddings, configuration blobs, and internal IPC. Practical implication: treat any deserialization boundary as an execution boundary and never assume a file extension makes content safe.

Practical implication: remove pickle from trust boundaries that touch untrusted inputs and isolate any remaining loaders in tightly constrained runtime environments.

How autonomous API exploration exposed the weakness

The article describes an AI agent that mapped endpoints, inferred hidden operations, and tested content types until it found one that accepted binary data without authentication. Once the agent saw the error string indicating unpickling, it did not need a signature match or a prior CVE to recognise the risk. That is important because many security programmes still assume exploitation requires a known pattern or a human analyst following a fixed playbook. In practice, AI-assisted testing can chain discovery, sequencing, and input generation fast enough to surface logic flaws and deserialization sinks before conventional tools flag them. Practical implication: DAST coverage must include stateful, content-aware, and binary-path testing.

Practical implication: add stateful API testing and binary-input coverage to security validation instead of relying only on signature-based scanners.

Why safer formats help, but do not remove the governance problem

Safetensors and similar formats reduce risk because they store numerical tensors rather than executable Python objects. That helps for model weights, but it does not solve everything, because many ML workflows still need object serialization for custom layers, training state, orchestration metadata, or cached intermediates. The result is a mixed estate where some assets are inert and others remain code-bearing. From a governance perspective, that fragmentation matters more than the file format name. Security teams need to know which artefacts are safe to move, which require signing, and which should never cross a trust boundary at all. Practical implication: build a serialization inventory and classify each artefact by executable risk, not by convenience.

Practical implication: classify ML artefacts by execution risk and require signing or reconstruction controls for anything that can carry code.

Threat narrative

Attacker objective: The attacker aims to turn a trusted ML loading path into arbitrary code execution that can expose secrets and expand access into the wider environment.

1. Entry occurs when an API endpoint, model file, or cache accepts binary data or serialized objects from a source that has not been strongly validated.
2. Credential or code access follows when the loader reconstructs attacker-controlled Python objects and executes embedded logic during deserialization.
3. Impact occurs when the attacker uses that execution path to run commands, exfiltrate environment variables, or pivot into cloud credentials and backend systems.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI model files have become a disguised identity and privilege boundary. The article shows that a serialized model can carry executable behaviour, not just data, which means the real control question is who and what is allowed to influence runtime code paths. In NHI terms, the service account loading the artefact is the privilege holder, but the file can still determine what that identity executes. Practitioners should treat model ingestion as a governed access decision, not a storage operation.

Unsafe deserialization is a governance assumption failure, not just a coding mistake. The core assumption is that internal sources, cached artefacts, or “safe” framework modes are trustworthy enough to deserialize automatically. That assumption fails when attackers can poison caches, compromise CI/CD, or reach internal APIs with network access. The breach pattern here is the same one that drives many NHI incidents: persistent trust in artefacts whose origin and integrity were never continuously verified. Practitioners need provenance controls, signing, and runtime containment, not more confidence in default loaders.

Context-aware AI testing changes the economics of vulnerability discovery. The article’s agent did not rely on a known signature or a human hypothesis. It explored, learned, and adapted to the target’s responses, which means AI-assisted offensive testing can outpace teams that still depend on linear review and static scanning. For AI governance, this strengthens the case for testing models, pipelines, and internal APIs as attack surfaces in their own right. Security programmes should expect machine-speed discovery and design validation workflows accordingly.

Pickle risk is a supply chain and workload identity problem at the same time. A poisoned model cache, shared NFS mount, or overly permissive bucket becomes dangerous because the loading workload often has broad cloud access and embedded secrets. That makes identity scope, secret exposure, and runtime isolation part of the same control story. In practice, the question is not whether the framework is popular, but whether the workload identity can safely touch the artefact at all. Practitioners should narrow privileges before they narrow file formats.

Serialized artefact governance should become a named control category. A useful concept here is deserialization trust debt: the accumulated risk created when teams keep treating executable artefacts as if they were inert data. That debt grows across notebooks, pipelines, caches, and registries until one parsing boundary becomes enough for code execution. The practical answer is to inventory every deserialization path, define who can write to it, and remove any assumption that internal equals trusted. Practitioners should classify and govern the boundary explicitly.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• From our research: Read 52 NHI Breaches Analysis for the breach patterns that show how weak lifecycle control and excessive trust lead to compromise.

What this signals

Deserialization trust debt will become a recurring AI governance metric. As ML systems expand, the number of places where a service account can load executable artefacts grows faster than most security teams can document them. That means governance needs to track not only model provenance but also which identities can touch each artefact and from where. The practical shift is toward inventory, signing, and isolation as default controls, not exceptional hardening.

For teams already using identity governance in cloud and application estates, the lesson is to extend those controls into ML pipelines before they become blind spots. The same discipline that helps with Top 10 NHI Issues applies here: know which workloads can act, what they can load, and what secrets they can reach. That is how AI security stops being a separate programme and becomes part of the access model.

The article also reinforces why agentic testing matters as a defensive capability. AI can now discover weak assumptions in APIs and frameworks faster than many manual review cycles, which means validation must become continuous and content-aware. Teams should align their validation strategy with the MITRE ATT&CK Enterprise Matrix for attack-path thinking and with the OWASP NHI Top 10 for agentic risk coverage.

For practitioners

• Inventory every deserialization path in ML systems Map where pickle, cloudpickle, torch.load, joblib, and similar loaders are used in training, inference, caching, and internal APIs. Classify each path by whether untrusted inputs, shared storage, or network-reachable services can reach it.
• Remove executable artefacts from trust boundaries Prefer inert formats for model weights and simple config data, and stop accepting serialized Python objects where JSON, Protocol Buffers, or explicit reconstruction will work. If legacy code must remain, segment it from production credentials and cloud access.
• Require signing and provenance checks for model artefacts Verify source, integrity, and approval before any model file, cache object, or dependency enters a pipeline. Enforce cryptographic signing for artefacts that cannot be eliminated and block unsigned objects from loading.
• Test binary and stateful API behaviour during validation Extend security testing beyond common web payloads by including malformed binary inputs, hidden endpoints, and dependency-chain sequencing. Use findings such as unpickling errors as indicators that a code execution sink may exist.

Key takeaways

• Unsafe deserialization turns model loading into a code execution problem, so AI pipelines need identity and integrity controls at the artefact boundary.
• The article shows how autonomous testing can expose critical binary-path flaws that conventional scanners often miss, especially in internal ML APIs and caches.
• The most effective response is to inventory deserialization paths, restrict workload privileges, and require signed artefacts wherever executable formats remain necessary.

Key terms

• Unsafe Deserialization: Unsafe deserialization happens when software reconstructs objects from untrusted data in a way that can trigger code execution or state corruption. In practice, the risk is not the file or message itself, but the fact that the parser is allowed to invoke behaviour while rebuilding the object.
• Cloudpickle: Cloudpickle is a Python serialization library that can handle dynamic objects such as lambdas, closures, and functions defined at runtime. That flexibility is useful for machine learning workflows, but it also expands the attack surface because the serialized object may contain executable behaviour, not just data.
• Deserialization Trust Debt: Deserialization trust debt is the accumulated risk that comes from repeatedly treating executable artefacts as if they were inert files. It grows across caches, notebooks, pipelines, and APIs until one loading step can become a code execution path that security teams never explicitly governed.
• Model artefact provenance: Model artefact provenance is the chain of trust showing where a model file, tokenizer, metadata bundle, or derived package came from and whether it was modified. For autonomous and agentic deployments, provenance must cover the whole package, not just the neural weights.

What's in the full article

Equixly's full blog covers the implementation detail this post intentionally leaves for the source:

• The autonomous testing workflow used to map API surfaces and sequence operations before a payload was ever generated.
• The proof-of-concept reasoning behind identifying an unpickling sink from a binary error response.
• The specific attacker pathways involving poisoned caches, shared storage, and internal APIs that can lead to code execution.
• The defensive trade-offs between pickle, cloudpickle, safetensors, and explicit reconstruction in production ML systems.

👉 The full Equixly blog covers the attack chain, unsafe deserialization mechanics, and mitigation options in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect access control, lifecycle discipline, and runtime trust across modern identity programmes.