Output DLP
Catch secrets and PII in the model's response before they reach your app — the egress side of data-loss prevention.
What it is
Data-loss prevention on the response
Output DLP scans what the model sends back for sensitive data — API keys, credentials, and PII patterns — before the response leaves the gateway. Where input PII protection guards what you SEND to the provider, output DLP guards what comes BACK: a model can echo secrets from a retrieved document, leak a key it saw in context, or surface PII it was never supposed to include. Output DLP is a post-call guardrail: it runs on the completion, not the prompt.
Modes
off / monitor / redact / block
Output DLP is a per-policy-group setting, output_dlp_mode, set to one of four modes. The default is monitor — every account gets detection out of the box without changing behaviour, then escalates when you're ready.
| Mode | Behavior |
|---|---|
| off | No scan. The response passes through untouched. |
| monitorDefault | Detect and LOG only — never blocks or redacts. Findings are recorded to Security Activity so you can measure the would-fire rate before enforcing. This is the default. |
| redact | Mask the detected spans in the response before returning it. The caller receives a scrubbed answer; the raw secret never reaches your app. |
| block | Return HTTP 403 when sensitive data is detected in the response. The completion is withheld entirely. |
Monitor first
See the would-fire rate before you enforce
Because the default is monitor, you can leave it on across your fleet and watch what it catches on the Security Activity dashboard for a week — real findings, zero customer impact. When the signal is clean, escalate that policy group to redact or block. This is the safe path to enforcement; see policy groups for how per-group config works.
// Policy group config (PATCH /anoman/v1/policy-groups/{id})
{
"output_dlp_mode": "redact" // off | monitor | redact | block
}Streaming
How redact and block interact with SSE
Streaming responses need care: tokens are emitted as they arrive, so once a span has been sent the guardrail can no longer pull it back. Mid-stream enforcement for redact and block requires enabling the opt-in output_dlp_buffer_streams setting. Without it, redact on a stream degrades to monitor — already-emitted tokens can't be masked — and block only fires at stream close, after partial tokens may already have streamed. Enable stream buffering to enforce on the live stream; in monitor mode findings are simply logged after completion.
For the streaming wire format and cancellation semantics, see streaming.
Configure
Where to set the mode and see findings
Set the mode per policy group in the dashboard at /dashboard/guardrails (Output DLP selector). Detections land in the Security Activity view at /dashboard/security-activity, together with every other monitored guardrail.
Related: the guardrails overview for the full pipeline, and PII protection for guarding data on the way IN.
Turn on egress protection
Output DLP is already monitoring — escalate to redact or block from your dashboard.