If your organisation deploys data loss prevention tools — and most do — you may assume you have meaningful protection against AI-related data leakage. That assumption is almost certainly wrong.
Traditional DLP was designed around a well-understood problem: structured data, identifiable by pattern, moving across defined channels. AI exfiltration breaks every one of those assumptions. Understanding why requires looking at both how DLP works and how AI data exposure actually happens.
How traditional DLP works
DLP tools operate on three core mechanisms.
Pattern matching. The engine scans content for fingerprints of sensitive data — credit card numbers, SSNs, IBAN formats, file hashes, document fingerprints. If the outbound traffic matches a rule, the transfer is blocked or flagged.
Channel monitoring. DLP agents monitor known egress paths: email, file uploads, web form submissions, USB transfers, clipboard operations. They sit on known channels and intercept traffic that matches a policy.
Classification labels. Many enterprise DLP deployments integrate with file classification tools (Microsoft Purview, Titus, Boldon James). Classified documents carry labels; DLP enforces rules based on those labels when documents move.
These mechanisms work well for their intended purpose. A DLP rule that prevents an employee from emailing a document labelled “confidential” to a personal address, or uploading an SSN-containing CSV to an unsanctioned cloud service, does its job.
The problem is that AI prompts are none of those things.
Three ways AI exfiltration breaks the DLP model
1. Sensitive content is unstructured and contextual
An employee pasting internal deal terms into ChatGPT to draft an executive summary is sending sensitive data to an external model. That content does not contain a credit card number. It does not match a regex pattern. It may not even be in a classified document — it might be typed from memory, copied from a Slack message, or synthesised from multiple sources.
Traditional DLP has no way to evaluate whether a block of unstructured text contains proprietary strategy, client details, or material non-public information. The engine reads characters; it cannot read meaning.
The exfiltration risk from AI prompts is semantic, not syntactic. A DLP system that cannot reason about the meaning of a prompt cannot protect against this class of data exposure.
2. The AI channel does not look like a data transfer
When a developer uploads a file to S3, that looks like a file transfer. When an employee sends an email with an attachment, that looks like email. When the same employee submits a prompt containing internal project plans to Claude via a browser extension, that looks like a web POST request to an API endpoint.
Most DLP agent configurations do not have specific policies for AI model API endpoints. And even when they do — blocking api.openai.com at the network layer, for instance — the approach fails quickly. Enterprise browser extensions, local model runners, VPN-bypassed mobile devices, and the proliferation of AI features baked into existing SaaS tools mean the channel surface is impossibly wide for network-layer blocking to cover.
Blocking every AI API endpoint is also the wrong policy goal. The objective is not to prevent AI use — it is to ensure that AI use does not exfiltrate data you do not want exfiltrated. Those are different problems.
3. Agents create a new exfiltration surface entirely
When employees build or use AI agents — retrieval-augmented workflows, autonomous assistants, Copilot-style integrations — the data flow changes in a fundamental way.
A traditional DLP scenario involves a human deciding to transfer data. There is a discrete moment of intent and action. An AI agent can retrieve, synthesise, and exfiltrate data across thousands of API calls per session, with no human reviewing individual requests. The agent may be accessing an internal knowledge base, a CRM, a code repository — pulling fragments of sensitive information into context windows that are then sent to an external model endpoint.
This is not a scenario DLP was designed for. There is no “transfer event” to intercept. The data moves continuously, in fragments, through a system that looks to the network layer like authorised application traffic.
What AI-native DLP actually looks like
Addressing AI data leakage requires controls that operate at the right layer — between the application and the model, at the prompt and response level, not at the network perimeter.
Prompt-layer inspection. An AI-native control plane intercepts outbound prompts before they reach the model API. It can evaluate the prompt content against policies that go beyond pattern matching: redacting specific entity types (names, account numbers, internal project codes), enforcing category-level rules (“no client data in prompts to uncontracted models”), and applying contextual classification to unstructured text.
This is fundamentally different from network DLP. The inspection happens at the semantic layer, not the traffic layer.
Model and endpoint allowlisting. Rather than trying to block every AI endpoint, an effective control plane defines which model APIs are approved for which use cases — and which are not. A developer can use an approved API with enterprise data processing terms; a consumer ChatGPT endpoint can be blocked or restricted to non-sensitive prompts. Enforcement is at the request layer, not the DNS layer.
Response filtering. AI-native DLP operates in both directions. A model response containing credential patterns, internal PII exfiltrated via indirect injection, or a hallucinated document that resembles a real internal artefact can be intercepted and redacted before it reaches the user.
Agent-level policy. For AI agents and automated workflows, governance requires a different model entirely: defining which data sources a given agent is permitted to retrieve from, which model APIs it can call, and what categories of information can enter the agent’s context window. This is access control applied at the AI workload layer — closer to IAM than to traditional DLP.
Audit trail. Every prompt, response, and blocked transfer is logged in a tamper-evident record that includes the actor, the session, the model endpoint, and the policy decision. This is the evidence layer that satisfies SOC 2, ISO 27001, and emerging AI-specific audit requirements.
Deployment priorities: where to start
For most organisations, the practical priority order is:
-
Visibility first. You cannot write effective policy without knowing what is actually happening. Deploy monitoring that gives you a full map of which AI tools are in use, which model endpoints are being called, and what categories of data are entering prompts. This inventory is the foundation.
-
Redact before you block. Outright blocking tends to drive users toward workarounds. A control that redacts sensitive entity types from prompts while allowing the workflow to proceed maintains productivity while reducing exposure. Start here.
-
Enforce approved model lists. Define a positive allowlist of model endpoints that meet your data handling requirements, and route all AI traffic through the control plane. Restrict uncontracted consumer endpoints for sensitive-data use cases.
-
Apply stricter controls to agents. Automated AI workflows deserve the most restrictive controls, because there is no human in the loop to catch a mistake. Constrain data source access to what each agent actually needs; apply session-scoped credentials that expire when the task ends.
How Qadar’s Shield suite addresses AI DLP
Qadar Shield is designed around the prompt-layer control model — operating at the layer where AI exfiltration actually happens.
Shield Web intercepts prompts from browser-based AI tools — ChatGPT, Claude, Gemini, AI-enabled SaaS — and applies configurable redaction and policy enforcement before the request leaves the browser.
Shield Desktop governs AI tool usage on managed endpoints: desktop AI clients, IDE-embedded copilots, locally running models. Policy enforcement happens at the application layer, independent of network path.
Shield Mobile extends the same control plane to iOS and Android, addressing field teams and BYOD environments where mobile AI usage is growing fastest.
Shield Control is the central policy and audit layer: model allowlists, entity-type redaction rules, agent data source permissions, and a complete audit log of every AI interaction across all surfaces.
Together, the four layers cover the full AI data surface — not just the browser, not just the managed endpoint, but everywhere AI tools operate in your organisation.
Want to see how Shield handles your specific AI tooling stack? Book a technical walkthrough