They often assume an allowlisted class is safe because it is approved. In reality, a permitted class can still read secrets, open network connections, or trigger template rendering when instantiated. The control question is not only whether a class is allowed, but what it does at creation time.
Why This Matters for Security Teams
Allowlists in deserialization fail when teams confuse approval with safety. A class can be permitted and still execute harmful side effects during object construction, including secret reads, network calls, file access, or template rendering. That makes deserialization a capability problem, not just a class-name filter problem. NIST’s identity guidance reinforces the broader point that trust decisions must be tied to context and assurance, not labels alone, as described in the NIST SP 800-63 Digital Identity Guidelines.
This same pattern shows up across non-human identity risk. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is the same root problem in a different form: an approved identity or object can still have dangerous runtime power. Security teams often focus on whether a payload passes the allowlist, rather than whether instantiation creates a path to sensitive data or privileged action. In practice, many teams discover unsafe gadget behavior only after a parser has already been exposed to untrusted input.
How It Works in Practice
The practical mistake is treating the allowlist as the final control. In deserialization, the object lifecycle matters. The moment a class is instantiated, its constructor, setters, annotations, converters, or hooks may run with application context. If those hooks touch secrets, call remote services, or trigger follow-on processing, the class is not safe just because its name was approved.
A stronger approach is to combine allowlisting with explicit object-binder rules, schema validation, and runtime restriction of dangerous types. Security teams should ask three questions:
- Does the class have side effects at creation time?
- Does it expose access to secrets, filesystem paths, or network clients?
- Can it chain into templating, logging, or command execution paths?
That is why current guidance suggests moving from name-based trust to behavior-based trust. The relevant control is not only “is this class allowed,” but also “what privileges does this object gain when created.” NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it pushes teams toward least privilege, input validation, and controlled execution paths rather than implicit trust. NHIMG’s Ultimate Guide to NHIs also highlights how long-lived privileges and poor secret hygiene amplify exposure once a trust boundary is crossed.
Operationally, teams should block unknown types by default, pin parsers to safe data-only formats where possible, and run deserialization inside narrowly scoped processes with no direct secret access. These controls tend to break down when legacy frameworks auto-instantiate rich objects because the application depends on constructor side effects.
Common Variations and Edge Cases
Tighter deserialization controls often increase engineering overhead, requiring organisations to balance compatibility against safer object handling. That tradeoff becomes sharper in legacy Java, .NET, or Python services where object graphs were designed for convenience rather than security.
There is no universal standard for this yet, but current guidance suggests several edge-case checks:
- Framework defaults may silently enable polymorphic deserialization, making a narrow allowlist ineffective.
- Custom classes may look harmless but still invoke logging, JNDI lookups, or token retrieval during initialization.
- Even a safe class can become unsafe if its injected dependencies include network clients or secret managers.
- Signed or authenticated payloads still need behavioral review, because authenticity does not remove gadget risk.
The strongest practical pattern is to combine type restrictions with capability restrictions. Security teams should strip constructors of side effects, isolate deserializers from sensitive environment variables, and treat any class that can read credentials or reach the network as high-risk unless proven otherwise. That is especially important in systems where object creation is coupled to business logic, because the allowlist may pass the payload while the application itself performs the dangerous action.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret handling and privilege sprawl mirror deserialization side-effect risk. |
| OWASP Agentic AI Top 10 | LLM-04 | Unexpected runtime actions by allowed objects resemble agent tool misuse. |
| CSA MAESTRO | I-03 | Execution context and trust boundaries must constrain object instantiation. |
| NIST AI RMF | Behavior-based trust and monitoring align with AI RMF governance principles. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is the key defense when allowed objects can still act dangerously. |
Limit object-created access to secrets and rotate any credentials exposed during parsing.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
