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.
Expanded Definition
Unsafe deserialization is not simply a parsing flaw. It is a trust boundary failure where an application accepts attacker-influenced data and reconstructs objects with methods, constructors, or callbacks that can change program state. In NHI and agentic AI systems, the same pattern appears when tokens, task payloads, or policy objects are rebuilt from untrusted sources and then treated as authoritative. That makes the issue relevant anywhere software processes serialized sessions, job messages, or identity claims.
Definitions vary across vendors on whether the term should be reserved for gadget-chain exploitation or also include logic corruption and denial of service. In practice, security teams should treat any deserialization path that can instantiate privileged types, load classes, or invoke code as high risk. The NIST SP 800-63 Digital Identity Guidelines reinforce the broader principle that identity assertions must be validated and bounded before they are trusted as inputs to downstream decisions.
The most common misapplication is assuming a “safe format” makes the parser safe, which occurs when teams trust JSON, YAML, XML, or binary payloads without restricting the object graph or allowed types.
Examples and Use Cases
Implementing deserialization safely often introduces compatibility and performance constraints, requiring organisations to weigh developer convenience against strict type control and input validation.
- A service account receives a signed job message, but the message is deserialized into a class that triggers file access during object hydration.
- An API gateway rebuilds an authentication context from a token payload, and a malicious field causes a privilege-bearing object to be instantiated.
- A workflow engine loads serialized agent state from a queue, and an attacker-provided gadget chain executes during object reconstruction.
- A legacy Java service accepts cache entries from another tier, and unsafe class loading turns a storage message into a remote code execution path.
- A security review maps repeated object-reconstruction flaws to patterns documented in the Ultimate Guide to NHIs, especially where service accounts and automation trust opaque inputs.
For implementation guidance, teams often compare these scenarios against deserialization-safe design patterns in NIST SP 800-63 Digital Identity Guidelines and then limit the object types that can be rebuilt.
Why It Matters in NHI Security
Unsafe deserialization becomes especially dangerous in NHI environments because automation frequently runs with broad, non-interactive privileges. If a malicious payload can be converted into a trusted object, the attacker may inherit the authority of a service account, workflow runner, or agent. That can lead to secrets exposure, unauthorized API calls, persistence inside CI/CD systems, or lateral movement across trust boundaries. NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which makes any parser that can turn untrusted data into executable behavior a meaningful governance concern.
From a controls perspective, unsafe deserialization is not just an application bug. It is an identity and authorization failure when the deserialized object can act as a proxy for a privileged non-human identity. The practical response is to constrain types, remove polymorphic auto-binding, validate structure before reconstruction, and keep high-risk parsers away from privileged execution paths. Organisatiouns typically encounter the operational impact only after a queue message, config file, or webhook has already executed inside a privileged automation path, at which point unsafe deserialization 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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Unsafe object reconstruction often enables secret misuse and privileged NHI compromise. |
| NIST CSF 2.0 | PR.AA-1 | Identity and access controls fail when deserialized data can impersonate trusted automation. |
| NIST SP 800-63 | Digital identity guidance emphasizes validation before assertions are trusted in downstream flows. |
Verify identity assertions and bound their use before any deserialized object influences authorization.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
