Answer box
AI DLP (AI data loss prevention) is the data-protection control layer that inspects content as it enters and leaves AI workloads — covering the prompt, the response, retrieved RAG context, and tool-call arguments. It exists because traditional DLP cannot see the content that now flows through conversational interfaces, browser-resident copilots, and agentic tool chains. If your sensitive data leaves the company through a textarea instead of an attachment, AI DLP is the control that catches it. Everything else — network DLP, endpoint DLP, CASB — is blind to that surface.
Cyberhaven's 2024 telemetry across enterprise endpoints found that 4.2% of paste events into GenAI tools contained PII and 11% contained material classified as sensitive by the originating company. That traffic does not cross any of the inspection points legacy DLP was designed for. AI DLP is the answer to that gap, and over 2025 it has hardened from a feature into a category — Gartner now tracks it inside both its DLP and AI TRiSM market guides.
The four boundaries an AI DLP must inspect
An AI workload is not a single API call. It is a four-boundary system, and your DLP either covers all four or it covers none of them well. Coverage gaps at any single boundary are the leak.
1. Prompt boundary (user input → model)
This is the boundary everyone thinks of first: a user pastes text into ChatGPT, Claude, Gemini, Copilot, or a custom internal app, and that text leaves your trust boundary. What flows here is unstructured free text plus pasted files, screenshots, code snippets, and increasingly audio and image inputs. What to inspect for: PII, credentials, source code with copyright markers, customer data, M&A materials, board content, and anything tagged sensitive in your enterprise corpus. The inspection has to happen before the prompt reaches the model provider — once it's in the vendor's logs, you've already lost the control point.
2. Response boundary (model output → user / downstream system)
The forgotten boundary. Models hallucinate confidential-looking content, regurgitate training data, and increasingly inherit context from RAG that the requesting user shouldn't have. Microsoft's own documentation on 365 Copilot's permission model makes this concrete: Copilot surfaces anything a user has technical access to, regardless of whether they should. The response boundary is where over-permissioned retrieval becomes a leak — and where a user discovers content they were never supposed to see. Inspect responses for the same content classes as prompts, plus retrieved-content provenance.
3. RAG retrieval boundary (knowledge base → model context window)
When a model retrieves documents from a vector store, SharePoint index, or Confluence connector, those documents pass into the context window — and from there into the response. Most enterprises have spent zero time inspecting what gets retrieved. The retrieval boundary is where you catch documents that shouldn't have been indexed in the first place, the ones a generous SharePoint permission set let a contractor pull during a finance-team prompt. Inspect for: classification labels, provenance metadata, document age, and content-class signals on retrieved chunks before they hit the context window.
4. Tool call boundary (model → tool → action with real data)
Agentic systems make tool calls. A model decides to query your CRM, call an internal API, write a row to a database, or send an email. The arguments to those tool calls are derived from prompts, RAG content, and prior tool outputs — meaning untrusted content can shape real-world actions. This is the boundary where prompt injection becomes exfiltration: an attacker plants instructions in a document, the model retrieves them, and the model calls a tool with arguments that move sensitive data outside your perimeter. Inspect tool-call arguments for sensitive content and for instruction-injection patterns.
| Boundary | What flows here | What to inspect for |
|---|---|---|
| Prompt | User-typed text, pasted files, images, audio | PII, credentials, source code, customer data, internal docs |
| Response | Model output, citations, retrieved content | Over-permissioned retrieval, hallucinated PII, leaked training data |
| RAG retrieval | Vector hits, SharePoint chunks, Confluence pages | Classification labels, provenance, indexing mistakes, stale content |
| Tool call | Function arguments, API payloads, downstream actions | Sensitive content in args, prompt-injection patterns, scope violations |
How AI DLP differs from traditional DLP — architecturally
If you're tempted to extend your existing DLP to cover AI, read the companion comparison piece first. The short version: the architectures are incompatible at five layers.
Inspection point
Legacy DLP inspects at network egress, endpoint file operations, and email gateways — places where structured artifacts move. AI DLP inspects inline at the prompt and response boundaries, which means inside the browser or SDK before the request leaves and after the response arrives. Anything inspecting only at the network layer sees TLS-encrypted traffic to a vendor domain and nothing else.
Latency budget
Legacy DLP can tolerate seconds. An email sits in a queue; a file upload waits on a scan. AI is conversational, which means a human is staring at a blinking cursor. Sub-50ms p99 inline latency is the budget. Anything slower and users disable, bypass, or route around the control. Vendor-stated latency is irrelevant — only customer-observed p99 metrics matter, measured under your own concurrency.
Content format
Legacy DLP was built for structured documents with predictable formats: spreadsheets, PDFs, database exports. AI DLP must inspect free-text and multi-modal content: a paragraph of customer support notes, a screenshot of a board slide, an audio recording of a sales call, a code snippet with embedded credentials. Pattern rules that worked on field-delimited data don't survive contact with this surface.
Policy expression
Legacy DLP policy is pattern-based: regexes, dictionaries, exact-match fingerprints. That works for credit-card numbers and not much else. AI DLP needs semantic classification with context: the same nine-digit number is a SSN when it appears next to a name and DOB, and a random integer when it appears in a code comment. Policies have to reason about meaning, not match strings.
Audit format
Legacy DLP produces event logs: who did what, when, blocked or allowed. AI DLP has to produce provenance trails with decision rationale: which classifier fired, what content class was detected, which policy version applied, what the model would have seen, what the user actually saw. Auditors under NIST AI RMF and ISO 42001 need decision rationale, not just outcomes.
What an AI DLP actually does step by step
Walk through the lifecycle of a single prompt. The user pastes a paragraph from a customer support ticket into a copilot and asks the model to summarize it.
- Capture. A browser extension or SDK interceptor captures the prompt payload before it is submitted to the model endpoint. The capture happens in-process, not over the network, because TLS to the vendor would block any out-of-band proxy. Capture latency budget: under 5ms.
- Classification. The captured content is passed to an inspection engine that runs pattern detectors, statistical detectors, an ML classifier trained on your enterprise corpus, and a context-aware reasoner. Each detector emits content-class signals: PII present, confidence 0.94; customer record fingerprint match; policy-tagged source-code marker. Classification latency budget: under 30ms.
- Policy decision. A policy engine takes the signals plus context (user role, destination model, requested action) and decides: allow, redact, block, or escalate. A finance analyst summarizing customer feedback gets redaction. A contractor asking the same model the same question gets a block. Decision latency budget: under 10ms.
- Action. If allowed, the prompt is forwarded. If redacted, sensitive spans are replaced with reversible tokens and forwarded. If blocked, the user gets a contextual message explaining why — generic "denied" copy gets ignored or worked around.
- Response inspection. The model's response is intercepted on return, classified the same way, and passed back through the policy engine. Over-permissioned retrieval is caught here. Hallucinated PII is caught here. Reversible redaction tokens are restored for the requesting user only if their role permits.
- Provenance logging. Every decision is written to an audit store with full rationale: input content class, classifier scores, policy version, decision, what the user saw versus what the model saw. This is the artifact auditors actually want — and the artifact your incident response team needs when something does leak.
End-to-end inline latency budget for the whole loop: under 50ms p99. If your DLP adds 200ms on top of model latency, users will route around it within a week.
The seven content classes AI DLP must catch
Coverage breadth is non-negotiable. A control that catches PII but misses source code is a control that catches the easy half. The seven classes you need first-class detection for:
1. PII
Names, emails, addresses, phone numbers, government IDs, account numbers, dates of birth. This is the base case and the easiest. Every credible AI DLP covers it. Note that PII detection in free text needs context — "John" alone is not PII; "John Smith, DOB 1972-04-12" is.
2. Credentials and secrets
API keys, OAuth tokens, passwords, SSH keys, database connection strings, JWT tokens, signing keys. These get pasted into AI prompts constantly — engineers troubleshoot with them. A leaked secret in a vendor's training set is a long-lived blast radius. Entropy-based detectors catch novel secret formats that pattern matchers miss.
3. Source code
Internal source code is IP. Engineers paste it into AI tools to debug and refactor. Detection needs to recognize code by structure and identify proprietary markers — internal package names, copyright headers, distinctive identifier conventions. Generic "this looks like code" is not enough; the question is whether your code is leaving.
4. PHI
HIPAA-covered protected health information: diagnoses, treatment, payment for healthcare, anything tying medical data to an identifiable person. Detection has to reason about combinations, because a diagnosis without an identifier is not PHI, and an identifier without a diagnosis is not PHI — but the two together, even in separate sentences of the same prompt, are.
5. Financial and commercial data
Pre-public earnings, M&A materials, customer pricing, vendor contract terms, win-loss data, pipeline forecasts. This is the content that, if leaked, triggers SEC disclosure obligations and contract breaches. Detection needs fingerprinting against your own corpus, because no pattern matcher knows your pricing structure.
6. Internal documents
Board materials, strategy planning, RIF planning, compensation, performance reviews, legal hold documents, internal-only memos. The content class with the highest reputational blast radius. Detection requires document-level classification labels propagated through your corpus and recognized in pasted excerpts.
7. Regulated communications
Attorney-client privileged content, EU/GDPR-scoped personal data with cross-border implications, export-controlled technical data (ITAR/EAR), MNPI subject to insider-trading rules. These have legal-grade consequences if they leave. Detection needs jurisdictional context — the same content can be allowed for an EU-resident user and blocked for a US-resident user.
Detection methods — how AI DLP actually classifies
Four detection methods, used in combination. No single method covers the surface; ensembles do.
| Method | Strength | Weakness | Best for |
|---|---|---|---|
| Pattern-based (regex, dictionaries) | Sub-millisecond, deterministic, auditable | Brittle on novel formats; high false-positive on free text | Credit cards, SSNs, known token formats |
| Statistical (entropy, n-gram) | Catches novel secrets and unusual content structure | Tunable but noisy; needs threshold work | API keys, high-entropy secrets, code blobs |
| ML classifier (trained on enterprise corpus) | Handles ambiguity; understands context within a span | Needs training data; opaque to auditors without explainability | PII in free text, document-class detection, sentiment |
| Context-aware (intent + RAG + tool call) | Reasons across the whole interaction; required for agentic systems | Higher latency; needs careful policy expression | Multi-turn leakage, prompt injection, scope violations |
Pattern-based detection alone is what legacy DLP does, and it is exactly why legacy DLP fails on AI traffic. Context-aware detection alone is too slow and too opaque for production. The credible stack is all four, with policy expressed against the union of their signals.
Evaluation criteria — what to look for in an AI DLP vendor
The market is full of vendors retrofitting old DLP engines and stamping "AI" on the box. Seven criteria separate the credible from the rebranded.
- Sub-50ms p99 inline latency, customer-observed. Not vendor-stated. Not marketing-deck average. Customer-observed p99 under your own concurrency. Ask for a reference customer's Datadog dashboard. If they can't produce one, walk.
- Coverage of all four boundaries. Prompt, response, RAG retrieval, tool call. Most vendors cover prompt only. Some cover prompt and response. RAG and tool-call coverage is the hard part and the differentiator.
- Browser-resident detection. Network proxies miss browser-only AI traffic, and API gateways miss anything users do in a browser. Detection has to live in the browser via extension or in the SDK via interceptor. See the Copilot vs. ChatGPT leakage breakdown for why this matters.
- Policy versioning and rollback. Policies will be wrong. You need to ship a fix, version it, attribute decisions to a specific version, and roll back without losing audit history. Vendors that hand-edit YAML in a console will not survive your first incident.
- Provenance-grade audit trail. Auditor-ready format with decision rationale, classifier scores, policy version, and the delta between what the model saw and what the user saw. NIST AI RMF and ISO 42001 both require evidence of decision logic, not just outcomes.
- Per-vendor connector model. Copilot, Workspace, Einstein, ChatGPT Enterprise, Claude for Work, and the half-dozen internal apps your platform team is building each have different surfaces. A real AI DLP ships purpose-built connectors per vendor, not a generic HTTP proxy. The Copilot permissions deep-dive shows how vendor-specific this gets.
- Framework auto-mapping. NIST AI RMF, ISO 42001, EU AI Act, SOC 2, HIPAA — controls need to be auto-mapped to framework requirements. Your GRC team is not going to hand-map 300 policies to NIST controls every audit cycle.
For broader category context, the workforce AI security buyer's guide and the AI-SPM buyer's guide cover the adjacent controls. The prompt DLP pillar covers the prompt-boundary subset in depth.
FAQ
Is AI DLP a category or a feature?
It's becoming a category. Through 2024 most analysts treated it as a feature inside DLP or AI TRiSM. Gartner started naming it explicitly in 2025 across both its DLP Market Guide and AI TRiSM Market Guide, and standalone vendor procurement now happens against AI DLP RFPs rather than DLP RFPs with AI add-ons. Expect a dedicated Magic Quadrant within 18 months.
How does AI DLP relate to AI-SPM?
AI-SPM (AI security posture management) is the inventory and posture layer: which AI apps exist in your environment, who uses them, how they're configured, what risks they carry. AI DLP is the runtime data-protection layer: what content moves through them and whether it's allowed. SPM tells you the attack surface; DLP enforces what crosses it. You need both, and they should share a policy and identity backbone.
Can our existing DLP vendor add this as a module?
Some are trying. The retrofit problem is architectural: legacy DLP's inspection points (network, endpoint, email) don't see the AI traffic surface, and its latency budget (seconds) doesn't survive contact with conversational UX. A module that exposes the legacy engine through a proxy will hit the latency wall by the second week of deployment. Purpose-built engines with browser-resident detection are a different design.
Do we need both AI DLP and AI-SPM?
Yes. SPM without DLP gives you a beautifully complete inventory of how data leaks. DLP without SPM gives you runtime enforcement on the apps you know about and zero coverage of the shadow AI usage that drives most exposure. A 2024 enterprise telemetry study found shadow AI tools account for more sensitive paste events than sanctioned ones. SPM finds them; DLP enforces against them.
What's the CapEx vs. OpEx profile?
OpEx-heavy. AI DLP is a SaaS control plane with browser/SDK agents, billed per user per month, typically between $8 and $25 PUPM depending on coverage. Implementation cost is low — connector deployment and policy authoring runs four to six weeks for a 5,000-seat enterprise. The dominant cost is policy maintenance, not infrastructure. Compare against Ponemon's 2024 average breach cost of $4.88M; one prevented leak underwrites several years of license.
What's the typical 30-day result?
For a mid-sized enterprise rolling out across sanctioned AI tools, the 30-day picture looks like: 1.5–4% of prompts flagged sensitive (consistent with Cyberhaven's external baseline), 70–80% of those handled by redaction rather than block, single-digit user complaints about false positives once policies are tuned, and a documented audit trail ready for the first NIST AI RMF or ISO 42001 evidence request. Customers who don't see those numbers in 30 days have a policy problem, not a tooling problem — and that is usually fixable in a week.