LLM Data Security: Five Places Enterprise Data Moves and Which Ones You Can Control
Enterprise data reaches a model through five distinct paths: a user pasting into a prompt, an application assembling context programmatically, a retrieval system injecting documents, a tool call returning results mid-loop, and training or fine-tuning. Each path has a different owner and a different control point. This walks all five, marks which are governable at the HTTP request layer, and explains why prompt-time classification is the one that cannot be substituted.
Zscaler's ThreatLabz 2026 AI Threat Report measured 18,033 terabytes of enterprise data moving into AI tools, a 93% year-over-year increase, alongside more than 410 million ChatGPT DLP policy violations (Infosecurity Magazine, June 17, 2026). The volume is worth pausing on, and the more useful question is how that data got there, because the answer is five separate mechanisms with five separate owners.
Teams that treat LLM data security as one problem end up with one control covering one path. I want to walk each path, name where it can be governed, and say plainly which ones sit outside an HTTP control point.
Path 1: A person pastes it
The largest volume and the least structured. An employee copies a spreadsheet range, a customer email thread, a block of logs, or a contract clause into a chat interface. 78% of employees use unauthorised AI tools at work and 77% of those admit to pasting sensitive business data into unsanctioned models (Cloud Radix).
The content is assembled by a human in real time, so nothing upstream reviewed it. Data classification applied at rest in a document store says nothing about what a person selected and pasted at 4pm.
Control point: the HTTP request to the model endpoint, where the assembled prompt is visible and classifiable before it reaches a provider. Network DLP running below TLS records an outbound connection and reads none of the payload. The distinction is worked through in AI DLP vs traditional DLP.
Path 2: An application assembles it
A service builds a prompt in code: a template, plus fields pulled from a database, plus the user's input. This path is more predictable than pasting and it moves higher volumes, because it runs on every request the feature serves.
The failure is scope creep in the template. A summarisation feature ships pulling three customer fields, and eight months later a developer adds the full record because a downstream prompt needed one more attribute. The change passed code review as a one-line diff. Nobody outside that team knows the data sent to an external provider expanded.
Control point: enforceable at the request layer, and worth noting that this is precisely where an application-side validator falls down. A validator lives in the same repository as the template, so the same commit can widen the data and relax the check.
Path 3: Retrieval injects it
A RAG pipeline retrieves documents by similarity and places their contents into the context window. The user asked a question and the system decided which documents to include, which means the data in the prompt was selected by a vector search rather than by a person.
Two things go wrong. The index is built over a corpus with mixed sensitivity and the retrieval step has no notion of the requesting user's entitlements, so a query from someone in marketing pulls a passage from an HR investigation because it scored well on similarity. Separately, a document in the corpus can carry injected instructions that reach the model as trusted context, covered in RAG prompt injection.
Control point: split. Entitlement-aware retrieval belongs in the pipeline, filtering the index by the requesting identity before ranking. What was actually injected into the prompt is visible at the request layer, and that is where the record of it gets written. The pipeline design is in RAG security architecture.
Path 4: A tool call returns it mid-loop
An agent calls a tool, the tool returns rows from a database or the contents of a file, and that output is appended to the context and sent back to the model on the next iteration. Nobody typed this data and no template specified it. The agent selected the tool and the tool decided what to return.
This path produces the widest gap between intent and outcome, because the data reaching the model on call 14 is a consequence of choices made on calls 1 through 13. Each individual call looks reasonable.
Control point: two layers, and only one of them is HTTP. What the tool is permitted to return is a credential scoping problem enforced by the database grant, the IAM role, or the filesystem permission. A read-only connection to three tables cannot return the fourth, whatever the agent asks. What then travels to the model is visible at the request layer. Scoping the credential is the stronger control and it does not live at a gateway, which is worth stating rather than implying otherwise.
Path 5: Training and fine-tuning
Data assembled into a training or fine-tuning corpus. Different lifecycle, different risk: data that enters model weights cannot be retracted per-record, and provider terms determine whether prompts from ordinary inference also enter training.
Control point: the data pipeline and the provider contract. This path sits outside anything an HTTP proxy observes, except for the contractual question of which endpoint tier your traffic uses, since consumer tiers commonly permit training use where enterprise tiers exclude it. Choosing the endpoint is a data security decision.
Where the paths land
Four of the five paths converge at the same place: an HTTPS POST to a model endpoint carrying a context window. That convergence is the reason prompt-time classification cannot be substituted by controls further upstream. Whatever assembled the content, the content is complete and inspectable at that one point, and only at that one point.
The control I see skipped most
Egress constraint. Classification at the request layer is only as complete as the traffic that traverses it, and a laptop with an API key and open outbound access has a route that no policy covers. Denying direct egress to provider endpoints from application and workstation tiers, leaving one allowed route, is what converts a good control into a complete one.
It is a firewall change rather than a security product, and it is more consequential than most of the products. Details in AI egress control implementation.
Blocking is the wrong default
The instinct after reading the Zscaler volume figures is to block the AI tools. Organisations that tried it in 2024 mostly learned that usage moved to personal devices and personal accounts, where visibility drops to zero and the data still leaves. I would rather see a sanctioned path with classification and records on it than a ban with a shadow path underneath. That opinion has cost me a few arguments with security teams who wanted the cleaner-looking policy.
DeepInspect
This is exactly what DeepInspect does. Four of the five paths above converge on an HTTP request between an authenticated caller and a model endpoint, and DeepInspect sits inline at that boundary.
For every request, DeepInspect binds the call to the identity the caller presents, classifies the assembled prompt against your own data classes, evaluates identity-aware policy, and makes a deterministic fail-closed decision before the content reaches the provider. Classification runs on the actual context window, so a pasted ticket thread, a widened application template, and a retrieved document passage are all evaluated as what they are rather than as what a source system was labelled months earlier. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the calling application never controls. DeepInspect governs the traffic to the model and leaves credential scoping, index entitlements, and training pipelines to the systems that own them. If your DLP is running below TLS and your prompts are invisible to it, book a demo today.
Frequently asked questions
- Can traditional DLP inspect LLM prompts?
Not in the deployments most enterprises run. Network DLP operates below TLS and sees an encrypted connection to a provider domain without reading the payload. Inspecting prompt content requires terminating TLS for those destinations and parsing the request body, which is a different architecture from pattern-matching on file transfers and email.
- What is the biggest LLM data security risk?
Volume through the unstructured path. Zscaler's ThreatLabz 2026 report measured 18,033 TB of enterprise data moving into AI tools, up 93% year over year, most of it assembled by people in real time rather than by reviewed application code. That path has no upstream control, which is why classification has to happen on the prompt itself.
- Does using an enterprise AI tier solve data security?
It addresses the contractual half. Enterprise tiers commonly exclude prompt data from training and offer retention controls, which matters for path 5. What data leaves your environment, under which identity, and whether it was permitted stays an enforcement question that the contract does not answer.
- How do you stop sensitive data reaching a model?
Constrain egress so every model call has one route, classify the assembled prompt at that route against your own data classes, bind the decision to the calling identity so policy can differ by role, and record each decision outside the calling application. Blocking access to AI tools outright tends to relocate the traffic to personal devices, where nothing is visible at all.