Data loss prevention
Scan prompts and completions for PII, secrets, and other sensitive data
Gateway’s DLP layer inspects every inbound prompt and outbound completion against a configurable rule set, then logs, redacts, or blocks based on what it finds. Use it to keep PII out of vendor logs, to comply with a customer DPA, or to prevent secrets from leaking back to end users.
DLP runs three categories of rules in parallel on the same request:
The seeded rule set covers 15 entity types by default. Each one has a default action (redact, log, or block) that you can override per org.
Seeded rules can be disabled or have their action changed, but their detection pattern is immutable. The patterns are tied to the upstream Presidio recognizer.
Custom rules let you catch organization-specific patterns. Each custom rule combines two optional matchers:
A custom rule must include at least one of the two. Patterns are validated with re.compile at save time, so invalid regex is rejected before reaching the data plane.
Each rule has a name (entity_type), a description, and an action. Names must be unique within your org.
Every rule, seeded or custom, runs with one of three actions:
Two rules can match the same span. When they do, Gateway keeps the higher-priority entity (for example, CREDIT_CARD wins over DATE_TIME) so you don’t get duplicate findings on the same span.
The dashboard includes a built-in tester so you can validate rule behavior without sending a real request. Paste sample text and you’ll get a list of hits with their entity type, action, matched substring, and character offsets.
The tester runs a deterministic regex-based simulator. It does not call the live sidecar, which keeps the response under a millisecond and means you can iterate on rules quickly. Input is capped at 50,000 characters.
The tester is the fastest way to develop a custom rule. Iterate until the hits match what you expect, then enable the rule in your org settings.
Open Security → DLP in the Merge Gateway dashboard. The page lists seeded and custom rules side by side, with toggles for enabled and a dropdown for action. The same page exposes the tester so you can validate changes without leaving the screen.
Custom rule CRUD requires the Manage organization settings permission. Every change emits an audit log event.
Every DLP detection, whether the rule’s action is log, redact, or block, generates a security alert under Security → Alerts. Each alert includes:
Alerts share the same store as PI-protection events, so you can filter, sort, and triage both signal types together.
DLP runs synchronously on the request and response path:
PERSON / LOCATION detection, disable those rules to save the most time.Yes. Inbound prompts are scanned before they reach the vendor, and outbound completions are scanned before they reach your application. Both directions use the same rule set.
No. Seeded rules can be disabled or have their action changed, but they can’t be deleted. This is intentional, so we can add new recognizers in future releases without breaking existing configurations.
DLP looks for structured sensitive data (PII, secrets, customer-defined patterns). PI protection looks for adversarial intent (prompts trying to manipulate the model). They run independently on the same request and either one can block, redact, or alert.
By default, DLP fails open and the request proceeds. Operations are responsible for sidecar uptime; if it goes down, you’ll see alerts about it in the platform health dashboard before any prompts go unscanned.
The redacted version is what the vendor receives and what gets stored in the request log. The original is never persisted by Gateway unless you’ve enabled payload logging on the org.