JSON bodies are masked structurally (string values only — keys are never
touched); plain-text bodies are masked directly. Matches that are secrets (API
keys, access tokens, JWTs, Stripe keys) are reported as secret findings; other
entities as PII.
What it protects against
Three different problems, and they are worth separating because each wants a different action:- Personal data leaving your control — reaching a third-party model provider in a prompt. Input + Transform: the request still goes through, masked.
- Personal data reaching a person who should not see it — regurgitated in an answer. Output + Transform.
- Credentials leaking — API keys, access tokens, JWTs, Stripe keys. Block rather than Transform: a masked credential has still left, and a request carrying one is usually a bug worth surfacing rather than cleaning.
Configure
- Open Detectors → create a detector and pick Data Loss Prevention.
- Under Data Categories, choose what to detect (or use Enable all).
- Optionally add Custom rules for keywords or regex patterns that are not in the built-in catalog.
- Save the detector, then add it to a policy rule (Input and/or Output) with an action.
What happens when it matches
The detector only finds and (when Transform is selected) masks. The action is set on the policy rule that references it:Data Categories
The form groups 67 built-in entities into six searchable categories. Toggle them individually, use Search categories to narrow the list, or Enable all to mask every entity at once.Personal information
Financial data
Secrets & credentials
Every entity here except UUID is reported as a secret finding rather than PII. See Secrets are a different kind of finding.Device & network
Health & medical
Several of these verify a check digit rather than matching a shape, so they produce far fewer false positives than a bare pattern would.National & government IDs
Secrets are a different kind of finding
A leaked credential is an incident, not a privacy problem, and TrustGuard keeps them apart: 22 of the 23 entities in Secrets & credentials are reported as secret findings instead of PII. UUID is the exception — it sits in that group for convenience but is reported as PII, because a UUID on its own is rarely a credential. That split is why secrets usually deserve their own policy rule: Block on them, while everything else is merely masked. When Transform runs, predefined entities are replaced with an entity-specific token (for example[MASKED_EMAIL]) unless you rely only on custom rules.
Custom rules
Use Custom rules when you need patterns that are not in the built-in catalog — internal account IDs, project codes, product-specific tokens, and so on.- In the detector form, open Custom rules.
- Click Add custom rule.
- Set Type:
- Keyword — exact substring match (e.g.
confidential). - Regex — a regular-expression pattern (e.g.
ACME-\d{6}).
- Keyword — exact substring match (e.g.
- Enter the keyword or pattern (required).
- Optionally set Mask with (default
***) and Preserve length (replace with*repeated to the original length). - Add more rules as needed; each rule is evaluated in order along with the selected data categories.
When to use
- Output + Transform — strip PII the model regurgitates before it reaches the user.
- Input + Transform — keep PII out of third-party model providers.
- Block on the Secrets & credentials group — a masked credential has still left your perimeter, so cleaning it up is not enough.
- Start with Monitor (and policy Report mode) when enabling broad categories, then switch to Enforce + Block/Transform once the signal looks right.