Join our Newsletter — 33% off our NHI Course

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.

Expanded Definition

Cloudpickle is a Python serialization library that extends standard pickling to support runtime-generated code, including lambdas, closures, nested functions, and interactive objects. In machine learning and data engineering, that capability helps teams move models, pipelines, and helper functions across processes or distributed workers without rewriting them into static modules. The tradeoff is that serialization is no longer limited to data structure transfer. It can preserve executable behaviour, which increases the security significance of where objects come from, who can modify them, and how they are deserialized.

Definitions vary across vendors and engineering teams about whether cloudpickle should be treated as a convenience layer or as a privileged code transport mechanism, but the security posture is the same: anything that reconstructs executable Python objects deserves the same scrutiny as other software supply chain inputs. For NHI and Agentic AI governance, cloudpickle matters because agents and automation jobs often move code, state, and credentials through the same orchestration paths. The most common misapplication is treating a cloudpickle payload like inert data, which occurs when teams load untrusted artifacts from shared buckets, message queues, or notebooks.

For broader identity and access context, the NIST Cybersecurity Framework 2.0 is useful because it frames how organisations should protect software artefacts, execution environments, and trust boundaries around them.

Examples and Use Cases

Implementing cloudpickle rigorously often introduces portability and review overhead, requiring organisations to weigh developer speed against the need to inspect executable payloads before they move across trust boundaries.

  • A data science team serializes a trained pipeline that includes a closure capturing preprocessing logic, then restores it in a batch job running under a service account with scoped access.
  • An Agentic AI workflow sends a dynamically defined tool wrapper between workers, which works well operationally but requires controls around artifact provenance and deserialization permissions.
  • A notebook prototype uses cloudpickle to persist helper functions during experimentation, then graduates into production without a code review step, creating hidden execution paths.
  • An incident response team investigates a suspicious object loaded from shared storage after a workflow mirrors the kind of credential and access abuse seen in the 230M AWS environment compromise.
  • A cloud team compares serialization controls with lessons from the Snowflake breach and validates whether privileged automation can load runtime-defined code from shared locations.

In implementation terms, cloudpickle should be restricted to trusted build paths, signed artifacts, and controlled runtime environments. When teams need to understand the library’s mechanics in more detail, the Python ecosystem documentation and the NIST framework both help anchor the discussion in operational controls rather than convenience alone.

Why It Matters in NHI Security

Cloudpickle becomes an NHI concern because modern workloads often use service identities, ephemeral credentials, and agent execution paths to exchange serialized tasks across systems. If the payload is tampered with, the identity that loads it may unintentionally execute attacker-controlled behaviour under legitimate privilege. That is especially dangerous where secrets are embedded in environment state, where notebooks move from experimentation into production, or where automation tools deserialize objects from shared object stores. The control problem is not just code safety. It is also identity scoping, artifact integrity, and separation of duties around who can create, store, and run serialized objects.

NHIMG research shows how often access governance lags behind automation reality: 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey. That risk compounds when serialization paths are also privileged. The lesson aligns with the NIST Cybersecurity Framework 2.0: protect the asset, limit access, and verify trust before execution. Organisaties typically encounter the consequences only after a workflow unexpectedly runs modified code from a shared artifact store, at which point cloudpickle becomes operationally unavoidable to address.

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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-02 Serialized objects can hide executable behavior and secret handling risks.
OWASP Agentic AI Top 10 A2 Agent workflows may move dynamic code through serialization paths.
NIST CSF 2.0 PR.DS Data and software integrity controls apply to serialized execution artifacts.
NIST Zero Trust (SP 800-207) SC-7 Zero trust requires verifying trust boundaries before execution.
NIST AI RMF AI risk management must consider code mobility and runtime trust.

Restrict untrusted deserialization and treat cloudpickle artifacts as privileged code, not data.