NEWS
Verax AI Risk Assessment is live. See what's exposed
blog

Why DLP Can't See What AI Agents Actually Send

A technical breakdown of why the traffic that carries your data out is indistinguishable, on the wire, from a normal successful request

In our first piece in this series, we walked through a demo where an AI agent read a file called "Career Notes" while helping with an ordinary resume request, and forwarded an SSN, a salary history, and private references straight into an API call. The line we closed on was this: "the SSN left the building inside a JSON body that looked like a successful API call." We want to come back to that line, because it's not a rhetorical flourish. It's the entire reason your DLP stack didn't fire.

What DLP was actually built to catch

Data loss prevention tooling, going back to its earliest network and endpoint incarnations, was built around a specific shape of event: a discrete, classifiable object moving across a known channel. A file gets attached to an email. A document gets copied to a USB drive. A spreadsheet gets uploaded to a cloud storage folder. In every one of those cases, there's something to inspect: a filename, a MIME type, a byte range with a recognizable structure, often a sensitivity label already attached by the organization's classification system.

An AI agent reading a file doesn't produce any of that. It opens the file, reads the bytes, and forwards the contents as a string inside a tool_result field, nested inside a messages array, inside a JSON body headed to an API endpoint. There is no attachment. No filename crosses the wire as a distinct object. No MIME type says "this is a document." What crosses the wire is prose, formatted exactly like every other piece of conversational text in that request. From the perspective of a system built to recognize file transfers, nothing happened, because nothing that looks like a file transfer happened.

The traffic itself gives you almost nothing to work with

Say your organization does have TLS-inspecting infrastructure in place, so payload content isn't hidden behind encryption. You still run into three compounding problems.

The destination is pre-trusted. Most CASBs and secure web gateways classify traffic by destination domain. A connection to api.anthropic.com gets mapped to "Anthropic" or "approved AI vendor" and, in many configurations, that classification is itself the reason the traffic is allowed to flow without deep inspection: the domain is reputable, the vendor is contracted, the traffic is "trusted." That trust is exactly what makes it invisible. Knowing which vendor a connection went to tells you nothing about what was inside the request.

The payload doesn't match what pattern-matching was tuned for. Classic DLP content inspection is built around recognizing patterns in structured or semi-structured documents: an SSN format in a spreadsheet cell, a credit card number in an email body. An SSN sitting inside an escaped string, three levels deep in a JSON array, surrounded by thousands of tokens of system prompt, tool schema definitions, and unrelated conversation history, is a much harder needle to find in a much bigger haystack, and it's not the shape of haystack most rule sets were written against.

The classification label doesn't survive the trip. Enterprise data governance leans heavily on labels: a file tagged "Confidential" in a document management system, a database column flagged as PII. Those labels travel with the file as long as it stays a file. The instant an agent reads that file's contents and re-expresses them as freeform text in a prompt, the label is gone. The bytes changed form. What used to be "a Confidential-labeled Word document" is now "a paragraph," and paragraphs don't carry metadata.

What the log actually shows you

It's worth looking at what a security team would actually see if they went hunting for this after the fact. Here's a representative entry from a proxy or CASB log for the exact request that carried the Career Notes file contents out:

2026-08-27T14:12:03Z  10.0.4.112  TLS1.3  api.anthropic.com:443
 method=POST  path=/v1/messages  status=200  bytes_out=4812  bytes_in=1103
 user=john@company.com  app=Claude (approved)  category=AI/Productivity

Every field in that line is unremarkable. The status code is a success. The destination is an approved, categorized application. The byte counts are unremarkable for a chat request with some file content included. There is no field for "contained an SSN." There is no field for "the file this text originated from was labeled Confidential." A security analyst reviewing this log has no reason to open it, and even if they did, there's nothing in the log itself pointing them toward the one request, out of thousands that day, that mattered.

This is the mechanism behind what industry researchers have started calling the AI visibility gap in security operations: not that the traffic is hidden, but that it looks exactly like every other successful, sanctioned use of an approved tool (Dark Reading, Why Your DLP Can't See Shadow AI Threats). As one industry analysis of the gap put it plainly: from a legacy DLP system's perspective watching an employee paste content into a browser-based AI tool, "no file is involved, no email is sent, no policy is violated in the traditional sense... nothing happened" (Cyberhaven, Generative AI & DLP: Why Legacy Security Tools Fail).

Agent traffic is a harder version of the same problem

Everything above applies to a human pasting text into a browser-based chat window. Agent traffic makes the problem worse in two specific ways.

There's no human moment of decision to instrument around. Browser-focused monitoring tools can, in principle, watch a paste event into a known chat UI and flag it. An agent reading a file and forwarding its contents happens programmatically, inside an API call issued by client software, with no browser DOM event to hook into at all. The entire perceive-serialize-think-act loop we described in our piece on agent architecture happens between processes, not between a human and a text box.

The request is bidirectional, and only one direction was ever monitored. Legacy DLP was built around a one-way threat model: sensitive data leaving the organization. An agent's response, the next tool call it decides to make, is also a data flow, and it's one that can act on what it just read: drafting a document from it, sending it somewhere, storing it in a new location. A defense built to watch the front door doesn't help once the thing that walked through it starts moving around inside the house.

Why "just add more inspection" doesn't close this

The tempting fix is to bolt AI traffic onto the existing DLP pipeline: route it through the same TLS-inspecting proxy, apply the same regex rule sets, log it to the same SIEM. This helps marginally and doesn't solve the structural problem, for the same reason described above: the rules were written for documents and attachments, and what's flowing through this channel is neither. Tuning a regex library to also scan JSON request bodies catches some obvious cases (an unmistakable SSN pattern) and misses the much larger category of content that's sensitive by context rather than by format: a customer's name next to their diagnosis, a term sheet's numbers without a label saying "term sheet," a caregiving-leave explanation that reads as ordinary prose with nothing pattern-matchable in it at all. The Career Notes file from our first post is a good test case here: most of what made it damaging (a candid reason for leaving a job, an unrecorded medical leave explanation, a salary floor) wouldn't trip a single regex rule, because none of it looks like a credit card number. It's just true, specific, and never meant to leave the building.

What actually has to change

The throughline across this whole series points at the same answer. Guardrails that matter have to live at the layer where the decision to serialize content actually happens, not at a network chokepoint downstream that only ever sees the aggregate result. That means visibility and control need to sit inside the agent's own request and tool-call path: seeing what's about to be read, what's about to be sent, and to which destination, before it's flattened into an indistinguishable JSON body and handed to a trusted domain. A network appliance watching encrypted, pre-approved, structurally unremarkable traffic after the fact was never going to be the layer that catches this. The traffic isn't hiding. It's just successful.

Further reading:

This piece is part of our ongoing research into how agentic AI systems are actually built and where their behavior comes from.

Get started

Understand your AI risk.  Prevent data exposure.

Stay updated
with Verax insights

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.