Your AI Agents Are Leaking Enterprise Data. Here's Why Nobody Is Watching.
If your organization is planning to deploy autonomous AI agents - or already has - this is the most important security conversation you're not having.
Most enterprise security teams are still focused on the wrong threat.
They've built policies around employees copying and pasting data into ChatGPT. They've deployed browser extensions. They've written acceptable use policies. Some have even started monitoring GenAI traffic.
And while they were doing all of that, the actual threat moved somewhere else entirely.
The real exposure in 2026 isn't what your employees type into ChatGPT. It's what your autonomous agents are doing right now - pulling from internal databases, chaining tool calls, accumulating sensitive context across dozens of pipeline steps - and sending all of it to external LLM providers with no human in the loop and nothing in between.
The Fundamental Difference Nobody Is Talking About
There's a reason the shift from human AI usage to agentic AI deployment is not just a step change - it's a category change.
When an employee uses ChatGPT, a human decision sits at every point of data exposure. They choose what to paste. They sometimes hesitate. They occasionally realize they've gone too far and stop. The friction is built in.
An autonomous agent has none of that friction. It executes. It doesn't second-guess. It doesn't hesitate. It doesn't know what it doesn't know.
A LangGraph agent authorized to analyze customer data will query your CRM, retrieve records, combine them with outputs from previous tool calls, accumulate the context across memory, and send the composed payload to OpenAI or Anthropic - all within seconds, all within its granted permissions, all completely invisible to every security tool you currently have deployed.
That's not a hypothetical. That's how these systems are designed to work.
The security problem is not that agents misbehave. It's that they behave exactly as designed, with access to data your security policies weren't built to govern.
The March 2026 Wake-Up Call
In late March 2026, security researchers at Cyera disclosed three critical vulnerabilities in LangChain and LangGraph - the frameworks that power a substantial share of enterprise agent deployments worldwide.
The findings were sobering. Each vulnerability exposed a different class of enterprise data through a completely independent attack path.
CVE-2026-34070 (CVSS 7.5 - High): A path traversal vulnerability in LangChain's prompt-loading API that allows attackers to access arbitrary files on the filesystem - Docker configurations, SSH keys, environment variables, internal credentials - without any validation. The attack requires nothing more than a specially crafted prompt template.
CVE-2025-68664 (CVSS 9.3 - Critical): A deserialization flaw that leaks API keys and environment secrets. Researchers named it "LangGrinch." The attack vector runs through LLM response fields that can be manipulated via prompt injection, then serialized and deserialized in streaming operations. It was sitting in production systems for months before disclosure. The most common path to exploitation: standard agentic workflow behavior that nobody flags as suspicious.
CVE-2025-67644 (CVSS 7.3 - High): An SQL injection vulnerability in LangGraph's SQLite checkpoint implementation. LangGraph uses checkpoints to maintain state in complex workflows. A successful exploit allows attackers to run arbitrary SQL queries against the database - exposing sensitive conversation histories and workflow state data that agents have accumulated over time.
LangGraph recorded over 9 million PyPI downloads in the week the vulnerabilities were disclosed. LangChain recorded over 52 million.
Patches were released. But the researchers issued a warning that most coverage buried: patching alone is not enough. Organizations need to audit prompt-loading functions, treat LLM outputs as untrusted input, validate metadata keys before checkpoint queries, and maintain ongoing security practices specific to agentic systems.
The question isn't whether your frameworks are patched. The question is whether your organization has the operational capacity to govern agentic behavior on an ongoing basis.
Most don't. And most don't know what that gap actually costs.
Why Your Existing Security Stack Has a Blind Spot
Understanding why traditional security tools fail for agentic AI requires understanding how they were built.
Every major security category - endpoint detection, data loss prevention, identity management, API gateways - was designed around a common assumption: security gets applied at the point where a human makes a decision to move data.
A human downloads a file. A human sends an email. A human pastes something into a web form. Security controls intercept those human decisions.
Agentic AI eliminates the human decision point entirely.
When an agent executes, it uses real credentials and approved interfaces. When it accesses sensitive data, the request is treated as valid because the agent is authorized to make it. When it composes a prompt from accumulated context and sends it externally, the connection is authenticated and the content is within the agent's granted permissions.
There is no clear distinction, at the security control layer, between normal agentic behavior and dangerous agentic behavior. The agent is doing exactly what it's supposed to do. It just happens to be doing it with data that should never have left your infrastructure.
ISACA's 2026 research framed it precisely: "Endpoint detection tools look for malware. Data loss prevention tools look for known patterns. Identity systems validate authentication. None of these are natively designed to detect misuse of legitimate, autonomous activity."
That's the blind spot. And as agent deployments scale, the blind spot scales with them.
The Multiplier Effect: Why This Gets Exponentially Worse With Agents
Let's ground this in numbers rather than abstractions.
Consider a mid-size enterprise with 500 employees, a reasonable proportion of whom use AI tools regularly. Assume each generates 15 prompts per day to external AI services. Assume 7% contain data that carries meaningful risk - PII, credentials, source code, internal strategic information. That's roughly 500 high-risk events per day across the organization.
Now assume you deploy a LangGraph pipeline with access to your CRM, your internal document store, and your analytics database. A single agent session might involve 40 to 80 tool calls. Each call adds to the accumulated context. The final payload sent to the external model contains fragments from dozens of internal data sources, assembled automatically, with no human review.
A single agent pipeline running 8 hours a day generates more potential data exposure events than your entire workforce combined.
McKinsey's September 2025 cybersecurity survey found that organizations expect the share of security budgets allocated to AI solutions to nearly triple over the next three years. Security leaders are beginning to understand what the threat surface shift actually means. The challenge is that the tools to address it are still catching up.
The Architecture Problem: Why the Security Layer Has to Be Inside the Pipeline
When security architects encounter this problem for the first time, the instinct is to add another layer on top of existing infrastructure. More DLP. A smarter gateway. A wrapper around outbound API calls.
The problem with that instinct is that it applies the old mental model to a new problem.
A browser-level tool sees the final prompt that reaches an AI interface. It has no visibility into what the agent did before it composed that prompt - the tool calls it made, the data it retrieved, the context it accumulated, the reasoning path it followed.
An API gateway sees the outbound request at the moment it leaves your infrastructure. It sees a payload. It does not see the 40 pipeline steps that assembled that payload, or the sensitive fragments that got mixed into the context five tool calls ago.
To actually govern what an agent does with data, the security layer has to sit inside the execution graph. Between the agent's tool calls and the external model. Reading the full runtime state - message history, tool outputs, accumulated context, complete graph state - not just the final string.
This is what execution-layer security means. And it's architecturally different from every security category that currently exists.
The comparison is direct: proxy-based solutions and browser-level tools see what crosses the boundary. Execution-layer security sees everything that happens before anything crosses the boundary. The difference is the entirety of the agentic attack surface.
The Employee AI Risk You're Also Missing
While agentic AI represents the emerging threat, the immediate exposure in most organizations is already significant - and equally invisible.
Most enterprise security teams have no systematic visibility into what employees are sending to ChatGPT, Claude, and Gemini. Not because the tools don't exist, but because adoption has outpaced governance.
Shadow AI isn't new. But the scale has changed. Enterprise AI usage grew by hundreds of percent year over year. The vast majority of that usage happens without IT oversight, without policy enforcement, and without any audit trail.
This matters for agentic AI for a specific reason: your agents will inherit your organization's data habits.
If your employees have normalized sending customer records to Gemini, that pattern is reflected in your data posture. When you deploy an agent with CRM access, you're deploying into an environment where that boundary has already been eroded. The agent will interact with the same external providers, with the same data types, at twenty times the volume and zero human judgment.
Understanding your current AI risk surface - before agents amplify it - is not a nice-to-have. It's the baseline from which every subsequent security decision has to be made.
What Good Looks Like: A Security Framework for the Agentic Era
The organizations getting this right are approaching it in three layers, in sequence.
Layer one: Establish visibility before you establish policy.
You cannot write effective policy for behavior you cannot see. Before deploying agents - and before tightening rules around employee AI usage - get a clear picture of what's actually happening. What data categories are flowing into external AI services. Which departments carry the most risk. What patterns look like routine behavior versus isolated incidents.
This baseline is what every subsequent decision rests on.
Layer two: Build security into agent architecture from the start.
Security retrofitted to agentic pipelines is security that doesn't work. The access controls, data governance policies, and risk scoring mechanisms need to be part of the initial agent design - not bolted on after deployment.
This means defining, before any agent goes live, exactly what data it can access, what it can do with that data, and what happens when risk thresholds are exceeded. It means treating agent permissions with the same rigor as human identity permissions. And it means having a mechanism to inspect and govern data movement at the execution layer, not just at the perimeter.
Layer three: Monitor agent behavior as a first-class security function.
Human security monitoring looks for anomalies in human behavior. Agentic security monitoring requires a different model - one that tracks tool call sequences, monitors context accumulation, scores the risk of composed payloads in the context of full session state, and maintains audit trails that are meaningful for compliance purposes.
This is genuinely new operational territory. Most security operations centers have not yet built the capability to do it. But the organizations that build it first will have a significant advantage - both in terms of actual risk reduction and in terms of the regulatory readiness that enterprise AI adoption increasingly demands.
Four Things to Do Before Your Next Agent Deployment
1. Map your current AI exposure surface.
Get systematic visibility into what your employees are currently sending to external AI services. This is your baseline. It tells you what risk profile your agents will inherit when they go live. Without this, you're deploying into an unknown.
2. Update your LangChain and LangGraph installations immediately.
CVE-2026-34070 is fixed in langchain-core 1.2.22 and later. CVE-2025-68664 requires langchain-core 0.3.81 or 1.2.5. CVE-2025-67644 is fixed in langgraph-checkpoint-sqlite 3.0.1. If you're running any version before these, you have a known critical exposure in production right now.
3. Define agent permissions with least-privilege discipline.
Every data source an agent can access is a data source that could end up in an external model's context. Audit what each agent touches. Apply the same rigor you'd apply to a human with privileged access to sensitive systems. Then go further, because agents act faster and at higher volume than any human ever would.
4. Require a security review before agent deployments go to production.
Build this into your development process the same way you'd build in a code review or a penetration test. The question isn't whether your agent works correctly. It's whether it governs data correctly - in every path, under every condition, including the ones you didn't anticipate when you designed it.
The Larger Point
The security industry spent years building tools for the threat landscape of the last decade. Those tools are mature, well-understood, and increasingly insufficient.
Agentic AI is not an extension of the GenAI security problem. It's a different problem. It operates at machine speed, with real credentials, across internal systems that were never designed to be governed autonomously. The attack surface isn't the browser. It's the execution graph.
The organizations that understand this now - before agents are running at scale in production - will be in a fundamentally different position than those that understand it after an incident forces the conversation.
There's a narrow window where getting ahead of this is still relatively straightforward. That window is closing.
The question isn't whether to secure your agent pipelines. It's whether you do it before or after something goes wrong.
Asil Ozyildirim
Co-Founder, Privent
Privent is an enterprise security platform built for agentic AI pipelines. We embed natively inside LangGraph, CrewAI, and n8n execution graphs - reading full agent runtime state and governing data movement before it reaches any external model. If you're planning an agentic deployment and want to talk through the security architecture, reach out.