Decide where sensitive data may go before it is in a prompt.
Traditional DLP inspects traffic at the network edge and guesses at content. In an AI system the riskier moment is earlier: when retrieved records are assembled into a prompt for a specific model, or handed to a tool. Control enforces egress rules there, using labels applied at ingest.
Every way data leaves an AI workflow.
DLP in Control is enforced at each of these points by the same policy engine, so one rule covers all of them.
| Egress path | Example | Where it is enforced |
|---|---|---|
| Prompt to a model endpoint | Retrieved patient notes assembled into a prompt for a hosted model | AI gateway, before the request is sent |
| Agent tool call | An agent passes customer records as arguments to an external ticketing tool | MCP gateway, on tools/call |
| Export | A user asks an assistant to produce a CSV of account balances | Policy on the export action |
| Connector write-back | An agent writes summarized data into a less restricted system | Connector enforcement point |
| Response to a user | An answer would include content the user cannot open in the source | Permission-aware retrieval excludes it before generation |
Filter at retrieval instead of scrubbing at the edge.
Pattern-matching DLP on outbound text has two well-known failure modes: it misses sensitive content that does not look like a pattern, and it blocks harmless content that does. Both get worse when the outbound text is model-generated and paraphrased.
Control relies on labels assigned when data was ingested, by classifiers and confirmed by data owners, and carried with every chunk and record. When a request is headed to a destination that is not approved for a label, content with that label is not retrieved for it in the first place, or the request is denied or held for approval. The decision is made on known metadata, not on a guess about free text.
Rules written against labels and destinations.
Destinations are identities too. A policy can state that a label may reach only private endpoints, or only with approval, independent of which user or agent is asking.
id: pol_dlp_001
description: Regulated data stays on private models
subject: { any: true }
resource: { model_endpoint: { approval: external } }
action: [send]
when:
content.classification: { any_of: [PHI, PII, privileged] }
effect: deny
explain: "Regulated content may only be processed by private models."Illustrative example · final API surface documented in /docs
Designed to be tuned, not just switched on.
Simulate first
Run proposed egress rules against recorded request patterns in the simulator to see what they would block before enforcing them.
Explain denials
Users get the policy ID and a plain-language reason, which cuts down on tickets asking why an answer was refused.
Custom labels
Define labels for what matters in your business, such as deal codes or matter numbers, and write egress rules against them.
Reviewable trail
Allowed and denied egress events are in the audit log with label, destination, and identity for periodic review.
Edge DLP and AI-path DLP answer different questions.
| Question | Pattern-matching DLP at the edge | Label-based egress policy in Control |
|---|---|---|
| What is inspected? | Outbound text and files as they cross the network | The labels and destination of a request before content is assembled |
| How is sensitivity known? | Regular expressions and fingerprints at send time | Labels applied at ingest and confirmed by data owners |
| Paraphrased model output | Often missed, because it no longer matches a pattern | Not relevant; the labeled source content was never retrieved for that destination |
| Who is asking? | Usually a device or network address | A user, agent, service account, or model identity, including delegation |
| Possible outcomes | Block or alert | Allow, deny, exclude content, or hold for approval with a reason |
Introducing egress rules without breaking work.
- 1
List destinations
Register every model endpoint and tool that can receive data, and mark each one private, internal, or external. Unregistered destinations are unreachable.
- 2
Label the sources
Make sure the sources behind your first use cases have confirmed labels; rules written against labels are only as good as the labels.
- 3
Write the hard boundaries
Start with a small number of explicit deny rules, such as regulated labels never reaching external endpoints, so later allows cannot erode them.
- 4
Simulate and review
Run proposed rules through the simulator against realistic requests and walk the expected denials through with the teams affected.
- 5
Enforce, then refine
Turn rules on, watch denials by label and destination, and add approval paths where a legitimate need keeps getting blocked.
External model endpoints start disabled.
A new deployment can only reach private models served on your hardware. Enabling an external endpoint is an explicit, reviewed change, and egress policies decide what may be sent to it.
Questions buyers ask
Does this replace our existing DLP product?
No. Network and endpoint DLP still cover email, browsers, and devices. Control covers the AI-specific paths, such as prompts, agent tool calls, and exports through AI tools, where it has context those products lack.
What if classification misses something?
Classification is never perfect, which is why labels are reviewed by data owners and why the safest default is to keep regulated sources on private models entirely. Egress rules can also be set at the dataset level, not only per field.
Can we redact instead of block?
The primary mechanism is exclusion: labeled content that is not permitted for a destination is not retrieved for that request, so the rest of the answer can still be produced. Whether a full deny or approval is required is set in policy.
Are model responses inspected too?
Responses are recorded in the audit log in your environment. Because retrieval is already permission- and label-filtered, a response can only draw on content the request was allowed to use.
What about data a user pastes directly into a prompt?
Pasted text has no ingest label, so label-based rules cannot see it. The practical controls are destination rules, such as keeping certain teams or applications on private models only, plus the edge and endpoint DLP you already run.
How do we handle a destination that is missing from the request?
Write the rule explicitly. In the policy language a missing value fails every comparison except an exists check, so a deny for requests without a known destination is a one-line condition, and default deny covers the allow side.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.