AI data loss prevention: keeping sensitive data out of LLM prompts
Card numbers, credentials, customer records and source code end up in prompts. How data loss prevention for LLM traffic works and how to roll it out.
By Tessarac · Published · 4 min read
Every prompt sent to a hosted model leaves your environment. Most of the time that is the point. Some of the time the prompt carries something that should not leave: a customer’s card number pasted into a support summary, an API key in a stack trace someone asked a coding assistant to explain, a patient’s details in a note, a chunk of proprietary source code.
None of that requires a malicious user. It is what happens when people and pipelines use AI for real work. Data loss prevention (DLP) for LLM traffic inspects prompts on their way to the model and acts on sensitive data before it leaves.
Why prompts need their own controls
Traditional DLP watches email, file uploads and endpoints. LLM traffic looks different:
- It is API traffic from applications, agents and coding tools, not just people in a browser.
- The sensitive data is inside free text, mixed with everything else.
- The volume is high, and latency matters: a scanner in the request path has to be fast.
- The same data can leave through many providers, each with its own retention and training terms.
The natural place to inspect it is the one point every request already passes through: a gateway in front of the models.
What to detect
Sensitive data falls into three groups, and each needs a different detector.
Exact, structured data. Card numbers, national ID numbers, bank routing and account numbers, IBANs, live API keys and secrets. These have formats and often checksums, so they can be detected precisely with very few false positives. They are good candidates for blocking outright.
Personal data in free text. Names, email addresses, phone numbers, postal addresses, IP addresses, health information. Detecting these needs named-entity recognition, which is probabilistic. Start by recording what is found, measure the false-positive rate on your own traffic, then decide what to mask or block.
Your own confidential material. Project code names, internal terms, and the contents of your private repositories and documents. Nothing generic knows these. Detection works from a dictionary you supply, and from fingerprints of the sources you want to protect, so that a slightly edited copy still matches.
What to do when something is found
| Action | Effect | Use it for |
|---|---|---|
| Audit | The prompt goes through; the finding is recorded | Rolling out a detector and measuring before enforcing |
| Mask | The value is replaced with a placeholder before the prompt leaves | Data the model does not need to see to do the task |
| Route | The request may only be served by platforms you approve, such as your own cloud account | Material that may be processed, but only in specific places |
| Block | The request is refused and never reaches a model | Exact data with no legitimate reason to be in a prompt |
A sensible rollout: switch every detector on in audit mode, review a week or two of findings, then move the exact-data types to block and the free-text types to mask where the findings justify it. Apply stricter rules to the teams and applications that handle the most sensitive data.
Design questions to ask of any AI DLP
Where do the detectors run? A DLP service that sends your prompts to yet another third party for scanning has moved the problem, not solved it.
Do the records contain the values? A finding should record the type, the confidence and the position, never the sensitive value itself.
What happens when the scanner is down? A scanner outage should fail closed for anything you rely on DLP to stop, with an explicit option to fail open where availability matters more.
What is stored afterwards? If conversations are kept for review or sent to an observability tool, an audit-mode finding means the value is in that copy. Data that must never be kept should be masked or blocked, not audited.
Does it scan responses as well as prompts? Knowing what models send back is useful for reporting, even if you only enforce on the way in.
Can rules differ by team and application? A data science team and a customer-support bot do not need the same policy.
Alongside DLP, screen prompts for prompt-injection attempts: instructions hidden in user input or retrieved documents that try to override the system prompt or extract it.
DLP in the Tessarac AI Cost Optimizer
The AI Cost Optimizer includes DLP in the gateway, in three layers: exact data (cards, US Social Security numbers, routing numbers, IBANs, live secrets and API keys), free text (names, email addresses, phone numbers, mailing addresses, IP addresses, medical terms and your custom dictionary), and protected sources (fingerprints of GitHub or GitLab repositories you connect). Each data type can be audited, masked or blocked (and protected sources and policy rules can also restrict a request to platforms you approve), with policy rules per team, person or application. Nothing is scanned until you turn a data type on, every detector runs inside the ACOG deployment, and detection records never contain the values found. Prompt-injection screening is on by default in log-only mode. See the AI data loss prevention page and the DLP documentation.