LangChain core serialization flaw exposes agent framework trust boundaries

At a glance

What this is: This is an analysis of a critical langchain-core serialization flaw that can turn attacker-shaped LLM output into unsafe deserialization and secret exposure in agent workflows.

Why it matters: It matters because teams running AI agents must govern framework trust boundaries, not just model prompts, if they want to prevent secrets, metadata, and execution paths from crossing privilege lines.

By the numbers:

• 12 distinct flows in common LangChain use cases., in common LangChain use cases.

👉 Read CYATA's analysis of the langchain-core serialization flaw and AI agent trust boundaries

Context

LangChain core is a shared dependency in many AI application stacks, so a serialization flaw there becomes a governance problem as much as a software bug. When untrusted model output can influence structured state that later gets rehydrated, the boundary between content and code becomes hard to defend.

In this case, the primary issue is not a single tool integration. It is the framework's own handling of reserved markers and serialized objects, which means teams need to think about AI agent identity, data flow trust, and deserialization risk together rather than as separate controls. This is a typical failure mode in fast-moving agent adoption programmes.

Key questions

Q: What breaks when attacker-shaped LLM output reaches serialization paths in AI frameworks?

A: The failure is trust boundary collapse. If model output can carry attacker-controlled fields into serialization and later deserialization, the framework may revive unsafe objects or leak secrets through normal application flows. Teams should treat structured AI metadata as untrusted until it is explicitly normalised and isolated from replayable state.

Q: Why do AI agent frameworks create new secrets exposure risks for IAM teams?

A: They combine model output, tool calls, caches, and logging in one runtime path, which means a single unsafe object can cross multiple privilege boundaries. IAM teams need to know where environment variables, tokens, and constructor side effects are reachable from deserialized state, because that is where exposure becomes operational.

Q: What do security teams get wrong about allowlists in deserialization?

A: 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.

Q: How should organisations respond when a core AI framework serialization flaw is disclosed?

A: Patch the core dependency immediately, then trace every place where untrusted model output can be stored and reloaded as structure. Prioritise flows that touch secrets, caches, traces, and message history, because those are the paths most likely to convert a framework bug into real exposure.

Technical breakdown

How reserved markers create unsafe object revival in langchain-core

LangChain uses internal markers to distinguish framework objects from ordinary dictionaries. The LangChain advisory shows what happens when user-controlled data can carry the same marker and still pass through normal serialization paths. If dumps() and dumpd() do not escape attacker-shaped dictionaries, the framework can later interpret them as trusted structure during deserialization. That is not just a parsing bug. It is a trust-boundary failure where metadata becomes executable meaning inside the application runtime.

Practical implication: teams should treat any framework-owned marker field as a security boundary and review where untrusted data can inherit internal structure.

Why streaming logs and message history expand the blast radius

The risky path is often indirect. LLM output can land in fields such as additional_kwargs or response_metadata, then flow through streaming logs, event traces, memory stores, or caches before being reloaded later. That makes the attack harder to spot because no single step looks dangerous in isolation. The vulnerability turns ordinary observability and state-rehydration features into a propagation channel for attacker-shaped structures, which is why framework-level serialization and deserialization choices matter so much in AI applications.

Practical implication: isolate or sanitise streamed model metadata before it enters any storage or replay path.

How secret resolution turns deserialization into data exposure

The advisory also shows how deserialization can resolve secrets from environment variables when secret lookup is enabled. In that pattern, an attacker does not need direct file access or shell execution to reach sensitive values. If the framework instantiates a class that performs outbound requests or reads secrets during construction, the deserialization step itself becomes an access path. That is why allowlists are necessary but not sufficient: the constructor behaviour of allowlisted objects still matters.

Practical implication: review which deserialized objects can access environment variables, network endpoints, or other privileged runtime state.

Threat narrative

Attacker objective: The attacker wants to turn ordinary AI framework processing into secret exposure or unsafe object instantiation without needing a separate host compromise.

1. Entry occurs when attacker-shaped LLM output is preserved in structured fields such as additional_kwargs or response_metadata and later reaches serialization code.
2. Escalation occurs when dumps() or dumpd() preserves a user-controlled dictionary containing the reserved lc marker, allowing the framework to treat it as trusted LangChain structure.
3. Impact occurs when deserialization revives an unsafe object, enabling secret extraction, outbound requests, or other constructor side effects inside privileged agent workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Marker-based serialization is a hidden identity boundary, not a convenience feature. When a framework uses reserved fields to distinguish trusted objects from ordinary data, it creates an identity decision inside the application runtime. That decision becomes dangerous when attacker-shaped content can present itself as framework-owned structure. The implication is simple: AI platforms must be governed as trust-boundary systems, not just as application code.

Secret resolution during deserialization is an access-control failure, not a harmless helper. The LangChain advisory shows that a deserializer can become a secret broker when it resolves values from environment variables or instantiates classes with privileged side effects. That assumption was designed for controlled, developer-owned data. It fails when model output and retrieved content can flow into the same path. Practitioners need to rethink what counts as trusted input, not just add more scanning.

LangChain core illustrates an identity blast radius problem for agent frameworks. Because core orchestration libraries sit underneath logs, caches, memory, and tool execution, one serialization defect can cut across multiple application layers at once. This is exactly why AI agent governance must include framework dependency inventory, data-flow mapping, and runtime trust classification. The practical conclusion is that the framework boundary is now part of the security boundary.

Allowlists reduce exposure but do not neutralise constructor behaviour. A class can be approved for deserialization and still perform network calls, read secrets, or trigger template rendering when instantiated. That means the governance question is not only which classes are permitted, but what those classes do at creation time. Teams should treat allowlisted constructors as privileged runtime actions, especially in agent stacks that handle untrusted metadata.

Static prompt controls do not solve runtime serialization risk. Prompt injection is only the starting condition here. The actual failure occurs when attacker-shaped output survives long enough to be serialised, persisted, and rehydrated as structured state. That is the point where conventional LLM safety thinking gives way to identity and access governance for machine-generated data. The implication for practitioners is to map trust over time, not just at prompt entry.

From our research:

• 60% of NHIs are being overused, with the same NHI utilised by more than one application, increasing the risk of widespread compromise if exposed, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• From our research: 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• The same governance gap appears in AI stacks when serialized state outlives the trust assumptions that created it, which is why lifecycle controls and runtime boundaries need to be designed together.

What this signals

Marker confusion is the new boundary problem: when an AI framework uses internal markers to distinguish trusted objects from user data, the resulting control plane is only as strong as the sanitisation around those markers. Teams running agentic systems should assume that any stored metadata can be adversarially shaped, then align storage, replay, and secret-access controls to that assumption.

With 60% of NHIs overused across more than one application, per The 2025 State of NHIs and Secrets in Cybersecurity, AI runtime components are already operating in a high-blast-radius environment. The next governance failure will not come from a single prompt, but from how long untrusted state is allowed to survive inside privileged orchestration layers.

The practical shift for programmes is to map AI dependencies as identity-bearing infrastructure, not as isolated application code. Once logs, caches, and deserializers can revive privileged structures, your response process needs dependency inventory, version tracking, and trust-boundary review built into normal IAM and NHI operations.

For practitioners

• Inventory every serialization and replay path Map where LLM output, tool output, and retrieved content enter additional_kwargs, response_metadata, message history, caches, and event streams before they are reloaded.
• Disable secret resolution for untrusted serialized input Review any use of secrets_from_env or similar lookup behaviour and require explicit trust boundaries before environment variables can be resolved during deserialization.
• Separate observability data from executable state Prevent logging and tracing pipelines from preserving attacker-shaped fields in a form that later rehydrates into LangChain objects or other privileged structures.
• Audit allowlisted constructors for side effects Test every deserializable class for network calls, file access, template rendering, or secret access during instantiation, then remove anything that performs privileged work by default.
• Patch core framework dependencies first Upgrade langchain-core and verify the resolved version in production images, workers, and notebook environments before you rely on code review or feature flags.

Key takeaways

• A langchain-core serialization flaw turns reserved markers into a trust-boundary failure that can let attacker-shaped data behave like internal structure.
• The risk is not abstract: common AI workflows such as streaming, memory, and cache replay can move untrusted fields into privileged deserialization paths.
• Security teams should patch quickly, isolate model metadata from executable state, and audit deserialization for secret access or constructor side effects.

Key terms

• Reserved Serialization Marker: A reserved serialization marker is a special field a framework uses to distinguish internal objects from ordinary data. In AI systems, this becomes a security boundary because user-controlled input must never be allowed to masquerade as trusted structure during deserialization.
• Deserialization Trust Boundary: A deserialization trust boundary is the point where data stops being inert text and starts becoming an object the runtime can act on. In agentic systems, that boundary is high risk because replayed state may carry secrets, executable templates, or privileged metadata.
• Constructor Side Effect: A constructor side effect is any network call, file access, secret lookup, or other privileged action that happens when an object is created. In deserialization, side effects turn object revival into an execution path rather than a harmless data conversion.
• Agent Framework Blast Radius: Agent framework blast radius is the range of systems, data flows, and credentials that can be affected when a shared AI framework fails. It is often wider than a single application because logs, caches, traces, and orchestration layers all inherit the same trust assumptions.

What's in the full article

CYATA's full analysis covers the operational detail this post intentionally leaves for the source:

• The vulnerable code paths in dumps() and dumpd() and how the reserved lc marker is handled in patched versions.
• The full list of 12 affected LangChain flows, including streaming, logging, memory, caches, and hub pulls.
• The constructor side effects in allowlisted classes such as outbound requests and secret resolution.
• The advisory's remediation guidance for production teams running langchain-core and adjacent ecosystem packages.

👉 CYATA's full post covers the vulnerable flows, patch details, and production response guidance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or NHI programme, it is worth exploring.