DLP detectors

The DLP layer scans request bodies and response bodies for sensitive data. The detector ships with seventeen built-in kinds. You can’t add custom regex detectors from configuration on the opensource build (that’s a Rust-source change), but every built-in is enabled by default.

The seventeen kinds

Kind	Severity (default)	What it matches
Email	Medium	Standard email shape (local-part@domain.tld)
PhoneNumber	Medium	E.164 + common regional formats
SsnUs	High	US SSN (NNN-NN-NNNN, with checks for invalid area numbers)
CreditCard	High	Visa / Mastercard / Amex / Discover (Luhn-validated)
IpAddress	Low	IPv4 + IPv6 literals
AwsAccessKeyId	High	AKIA… / ASIA… 20-char prefixes
AwsSecretAccessKey	Critical	40-char base64-ish following an AWS-key heuristic
GithubToken	High	ghp_…, gho_…, ghs_…, ghr_… 40-char tokens
SlackToken	High	xox[baprs]-… Slack token format
OpenAiKey	High	sk-… 48-char OpenAI API key
AnthropicKey	High	sk-ant-… Anthropic API key
GoogleApiKey	High	AIza… 39-char Google API key
JwtToken	Medium	Three base64-url segments separated by .
BearerToken	Medium	Generic Bearer <opaque> in headers / bodies
PrivateKeyPem	Critical	-----BEGIN [RSA | EC | OPENSSH] PRIVATE KEY----- blocks
GenericHighEntropy	Medium	High-entropy strings (Shannon-entropy threshold) — catches “looks like a secret”

How severity becomes action

You don’t configure each detector individually. You set an action per severity:

# in .env
AGENTUM_DLP_ACTION_HIGH=block
AGENTUM_DLP_ACTION_CRITICAL=block

The four possible actions:

• observe — log the hit, don’t block, don’t redact.
• warn — log the hit, emit an alert, but let the call through.
• redact — substitute the matched substring with a tag ([EMAIL], [SSN], [OPENAI_KEY], etc.) before the request leaves or the response arrives.
• block — drop the request entirely; agent gets 403.

Defaults that ship in the example .env:

Severity	Default action
Low	observe
Medium	warn
High	block
Critical	block

Where DLP runs

Surface	DLP runs?
HTTPS-CONNECT gateway (proxy path)	Yes — prompts, tool args, tool results, response bodies (streaming + non-streaming)
MCP gateway	Yes — tool-call args + tool results
REST API direct calls (SDK path)	No — the SDK delegates allow/deny to the central policy engine without local body inspection

Note

If you need DLP on calls that go via the SDK, route the agent’s traffic through HTTPS_PROXY=http://lupid:7070 in addition to using the SDK. The two paths can coexist on the same agent.

What an audit row with a hit looks like

{
  "event_id":   "...",
  "event_type": "tool_call",
  "outcome":    "blocked",
  "agent_id":   "...",
  "tool":       "send_email",
  "data_classes": ["OpenAiKey", "Email"],
  "detail": {
    "findings": [
      { "kind": "OpenAiKey", "severity": "High",   "tag": "OPENAI_KEY", "redacted": false },
      { "kind": "Email",     "severity": "Medium", "tag": "EMAIL",      "redacted": true }
    ],
    "outcome_reason": "dlp_block_high_severity"
  }
}

The audit row records:

• Which kinds fired (data_classes).
• Per-finding severity and whether redaction was applied.
• Why the outcome was what it was (outcome_reason).

Useful for auditor questions like “how many requests in the last 30 days had a PrivateKeyPem hit?” — that’s a single agentum audit query away.

Severity tuning by audit type

The opensource build doesn’t expose a UI for per-detector severity overrides yet — the mapping in the table above is what ships. If you need to raise Email to High (e.g. you’re in a GDPR-strict environment), the cleanest path is a new migration that updates the classifications table; the application reads it at startup and applies the overrides.