Data Loss Prevention (DLP)

Prevent agents from accidentally leaking sensitive data like API keys, passwords, credit card numbers, or personal information.

Overview
How It Works
Key Concepts
Creating & Editing Rules
Enterprise Rule Packs
Violation Tracking
Testing Rules
Configuration & Setup
Best Practices
Troubleshooting
Related Pages

Overview

For everyone: DLP is like a security guard that watches everything your AI agents send and receive. If an agent accidentally tries to include a password, credit card number, or API key in an email or output, DLP catches it and blocks, redacts, or logs it — before any damage is done.

For technical users: The DLP system applies pattern-matching rules (regex, keyword, or PII type detectors) to agent inputs and outputs. Rules are evaluated in real-time with configurable actions (block, redact, warn, log) and severity levels. All matches are recorded as violations in an audit-ready log. The engine exposes /dlp/rules, /dlp/violations, and /dlp/scan endpoints.

How It Works

Define rules — create patterns that identify sensitive data (regex, keywords, or built-in PII types).
Content is scanned — as agents process emails and tool outputs, content is checked against all active rules.
Action is taken — when a match is found, the configured action fires: block, redact, warn, or log.
Violation is recorded — every detection is logged with the agent, tool, direction, match context, and action taken.

Key Concepts

Pattern Types

Type	Description	Example
Regex	Regular expression pattern matching	`sk-[a-zA-Z0-9]{48}` (OpenAI key)
Keyword	Simple text matching	`password`, `secret_key`
PII Type	Built-in detectors for common PII	`email`, `ssn`, `credit_card`

Built-in PII Types

email — Email addresses
ssn — US Social Security Numbers
credit_card — Credit/debit card numbers (Visa, Mastercard, Amex, etc.)
phone — Phone numbers (various formats)
api_key — Generic API key patterns
aws_key — AWS access key IDs (AKIA...)

Actions

Action	Behavior	Use When
Block	Prevents the content from being sent/processed entirely	Critical secrets, credentials, highly sensitive PII
Redact	Replaces the matched content with [REDACTED] and allows the rest through	Semi-sensitive data where the message itself is important
Warn	Allows the content but flags it with a warning	Potentially sensitive content that may be legitimate
Log	Silently records the match without any intervention	Monitoring and baseline measurement

Severity Levels

Severity	Color	Typical Use
Critical	Red	Production database passwords, master API keys, encryption keys
High	Orange	API keys, access tokens, credit card numbers
Medium	Blue	Email addresses, phone numbers, internal URLs
Low	Gray	Names, general keywords, non-critical metadata

Creating & Editing Rules

Click "Add Rule" to create a new DLP rule. Click any rule row to view its details in a modal, or use the pencil icon to edit an existing rule. Fill in:

Name — descriptive identifier (e.g., "Block OpenAI API Keys")
Pattern Type — regex, keyword, or pii_type
Pattern — the actual pattern or PII type name
Action — block, redact, warn, or log
Severity — critical, high, medium, or low
Applies To — inbound, outbound, or both
Enabled — toggle rules on/off without deleting them

Organization Scoping: Use the org switcher in the page header to view and manage DLP rules per organization. Rules are scoped — each organization has its own set.

Tip: Start with "log" action to measure how often a pattern matches before switching to "block" or "redact." This avoids disrupting agent workflows with false positives.

Example Rules

// Block AWS access keys
Name: "Block AWS Keys"
Type: regex
Pattern: AKIA[0-9A-Z]{16}
Action: block
Severity: critical

// Redact credit card numbers
Name: "Redact Credit Cards"
Type: pii_type
Pattern: credit_card
Action: redact
Severity: high

// Log email address mentions
Name: "Log Email Mentions"
Type: pii_type
Pattern: email
Action: log
Severity: medium

Enterprise Rule Packs

The Rule Packs tab provides pre-built enterprise-grade rule sets that can be applied to any organization with one click. Rules are instantly active — no restart needed.

Available Packs

Pack	Rules	Description
PII Protection	10	Email, SSN, credit card, phone, passport, DOB, driver license, tax ID, IBAN, IP addresses
Credentials & Secrets	14	API keys, AWS/GitHub/Slack/Stripe/Google/OpenAI tokens, private keys, passwords, DB connection strings, JWTs
Financial Data	5	Bank accounts, routing numbers, SWIFT codes, salary data, tax returns
Healthcare / HIPAA	5	Medical records, insurance IDs, ICD/CPT codes, prescriptions, DEA numbers
GDPR / EU Compliance	4	EU national IDs, DSAR keywords, consent withdrawal, cross-border transfer markers
Intellectual Property	4	Confidentiality markers, source code blocks, patent references, internal URLs
Agent Safety	5	Prompt injection (ignore instructions, role override, system prompt extraction), base64 payloads, shell injection

Applying Packs

Go to the Rule Packs tab
Select one or more packs (or "Select All")
Optionally check "Overwrite existing rules with same name" to update rules you've previously applied
Click "Apply Selected Packs"

Tip: Click the expand arrow on any pack to preview all its rules before applying. Rules that already exist (same name) are skipped by default unless overwrite is enabled.

API Endpoints

Method	Endpoint	Description
GET	`/dlp/rule-packs`	List available rule packs with metadata
GET	`/dlp/rule-packs/:id`	Get pack details including all rule definitions
POST	`/dlp/rule-packs/apply`	Apply packs to an org: `{ orgId, packIds[], overwrite? }`
POST	`/dlp/reload`	Hot-reload all rules from database

Violation Tracking

The Violations tab shows every DLP match across all agents. Each violation record includes:

Field	Description
Time	When the violation was detected
Agent	Which agent triggered the match
Tool	The tool or channel that contained the content (e.g., email send, web fetch)
Action	What action was taken (blocked, redacted, warned, logged)
Direction	Whether the content was inbound or outbound
Match	Context around the matched pattern

Warning: Violations are limited to the most recent 100 entries in the UI. For full audit history, use the Compliance reporting feature or query the API directly.

Testing Rules

The Test tab lets you validate rules against sample content before deploying them:

Switch to the "Test" tab
Paste sample content into the text area
Click "Run Scan"
Review results — shows which rules matched and how many times

Tip: Test with realistic data samples before deploying new rules. Include both positive cases (should match) and negative cases (should NOT match) to verify accuracy and avoid false positives.

Configuration & Setup

API Endpoints

Method	Endpoint	Description
GET	`/dlp/rules?orgId=`	List all DLP rules
POST	`/dlp/rules`	Create a new rule
PUT	`/dlp/rules/:id`	Update an existing rule
DELETE	`/dlp/rules/:id`	Delete a rule
GET	`/dlp/violations?orgId=&limit=`	List violations
POST	`/dlp/scan`	Test content against all active rules

Rule Schema

{
  "name": "Block API Keys",
  "orgId": "org-123",
  "patternType": "regex",       // "regex" | "keyword" | "pii_type"
  "pattern": "sk-[a-zA-Z0-9]{48}",
  "action": "block",            // "block" | "redact" | "warn" | "log"
  "appliesTo": "both",          // "inbound" | "outbound" | "both"
  "severity": "high",           // "critical" | "high" | "medium" | "low"
  "enabled": true
}

Best Practices

Start with logging — deploy rules in "log" mode first to understand match frequency before blocking.
Layer your rules — combine PII type detectors (broad) with regex rules (specific) for comprehensive coverage.
Test before deploying — always use the Test tab with realistic content to verify patterns.
Monitor violations regularly — review the Violations tab weekly to identify trends and false positives.
Use severity appropriately — reserve "critical" for production credentials; overusing it causes alert fatigue.
Cover both directions — set appliesTo: "both" unless you have a specific reason to scan only inbound or outbound.
Keep patterns specific — overly broad regex patterns generate false positives. sk-[a-zA-Z0-9]{48} is better than sk-.*.
Combine with Vault — store credentials in the Vault rather than relying solely on DLP to catch leaks.

Troubleshooting

Rule not matching expected content

Use the Test tab to debug. Common issues: regex missing anchors, case sensitivity, or PII type not covering the exact format. Try your regex at regex101.com first.

Too many false positives

Make your patterns more specific. For example, use \b\d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4}\b for credit cards instead of just \d{16}. Consider switching to "warn" or "log" action while tuning.

Violations not appearing

Check that the rule is enabled and that orgId matches. Violations are scoped per organization. Also verify the appliesTo field matches the direction of the content.

Agent blocked but content seems safe

This is a false positive. Review the violation's match context, adjust the rule pattern, and consider switching to "warn" action. You can delete and recreate the rule with a refined pattern.

Vault — Store credentials securely so agents don't need to handle raw secrets. Compliance — Generate reports that include DLP violation summaries. Users — Manage who can create and edit DLP rules.

AgenticMail Enterprise Documentation Report an issue

Data Loss Prevention (DLP)

Table of Contents

Overview

How It Works

Key Concepts

Pattern Types

Built-in PII Types

Actions

Severity Levels

Creating & Editing Rules

Example Rules

Enterprise Rule Packs

Available Packs

Applying Packs

API Endpoints

Violation Tracking

Testing Rules

Configuration & Setup

API Endpoints

Rule Schema

Best Practices

Troubleshooting

Rule not matching expected content

Too many false positives

Violations not appearing

Agent blocked but content seems safe

Related Pages