Data loss prevention

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.

Detection layers

DLP runs three categories of rules in parallel on the same request:

Built-in entity types

The seeded rule set covers 15 entity types out of the box. 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 - those are tied to the upstream Presidio recognizer.

Custom rules

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.

Rule actions

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.

Testing rules

Run sample text against your enabled rules without sending a real request:

$
curl -X POST https://api-gateway.merge.dev/api/dlp-rules/{org_id}/test \
>
  -H "Authorization: Bearer YOUR_API_KEY" \
>
  -H "Content-Type: application/json" \
>
  -d '{"text": "Contact me at [email protected] or 555-123-4567"}'

The response lists every hit with its entity type, action, matched substring, and character offsets:

1
{
2
  "text": "Contact me at [email protected] or 555-123-4567",
3
  "hits": [
4
    {
5
      "rule_id": "...",
6
      "entity_type": "EMAIL_ADDRESS",
7
      "category": "global",
8
      "action": "redact",
9
      "matched_substring": "[email protected]",
10
      "start": 14,
11
      "end": 28
12
    },
13
    {
14
      "rule_id": "...",
15
      "entity_type": "PHONE_NUMBER",
16
      "category": "global",
17
      "action": "redact",
18
      "matched_substring": "555-123-4567",
19
      "start": 32,
20
      "end": 44
21
    }
22
  ]
23
}

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.

Configuring DLP in the dashboard

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_ORG_SETTINGS permission. Every change emits an audit log event.

Security alerts

Every DLP detection - whether the rule’s action is log, redact, or block - generates a security alert under Security → Alerts. Each alert includes:

• Timestamp and request ID
• Entity type and category
• Action taken
• The triggering segment (subject to your log-payloads setting)
• Customer, project, and API key context

Alerts share the same store as PI-protection events, so you can filter, sort, and triage both signal types together.

Performance considerations

DLP runs synchronously on the request and response path:

• Latency: the sidecar adds a few milliseconds per request. Presidio’s NER models are the heaviest component; if you don’t need PERSON / LOCATION detection, disable those rules to save the most time.
• Redact vs. block: redaction adds a small constant cost (replacing spans in the payload). Blocking returns immediately, which is faster but customer-visible.
• Custom rules: each regex is compiled at startup and cached. Avoid catastrophic-backtracking patterns - the tester is a good place to verify they’re efficient.

FAQ

Next steps