DLP Filter

The dlp-filter policy checks request content against configured detect_patterns and blocked_terms. It can block the request or return redact. With action: redact, the response-redaction path also uses the configured regexes and literal terms on supported response transports.

Configuration

pack:
  name: dlp-filter-example
  version: 1.0.0
  enabled: true

policies:
  chain:
    - dlp-filter

policy:
  dlp-filter:
    detect_patterns:
      - 'AKIA[0-9A-Z]{16}'
      - 'ghp_[0-9A-Za-z]{36}'
    blocked_terms:
      - Project Titan
      - internal.acme.corp
    action: block
    fuzzy_matching: true
    max_distance: 2
    sensitivity_level: high

Fields

Field	Type	Description	Default
detect_patterns	string[]	Regex patterns evaluated against one string made from the message content.	[]
blocked_terms	string[]	Literal terms examined with case-insensitive matching.	[]
action	redact | block	block stops the request. redact lets the gateway redaction pass run.	redact
fuzzy_matching	boolean	Enable fuzzy matching for near-miss terms and patterns.	false
max_distance	integer	Maximum edit distance used when fuzzy_matching is enabled.	1
sensitivity_level	standard | high | restricted	high and restricted add the listed classification markers. standard does not add this check.	standard

What this policy does today

• It has no built-in regex library for API keys, SSNs, IBANs, MRNs, or biometric data.
• It only evaluates the patterns and terms you configure, plus the classification-marker context check enabled by high and restricted.
• At this time, high and restricted share the same context-sensitive marker detection in the gateway.

Use cases

Secret and codename blocking

pack:
  name: secret-leak-guard
  version: 1.0.0
  enabled: true

policies:
  chain:
    - dlp-filter
    - audit-logger

policy:
  dlp-filter:
    detect_patterns:
      - 'AKIA[0-9A-Z]{16}'
      - 'sk-[A-Za-z0-9]{48}'
    blocked_terms:
      - Project Titan
      - jira.acme.corp
    action: block
    fuzzy_matching: true
    max_distance: 1

Redaction verdict

pack:
  name: redact-then-log
  version: 1.0.0
  enabled: true

policies:
  chain:
    - dlp-filter
    - audit-logger

policy:
  dlp-filter:
    blocked_terms:
      - internal use only
      - do not distribute
    action: redact

Classification-marker detection

pack:
  name: classified-routing
  version: 1.0.0
  enabled: true

policies:
  chain:
    - dlp-filter
    - entity-list-filter
    - itar-ear-filter

policy:
  dlp-filter:
    action: block
    sensitivity_level: restricted

How it works

1. Verdictan makes one text buffer from the request messages.
2. Each regex in detect_patterns is evaluated against that content.
3. It checks each blocked_terms value without case sensitivity.
4. If fuzzy_matching is enabled, near matches at max_distance or less also count.
5. For high or restricted, the gateway checks the built-in classification markers above.
6. If a check finds a match, the policy returns block or redact.

Best practices

• Use detect_patterns for structured secrets and blocked_terms for specified organization names.
• Prefer block when deterministic enforcement of the matched content is necessary.
• Keep max_distance small. Values above 2 can cause many false matches.
• Use action: redact for supported response redaction. Output does not use the input fuzzy or classification-marker checks.
• Test buffered and streaming response bodies. A redact verdict does not prove that each fuzzy input match has a replacement target.

Next steps

• PII Detector — Built-in personal-data detection and redaction
• Data Routing Policy — restrict targets by declared data metadata
• Prompt Injection Detection — Input attack detection