Why can't our existing DLP handle AI prompts from analysts?

Because DLP inspects a layer the prompt does not travel in. Network DLP classifies documents and reads traffic beneath TLS, while an analyst's prompt is an encrypted API payload containing a context window. The appliance sees an HTTPS call to a provider and cannot read the rows inside it unless TLS is terminated for that domain and the body is parsed. The data that leaves is invisible to the tool most teams assume is covering it.

What is the highest-risk pattern for a data team?

Pasting raw query output into a model for a quick explanation. The analyst wants a summary and the prompt carries the underlying identifiers along with it, sending regulated records to an external model with no attribution or record. It is routine, it feels harmless, and it is the exact motion that turns a copilot into an unmonitored exfiltration channel.

How does per-analyst identity change anything?

It makes the model call attributable and policy-aware. With a shared workspace key, every prompt looks identical at the model boundary, so nothing distinguishes an analyst cleared for regulated data from one who is not, and no audit can name who sent what. Binding each call to the analyst identity lets policy reflect clearance and gives the audit record a person, which is the precondition for governing the traffic at all.

Does this replace warehouse access controls?

No. Warehouse access control and row-level security decide what an analyst can query, which is a separate and necessary control. The gateway governs what leaves for the model once the analyst has the data in hand. An analyst with legitimate access to a regulated table can still paste it into a prompt, and the gateway is what classifies and records that model call. The two controls cover different points in the path.

AI Security for Data Teams: Governing What Analysts Send to the Model

A data team uses AI by moving data into prompts. An analyst asks a copilot to write the SQL, pastes a block of query output and asks the model to explain it, or drops a sample of rows into a notebook assistant to check a transformation. Each of those is an HTTPS POST to a model endpoint, and the body carries schema, values, and sometimes the regulated records the warehouse exists to protect. The answer is useful. The request is data leaving the environment through a channel most controls were not built to watch.

Cloud Radix found that 77% of employees using unauthorized AI admit to pasting sensitive business data into unsanctioned models, and Netwrix found that only 37% of organizations have any detection or governance policy for AI usage at all. Data teams sit at the center of that gap, because their daily work is handling exactly the data that should not leave unmonitored.

Why DLP does not see this traffic

Network DLP inspects traffic below the TLS layer and classifies documents. An analyst's prompt to a model is an encrypted API call whose payload is a context window, not a file. The DLP appliance sees an HTTPS connection to a provider domain and the prompt content stays invisible unless TLS is terminated for that domain and the API body is parsed and classified. The data that matters, the rows and identifiers inside the prompt, travels in a layer legacy DLP was not built to read. This is the difference between AI DLP and traditional DLP, and it is why a data team can be fully covered by DLP on paper and still exposed on every model call.

Draw the boundary around the model call

A gateway governs the HTTP traffic between the analyst's tools and the model. It does not govern the warehouse or the notebook kernel.

Inside the boundary:

The call to the LLM from a copilot, notebook assistant, or BI tool, carrying the prompt.
The model's response returning to the tool.

Outside it:

The warehouse's own access controls and row-level security. Those decide what the analyst can query in the first place.
Code the notebook kernel runs locally on the analyst's machine.

The gateway controls what leaves for the model and who sent it. Warehouse access control decides what an analyst can pull, and both are needed.

Bind each call to an analyst identity

The common pattern gives a shared workspace or a service account one key to the model. Every analyst's prompt reaches the model as that credential, so an audit cannot attribute a leaked customer table to the analyst who pasted it. Route calls through the gateway and bind each to the analyst identity the tool already authenticates. Policy can then reflect what a given analyst is cleared to handle, and every prompt carrying regulated data names a person.

Classify regulated data in the prompt

An analyst rarely intends to send a full column of identifiers to a model. It happens because a query result pasted for a quick explanation carries more than the question needed. The gateway classifies the outbound prompt against regulated data types, PII, PHI, NPI, and applies policy on the class, so a call asking the model to explain an aggregate is allowed while a call carrying raw identifiers is redacted or blocked. Classification runs on the actual prompt, which is where the data exfiltration risk lives, rather than on a dataset labeled once at rest.

Constrain egress and record every decision

Restrict egress from the notebook and BI tiers so the only route to any model endpoint runs through the gateway, which keeps an analyst from configuring a personal key that skips policy. Every call then produces a decision record: the analyst identity, the data class in the prompt, the outcome, the policy version, and a timestamp. The record commits before the response returns, on a write path the analyst's tool does not control, so a later review can say which analyst sent which class of data to which model. That is the evidence a self-written application log cannot provide.

DeepInspect

This is the problem DeepInspect was built to solve. A data team's tools send regulated data to LLMs over HTTP, and DeepInspect sits inline at that boundary between those tools and the model endpoints they call.

For every request, DeepInspect binds the call to the analyst identity the application supplies, classifies the prompt against regulated data types, applies per-role policy, and makes a deterministic, fail-closed decision before the data reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the tool never controls. DeepInspect reads the prompt content that DLP runs underneath, and it governs the model traffic rather than the warehouse access controls that decide what an analyst can query. If your data team is pasting query results into models and you cannot see what left, let's talk today.