How do I stop sensitive data leaking to LLMs?
Updated · DBShifts
Short answer
Stop it before it reaches the model. Give agents only the fields their task needs, mask personal data and block secrets on the server that returns the data, apply the same rules to data passed between agents, keep raw data inside your network where you can, and log every read so you can show exactly what left.
Key facts
- Anything returned to an agent ends up in the model's context and may be sent to the model provider.
- Masking has to happen on the server: a model asked to ignore a column still receives it.
- Secrets — keys, tokens, passwords — should be blocked outright, not masked.
- Leakage also happens between agents, when one passes on data it read.
- Detection with fixed patterns and field names behaves the same way every time, which makes it testable.
In the glossary:DLP for AI
Where data leaks to a model
Tool and query results, retrieved documents, messages from other agents, error messages that echo values, and the conversation history a client sends with every request. Each of these is a path into the model's context, and through it to the provider.
Controls, from most to least effective
Do not return what the task does not need: column allowlists beat any redaction. Mask personal data on the server, including where it could leak through filters and aggregates. Block secrets entirely. Apply the same classification to data moving between agents and tools, in both directions. Keep credentials and raw connections inside your network. Log every read, without copying the data into the log.
Why deterministic detection matters
If a model decides what is sensitive, the same row can be masked one day and not the next, and nobody can test it. Pattern- and field-based detection gives the same answer every time, so a security team can review it and rely on it.
Checklist
- 1
Column and field allowlists per agent
- 2
Server-side masking, enforced in filters and aggregates
- 3
Secrets blocked, not masked
- 4
The same rules on agent-to-agent and agent-to-tool traffic
- 5
Credentials and raw connections kept inside your network
- 6
An audit log of reads that does not store the data
Common mistakes
Masking in the prompt
Asking the model not to repeat an email address still gives it the address. Masking belongs before the data leaves the server.
Forgetting filters and aggregates
If an agent can filter on a masked column, it can recover the value from row counts without ever seeing it.
Logging the leaked data
A debug log of full agent traffic creates a second copy of the sensitive data with weaker controls than the first.
How DBShifts does it
- DBShifts Agent Gateway masks personal data on the server, enforced in filters, aggregates and joins, before rows reach an agent.
- DBShifts Agent Mesh classifies data on every handoff between agents and tools, in both directions: emails, card numbers, phone and ID numbers are masked by default, and anything classed as a secret is blocked.
- A self-hosted data plane keeps database credentials and raw connections inside your network.
- Detection uses fixed patterns and field names, not an AI model.
Questions people also ask
Does masking stop agents doing useful work?
Usually not. Most tasks need the shape of the data — counts, statuses, amounts — rather than the exact personal values.
Is this the same as AI data loss prevention (DLP)?
It is the part of DLP that sits in the data path: deciding what may reach a model before it does, rather than scanning for it afterwards.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free28 answers in this series. See all or browse the AI agent glossary.