How does data get exfiltrated through an LLM?

Four ways. A person deliberately pastes sensitive content into a prompt to get work done. An agent's retrieval step pulls records beyond the requester's entitlement into the context window and the model summarizes them into a reply. An attacker plants an instruction in a document or web page the agent reads, and the model follows it, placing target data into an outbound call. Or the model returns content the requester should not receive, from a shared index or from memorized training data. All four are ordinary HTTPS traffic to a provider API, which is what makes them invisible to controls that operate below the TLS layer.

Why can't network DLP detect LLM data exfiltration?

Three reasons, all structural. DLP inspects traffic beneath the TLS session, so an encrypted POST to a provider API is opaque without provider-specific TLS inspection and payload parsing. DLP classifies documents and patterns in streams, and a prompt is an assembled context window rather than a document. And DLP cannot correlate the request to a corporate identity when the call is authenticated with a personal API key or a shared service credential. The result is that the highest-bandwidth egress channel in a modern enterprise reports as ordinary SaaS traffic.

What is the cost of shadow AI data exfiltration?

IBM's Cost of a Data Breach research across 600 breached organizations found that one in five experienced breaches linked to shadow AI, that those breaches cost $670,000 more than the average, that customer PII was exposed in 65% of them against 53% across all breaches, and that they took 247 days to detect. The detection figure is the one that should concern a CISO most: it means the organization is not finding these events, it is being told about them.

Does blocking AI tools prevent LLM exfiltration?

It relocates it. Blocking sanctioned tools at the proxy pushes usage to personal devices, personal accounts, and endpoints the enterprise cannot see, which converts a channel you could have governed into one you cannot. Cloud Radix reports 78% of employees already use unauthorized AI tools, which is what that policy produces at scale. The governable posture is to permit AI use through an enforcement point that classifies the prompt, binds it to an identity, and records the decision, so the traffic stays where policy can act on it.

Can an AI gateway redact sensitive data instead of blocking the request?

Yes, and redaction is usually the right default for the deliberate-paste path. If an engineer pastes a table containing account numbers into a prompt asking for a summary, denying the request teaches them to use a personal account, while redacting the account-number column returns a useful answer with the regulated fields stripped before the payload leaves the perimeter. The redaction is recorded in the decision record, so the audit trail shows what was removed and under which policy. Deny is the correct outcome for classifications that must not leave under any policy at all.

Data Exfiltration via LLM: The Channel Your DLP Was Never Built to See

When an engineer pastes a customer database schema and a sample of rows into a chat interface, the data travels as an HTTPS POST to api.openai.com. Your network DLP sees a TLS session to a well-known SaaS domain, carrying an encrypted payload of a few kilobytes. It records a connection. It has no view of what is inside.

That is the entire problem in one sentence. The LLM prompt is an egress channel that carries arbitrary content, terminates outside your perimeter, and is invisible to the control you bought to prevent exactly this.

Four paths out

The exfiltration paths through an LLM are distinct in mechanism and in who is at fault, and they need to be separated because they fail differently.

Deliberate paste. A person copies sensitive content into a prompt because it helps them do their job. Cloud Radix reports that 78% of employees use unauthorized AI tools at work and that 77% of those admit to pasting sensitive business data into unsanctioned models (Cloud Radix). This is not malice. It is a productivity decision made by someone with no visibility into where the data lands.

Agent retrieval. An agent assembles a prompt from a retrieval step, and the retrieval returns more than the requester was entitled to. The agent had broad read access, the query was a filter rather than an authorization boundary, and the resulting context window now contains records from outside the requester's scope. Nobody pasted anything. The system did it.

Injected instruction. An attacker plants content in a document, a ticket, or a web page the agent reads. The content instructs the model to include specific data in its next call to an external endpoint. This is indirect prompt injection used as an exfiltration primitive, and it is the variant that scales, because the attacker never needs credentials.

Response-side leakage. The model returns content the requester should not receive: another tenant's data pulled from a shared index, memorized training content, or the contents of a system prompt. The egress here is inbound to the user and outbound from your data boundary all the same.

Why the network layer is blind to all four

Three structural failures, and they are properties of where DLP operates rather than gaps in any particular product.

It runs beneath the encryption. The prompt is inside a TLS session to a provider API. Without TLS inspection configured specifically for AI provider domains, and without a parser that understands the provider's JSON payload shape, the content is opaque. Most enterprises have neither.

It classifies documents, not context windows. DLP was built to recognize a file, a record, a pattern in a stream. A prompt is an assembled object: fragments of a retrieved row, a snippet of code, three turns of chat history, and a user instruction, existing for the duration of one request. There is no document to classify.

It cannot correlate identity. An API call authenticated with a personal key or a shared service credential does not map to a corporate identity. Netwrix found that 97% of organizations that suffered AI-related breaches lacked proper access controls for AI services, and that only 37% have any detection or governance policies for AI usage at all (Netwrix).

The cost of the blindness is measurable. IBM's Cost of a Data Breach research, across 600 breached organizations, found one in five experienced a breach linked to shadow AI, that those breaches cost $670,000 more on average, that customer PII exposure rose to 65% in them against 53% across all breaches, and that they took 247 days to detect (IBM). Two hundred and forty-seven days is what "we have no visibility into this channel" costs in practice.

What the wire actually looks like

The exfiltration is not hidden. It is sitting in plain text inside the request body, which is what makes this a solvable problem once you terminate the request.

A control that terminates this request, parses the body, and classifies the content of messages[].content sees the SSNs. It sees them before the request leaves the perimeter. The decision to deny, redact the columns, or route the call to an endpoint covered by a data agreement is available at that moment and nowhere else in the stack.

The control that closes the channel

Four properties, and they have to be present together.

Termination and parse. The enforcement point sits in the request path, terminates the TLS session, and parses the provider payload. Without this, everything else is unavailable.

Prompt-level classification. Classify what is inside the context window rather than what document it came from. Account numbers, PHI markers, credential patterns, and source-code signatures are all detectable in the assembled prompt.

Identity binding. The request carries a verified subject and role, so the policy question becomes answerable: is this person permitted to send this classification of content to this endpoint. Authentication alone answers who is calling. The post-authentication gap is where the authenticated user still sends what they should not.

A per-decision record. What was sent, by whom, under which policy, with what outcome, and what was redacted. Written by the enforcement point rather than by the application, so it survives the application. The EU AI Act's Article 12 requires automatic recording of events over the system's lifetime to ensure traceability, including input data and identification of the natural persons involved (Practical AI Act).

Response-side leakage needs the same four properties applied on the return path, which is why the enforcement point has to be bidirectional. A control that inspects prompts and waves responses through covers half the channel.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between your users and agents and the LLM APIs they call, as a stateless proxy at the AI request boundary. It terminates the request, parses the payload, and classifies the content of the context window. For every request and every response it evaluates identity, role, data classification, model authorization, and organizational policy, then makes a permit, redact, or deny decision before the traffic reaches the model.

Enforcement overhead measures under 50 ms in internal testing, against LLM inference of 500 ms to 5 seconds, so the control stays enabled under load. Every decision writes a signed record carrying the identity, the policy version, the classification, the outcome, and any redactions applied. Because the record is committed by the proxy before the response returns, the application that made the call never has custody of the evidence about it.

If your DLP is reporting nothing on a channel that carries your customer data every day, book an AI readiness assessment.