AI Data Leakage Prevention: A Practical Guide to AI DLP
PromptGlass Engineering ·
AI data leakage prevention (AI DLP) means finding sensitive information in prompts, pasted text and uploaded files before it reaches an AI tool, then allowing, redacting, coaching or blocking based on policy. It differs from traditional DLP in three ways. The data moves as free-form conversation rather than files or emails. The destination is a fast-changing set of AI apps and APIs. And the right response is often to redact and continue rather than block, because the user’s task is usually legitimate.
How data actually leaks into AI
Most AI leakage isn’t malicious. It happens when people try to get work done:
- Paste-to-summarize. Someone pastes a customer complaint thread, a spreadsheet extract or meeting notes and asks for a summary.
- Debugging with real data. A developer pastes a stack trace that contains a connection string, or a code snippet with a hardcoded API key.
- Upload-to-analyze. A finance analyst uploads a forecast workbook to get a chart and commentary.
- Context stuffing in apps. An internal app built on an LLM API sends whole customer records as context because it was easier than selecting fields.
- Agents with broad access. An AI agent that reads email or files may forward more than intended to the model provider.
Each pattern calls for a different control point and a different response.
Why traditional DLP struggles
Network and endpoint DLP products were designed for files, email attachments and web uploads with predictable structures. With AI they hit several problems:
- Encrypted, streaming, structured traffic. AI web apps send prompts inside JSON over WebSockets or server-sent events. Without understanding each app’s protocol, a generic inspector sees a blob.
- No notion of “the prompt”. Even after decryption, a generic DLP engine doesn’t know which field is the user’s prompt, which is system context, and which is the response.
- Only allow or block. Most legacy DLP can only pass or stop the request. With AI, stopping a legitimate task pushes people to personal devices.
- No identity or app context. Telling a sanctioned enterprise workspace apart from a personal account on the same domain needs AI-specific knowledge.
The building blocks of AI DLP
1. Control points
You need at least one control point that sits before the data leaves:
- A browser extension sees prompts, pastes and uploads in web AI apps and can act inline. It is the best control point for knowledge workers.
- An AI gateway (forward proxy and API mode) sees browser, desktop and API traffic, and can redact, block or reroute it. It is the best control point for APIs and agents.
And after-the-fact sources for coverage and investigation:
- Vendor compliance and audit APIs (ChatGPT Enterprise, Microsoft 365 Copilot and others) for platforms where inline control isn’t possible or necessary.
2. Detection that fits conversation
Good AI DLP layers detection methods:
- Patterns with validators: card numbers with Luhn checks, national IDs with checksum rules, IBANs with mod-97, cloud keys by prefix and entropy. They are fast and precise.
- Dictionaries and proximity: project code names, deal terms, medical vocabulary near a person’s name.
- Exact data match: hashes of your actual records (customers, employees, patients), so a match means real data, not just data that looks similar. Only salted hashes leave your control.
- Code fingerprinting: detects snippets of your proprietary repositories, even after small edits.
- ML classifiers: named-entity recognition for names and addresses, source-code detection, document-type classification for contracts and résumés.
The tiers matter for speed. Cheap detectors run on every request, and expensive ones run only when a policy needs them.
3. Graduated responses
The response should match the risk:
| Situation | Response |
|---|---|
| Credential or private key | Block, alert security, prompt rotation |
| Customer PII in a sanctioned enterprise tool | Allow and log |
| Customer PII in a personal account | Coach toward the sanctioned tool |
| Customer PII in an internal support bot | Redact names and account numbers with tokens, restore them in the response |
| Patient information | Route to the model covered by your business associate agreement |
| Proprietary code in an unapproved assistant | Coach with a link to the approved coding tool |
Redaction with restoration deserves a special mention. The gateway replaces Jane Smith, account AC-10293847 with [PERSON_1], account [ACCOUNT_1] before sending, and puts the real values back in the response the user sees. The model never receives the real values, and the user’s workflow still works.
Designing policies people will accept
- Start in shadow mode. Run every rule in “would have” mode for two weeks. Look at what would have fired, find false positives, and tune them.
- Coach first. A short, specific message (“This looks like customer account data; use Copilot (Acme) for customer work”) with a one-click alternative changes behavior without stopping work.
- Watch override reasons. If people keep overriding a coaching rule with “need to compare with last year’s numbers”, your approved tool may lack a feature.
- Block narrowly. Reserve blocking for classes where any exposure is unacceptable: credentials, regulated health data, card data.
- Fail closed only where it counts. If detection can’t run, for example because of a timeout, should the request go through? For most traffic, yes. For regulated data classes, no.
Don’t forget the response side
Responses can leak too. An AI assistant grounded on internal documents may surface confidential content to someone who shouldn’t see it, or an agent may write sensitive data back into a ticket. Monitor responses for selected apps and data classes, especially retrieval-augmented internal assistants.
Measuring whether it works
Track these over time:
- Sensitive-data events per 1,000 AI interactions, by data class and department
- The share of AI usage in sanctioned tools
- Coaching override rate, and the most common override reasons
- Mean time to rotate leaked credentials
- False-positive rate from analyst triage
A falling rate of sensitive events combined with rising sanctioned usage is the outcome you want: people still use AI heavily, but in the right places, with the right data.
Getting started
Pick one high-value control point, usually the browser extension, and three data classes that keep your security team up at night, usually credentials, customer records and source code. Run them in shadow mode, tune, then coach. Add the gateway for API traffic and redaction once the first rules are stable. AI DLP works best when it is part of the toolset that makes AI safe to use widely, not just a list of things people can’t do.