Data Protection
Check requests for sensitive data before they reach a model
Data Protection checks outgoing requests for personal details and secrets before they leave the machine. A local model does the checking, you decide what happens to what it finds, and what it finds is never stored.
Turn it on once per machine. Then choose where checking applies: every request through a protected preset, only the paths of a Smart Route you pick, or both.
Data Protection requires an explicitly granted Enterprise entitlement.
What gets checked
The check covers the supported text of a request, not only the latest message. Earlier conversation turns, system text, tool inputs, and prompt variables are all in scope.
Every value the check finds is sorted into one kind of detail. The kinds come in three groups: Secrets, Personal details, and Context.
Valid card numbers, IBANs, US Social Security numbers, JWTs, private keys, and known secret prefixes are always caught, and minimum confidence does not apply to them.
A request is checked at most once, even when a preset and a Smart Route path both protect it.
Turn it on
- Open Data Protection.
- Select Turn it on.
- Wait for the privacy model to download. This takes a few minutes and carries on if you leave the page.
When the download finishes, the page shows On. The model runs inside Runtime. No local runtime or provider is needed, and nothing about your requests is sent anywhere to set it up. Setup appears as the Data Protection setup job, which you can follow in Activity.
You can cancel the download or remove Data Protection later. Removing it keeps every protection setting in place. Requests through protected presets are blocked until Data Protection is on again, and protected Smart Route paths follow their own setting for a failed check.
Decide what happens to each kind
For each kind of detail you pick one of three actions:
- Ignore leaves the text in.
- Redact removes the value before the request continues.
- Block stops the request entirely, with the
DATA_PROTECTION_BLOCKEDerror.
The shipped defaults:
| Kind of detail | Ships as |
|---|---|
| Passwords and keys, payment details, ID numbers | Block |
| Health details, contact details, addresses, dates of birth, device and vehicle details | Redact |
| Dates and times, ages, organizations, web addresses, places | Ignore |
Dates and times, ages, organizations, web addresses, and places are ignored by default because the model reads too much into them: a version number can look like a date.
Change any kind under Policy > Kinds of detail. The page carries a live example that follows your saved policy, so you can see the effect of a change before you rely on it. Reset to defaults restores the shipped actions and confidence; rules are kept.
The model also has to be sure enough. Minimum confidence starts at 50 percent. Lower it to catch more, raise it to flag less. Rules and built-in checks are always certain and never filtered by it.
Rules
Rules are patterns you write yourself. A rule's action wins over what the model finds, and an allow rule wins over every other match, so use one to keep text in the request.
Each rule has:
- A pattern, matched as exact text, wildcard, or regular expression
- Optional case sensitivity
- An effect: allow, redact, or block
- A kind to report matches under, and an optional name
Allow rules suit text you know is safe, such as a project codename or an internal URL. Block and redact rules suit text the model may miss, such as an account number or a license key.
Redaction
Redaction replaces a value instead of deleting it. Two styles exist:
- Placeholder writes a label, such as
[redacted: email]. Every removed email reads the same. - Pseudonym writes a stand-in, such as
[email-4f2a]. Each value keeps its own stand-in across turns and restarts. If John's email becomes[email-4f2a], it stays[email-4f2a], so the model can still follow who is who.
With pseudonyms, the gateway can also restore the real values in a reply before it reaches you. A restored reply carries the X-Msty-Nexus-Data-Protection-Restored response header, so the calling app can tell the text was rewritten. The gateway remembers which stand-in replaced which value only for the life of the request, then forgets it.
Placeholder is the default.
Protect a preset
Presets can clean requests on their own. Turn on Remove personal information in the preset's settings, and detected values are taken out before the request leaves the machine, where the target model supports it.
A protected preset needs Data Protection to be on. If it is not, the preset says so, and its requests are blocked until it is.
Protect a Smart Route
Smart Routes decide path by path. Open Data Protection on a route to choose:
- Which requests get checked. Each routing choice, the default fallback, and the image fallback have their own check box. The route reports honest coverage, such as 2 of 4 paths protected.
- What happens when sensitive data is found. Send a cleaned request, block the request, or send it through a sensitive data route. You pick the target model or Smart Balancer pool, and whether it receives the cleaned or the original request. If that target is unavailable, the route can block or fall back.
- If the check cannot run. Block is the safe default. Sending the original request is allowed, but it is a deliberate choice and it is marked in live routing.
- What a fallback receives. The request already in flight, cleaned or original. Both are explicit; Nexus never switches versions on its own.
A route can also override the machine policy for its own requests: change a few kinds of detail, tighten the confidence, add route-only rules, or use a different redaction style.
The check runs after a lane is chosen and before its target is called, so unprotected paths never pay for it. See Smart Routes for lanes, fallbacks, and live routing.
See what it found
The Data Protection page keeps a running record: requests checked, details removed, requests blocked, originals sent, and which kinds turned up. Counts only, never the text.
Each checked request in Smart Route live routing shows what the check found, how sure the model was, why a value was left in, and where the request went. Every finding has an action attached, right where it appears: ignore that kind of detail on the route, or create an allow rule for the flagged text.
If you run Nexus on several machines, Fleet insights shows the same counts for all of them.