# Detect and redact sensitive data
> Detect and redact sensitive data at the Agent Router gateway, catching PII, secrets, and card numbers in prompts before they leave.
Enterprise Tier
Sensitive data leaks at the gateway long before anyone notices. A customer record pasted into a prompt, an API key embedded in a code snippet, a payment-card number copied into a support question: each of these can travel to a third-party model provider, and from there into a provider's own logs, the moment a request is forwarded unchecked. Data-loss prevention (DLP) is the discipline of stopping that traffic at the boundary: inspecting prompts on their way out and responses on their way back, recognising sensitive content, and removing, rejecting, or recording it before it crosses a line it should not cross.
Tetrate Agent Router enforces DLP through the same rule engine that backs its content guardrails. A guardrail is a content-filtering rule enforced inline by the gateway; DLP is the sensitive-data-focused application of that engine, configured in the Admin Dashboard and tuned for the specific categories a security or compliance team cares about: personally identifiable information (PII), source secrets, and API keys. This guide covers the work of standing up a DLP policy in Agent Router: choosing what to detect, deciding what happens on a match, scoping the policy to the right project, applying it on both stages, testing it before it enforces, and deciding where the resulting trigger records go.
This guide does not re-explain the rule engine itself. The mechanics of creating a guardrail, check types, providers, actions, and monitor mode are covered once, in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails). What follows is the DLP-specific reading of that material: which detectors to reach for, and how to assemble them into a policy that a compliance stakeholder will accept.
**Persona:** Platform operator working in the Admin Dashboard, typically alongside the security and compliance stakeholders who own the underlying data-handling policy.
**Estimated time:** 30 to 45 minutes for a first DLP policy, including time spent testing against seeded samples.
## When this guide applies
This guide is the right starting point in any of these situations:
| Situation | What it covers |
| :---- | :---- |
| Stripping PII from prompts before they reach an external provider | A `pii` rule on the input stage with a redact action |
| Preventing customer records from leaving Agent Router | A detector in the project that handles that data |
| Stopping API keys and secrets from being sent to or returned by a model | A `secrets` rule applied on both stages with a block action |
| Encoding an organisation-specific record format the built-in detectors do not know | A custom pattern added alongside the built-in detectors |
| Demonstrating sensitive-data controls for a compliance review | A project policy with redact and block actions, evidenced by its guardrail-trigger records |
For the developer-side view, how a request path opts into the guardrails an operator has configured, see [Protect requests with guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/protect-requests-with-guardrails).
## Outcomes
By the end of this guide:
- At least one DLP policy exists, built from one or more built-in detectors and any custom patterns the policy requires.
- Each category of sensitive data carries a deliberate action (`redact` or `block`) and mode (`enforce` or `monitor`).
- The policy inspects the input stage, the output stage, or both, matching the direction in which the data can leak.
- The policy sits in the project that handles the data rather than being applied indiscriminately.
- The policy has been tested against seeded sample content before being allowed to enforce.
- The relationship between DLP, custom guardrails, and the guardrail-trigger record is clear.
## Prerequisites
- Administrator access to the Admin Dashboard with permission to manage guardrails for the project, typically the `super_admin` role. The read-only `guardrail-reader` role can review what a policy did but cannot create or change one.
- A written data-handling policy that states which categories of data are sensitive and what must happen to each. The most defensible DLP policies start from a compliance requirement expressed in plain language, not from a pattern invented at configuration time.
- For any organisation-specific format (an internal record or account number) the pattern that describes it, ideally reviewed with the stakeholder who owns the data.
- Seeded sample content for the testing step: text that should match each detector, and realistic text that should not.
- Familiarity with [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails), which describes the rule engine this guide applies.
## Step 1: decide what counts as sensitive
DLP begins with a list, not a configuration screen. Before any rule is created, the categories of data the policy must catch should be named and agreed with the stakeholder who owns them. Each category then maps onto one of three check types.
| Category | Check type | What it recognises |
| :---- | :---- | :---- |
| Personal data | `pii` | Names, email addresses, phone numbers, national identifiers, payment cards, IBANs, and similar well-known classes |
| Credentials | `secrets` | AWS, GitHub, and Slack credentials, generic API keys, and other credential-bearing tokens |
| Organisation-specific formats | `regexp` | Whatever the named patterns say: an internal record number, an account format, a document identifier |
The `pii` and `secrets` check types recognise the common shapes of their categories without any pattern being written by hand. Where a category includes something organisation-specific, a named pattern in the Patterns library fills the gap: `regexp` rules take pattern names directly, and `builtin` detection patterns can each reference a catalog pattern instead of an inline expression. See [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails) and [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails).
A policy is usually assembled from several rules, each doing one job, rather than one rule stretched to cover every category. A `pii` rule for the well-known classes, a `secrets` rule for credentials, and a `regexp` rule naming the organisation's own patterns is a typical starting shape. The full check-type vocabulary is in the [guardrails reference](/reference/guardrails#check-types).
## Step 2: choose the action for each category
The action is what the gateway does when content matches a detector. Two enforcement actions are available (`redact` and `block`), and whether they apply is controlled by the rule's **mode** (`enforce` or `monitor`). A single DLP policy commonly uses more than one action: redact for data that should be stripped, block for data that must never pass, and monitor mode where visibility is the goal before enforcement.
| Action / mode | What happens on a match | Where it fits in a DLP policy |
| :---- | :---- | :---- |
| Redact (enforce) | The matching span is masked or removed, and the request continues with the sanitised content | Personal data and customer records that should be stripped without stopping the interaction |
| Block (enforce) | The request is rejected with HTTP `403`, or the response is withheld from the caller | Secrets and API keys, where a match means the interaction itself is not permitted |
| Monitor mode | The content passes unchanged, but the would-be action is recorded | Observing how often a category would fire before enforcement, without disrupting traffic |
Redact is the workhorse of a PII policy: the sensitive span is removed so the model never sees it, while the rest of the prompt proceeds and the interaction is not interrupted. For structured identifiers, the `regexp` provider's Patterns library and redaction format are a common choice; for semantic PII the `tetrate` provider's PII model can return entities and a masked copy. Block is the right action where the presence of the data is itself the problem: a credential or API key has no legitimate reason to travel to a model, so a match should stop the request outright. Monitor mode is the safest way to start any new rule: it produces the same trigger record without changing what callers experience, which makes it the natural pilot for Step 5. Action and mode are described in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails).
## Step 3: apply detection on both stages
Sensitive data leaks in two directions, and a DLP policy has to account for both. A rule's **Run on** setting selects the input stage, the output stage, or both.
- The input stage examines the prompt on its way to the model. This is where most PII redaction belongs: the sensitive content is removed before it leaves the organisation's boundary and before any provider can log it.
- The output stage examines the model's response before it returns to the caller. A model can reproduce sensitive data it was given earlier in a conversation, or surface a secret it inferred from context; output inspection catches data on its way back out.
- Setting **Run on** to both applies the same check each way. A credential should neither be sent to a model nor returned in a response, which makes `secrets` the clearest case for symmetric inspection.
One restriction applies to that symmetry. On the ML providers, `secrets` is an input-stage check, so a rule that must inspect both stages for credentials belongs on `regexp` or `builtin`, where every check type runs on either stage. The stage restrictions are listed in the [guardrails reference](/reference/guardrails#provider-availability-and-evaluation-order).
The stage is the only placement decision the rule form offers. Which kind of content an evaluation ran against (text, image, document, tool call, thinking, or context) is recorded as the evaluation's content type rather than chosen on the rule, so a rule set to run on a stage inspects every kind of content arriving on it. Those values matter when reading trigger records, covered under [How DLP matches are recorded](#how-dlp-matches-are-recorded), not when creating the rule; they are listed in the [guardrails reference](/reference/guardrails#rule-level-settings).
## Step 4: scope the policy to a project
A DLP policy rarely applies uniformly to all traffic. The same prompt that is unremarkable from an internal analytics tool may be a violation from a public-facing assistant.
The **project** is the only scope a guardrail has. Rules apply to the whole project, so guardrails in one project never touch another, and there is no per-app or per-team rule target. Separation therefore comes from which project a workload's API keys belong to: a project whose keys serve a customer-facing assistant can carry a strict policy while a project used for internal experiments carries none. Naming keys by purpose, as in [Onboard developers and issue keys](/agent-router-enterprise/guides/operate-and-govern/onboard-developers-and-issue-keys), is what makes that boundary legible later.
The practical consequence is that a category admitting no exception (credentials typically) belongs in every project that handles model traffic, while a category that is sensitive only in one context belongs in the project that context routes through. Where several rules apply to the same request, each is evaluated independently, and a block from any one of them stops the request.
## Step 5: validate in monitor mode against representative traffic
A DLP policy that has never been validated against representative content will eventually redact something it should leave alone, or pass something it should have caught. There is no separate test-content surface that dry-runs a rule against pasted samples: validation is monitor mode against live or staged traffic, and the procedure is in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails#step-6-validate-in-monitor-mode-before-enforcing).
Two things are specific to DLP validation:
- **Sample content must be fabricated, never drawn from production.** A synthetic record, a key in the expected format, and a realistically shaped but invalid credential exercise the same patterns without creating the exposure the policy exists to prevent.
- **Negative samples matter as much as positive ones.** A pattern for an internal record number will often match something innocuous, and an over-broad `pii` threshold will redact ordinary prose. Feed the rule realistic traffic that should *not* match and confirm it stays quiet.
Resolving every false match and every missed match at this stage costs far less than discovering them once the policy is rejecting real requests.
## How DLP relates to guardrails
DLP is not a separate subsystem. It is the same rule engine, on the same request path, aimed at one class of content: a DLP policy is the subset of guardrail rules that target personal data, credentials, and organisation-specific record formats. Everything in [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails) therefore applies unchanged, and this guide adds only the DLP reading of it.
## How DLP matches are recorded
Every match produces a **guardrail-trigger** record, and that record is what makes the policy defensible to a compliance stakeholder rather than merely active. One record is written per rule evaluation, carrying the rule and guardrail identifiers, the score, the action and mode, the stage and content type, the execution duration, and the project and consumer context.
Guardrail triggers are a different record type from Audit Logs. Audit Logs capture administrative mutations, including changes *to* a guardrail; triggers capture the policy *firing*. An operator investigating a specific block starts from the correlation identifier returned with the `403`, which resolves to the rules that triggered, their scores, and the content that caused it. That workflow is in [Guardrails best practices and FAQ](/reference/best-practices/guardrails-best-practices-and-faq). The read-only `guardrail-reader` role exists for exactly this review.
**Trigger records can contain the matched content, and by default the data plane's own copy always does.** The record carries the matched message and, for a redaction, the sanitised message. Two independent controls govern where that content goes:
- **Settings → Guardrails** in the Admin Dashboard sets what reaches the management plane: **Full** (matched and sanitised text stored), **Metadata only** (scores, check types, actions, and identifiers, without message content), or **Off** (no trigger records, and empty dashboard trigger views).
- A `guardrailtrigger` subscription on a custom observability backend receives **full content regardless of that setting**, because the fan-out exists so an organisation can hold complete records in its own systems.
A DLP policy therefore needs both settings decided deliberately: a control designed to keep sensitive data out of a provider's logs should not put it somewhere unintended instead. Both are documented in [Custom observability backends](/agent-router-enterprise/guides/observability-and-analytics/configure-custom-observability-backends#guardrail-trigger-destinations). Retention of the management-plane copy is governed separately; see [Manage log retention and purge](/agent-router-enterprise/guides/operate-and-govern/compliance-and-governance/manage-log-retention-and-purge). For streaming decisions into a central security system, see [Export audit and policy decisions to a SIEM](/agent-router-enterprise/guides/operate-and-govern/compliance-and-governance/export-audit-and-policy-decisions-to-a-siem).
## What to do next
- **Configure guardrails**: the full mechanics of the rule engine this guide applies, including check types, providers, and monitor mode. See [Configure guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-custom-guardrails).
- **Configure guardrail providers**: how `regexp`, `builtin`, and `tetrate` score PII and secrets checks. See [Configure guardrail providers](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/configure-vendor-guardrails).
- **Protect requests with guardrails**: the developer-side view of how a request path sees the detectors configured here. See [Protect requests with guardrails](/agent-router-enterprise/guides/operate-and-govern/safety-and-data-protection/protect-requests-with-guardrails).
- **Custom observability backends**: decide where trigger records and their matched content are delivered. See [Custom observability backends](/agent-router-enterprise/guides/observability-and-analytics/configure-custom-observability-backends#guardrail-trigger-destinations).
- **Guardrails best practices and FAQ**: investigate a specific block from its correlation identifier. See [Guardrails best practices and FAQ](/reference/best-practices/guardrails-best-practices-and-faq).
- **Manage log retention and purge**: govern how long the management-plane copy of trigger records is kept. See [Manage log retention and purge](/agent-router-enterprise/guides/operate-and-govern/compliance-and-governance/manage-log-retention-and-purge).
- **Export audit and policy decisions to a SIEM**: stream DLP decisions to a central security system. See [Export audit and policy decisions to a SIEM](/agent-router-enterprise/guides/operate-and-govern/compliance-and-governance/export-audit-and-policy-decisions-to-a-siem).
- **Reference**: the definitions behind the terms used in this guide are in the [glossary](/reference/glossary).
Where to go next
Configure guardrails
The full mechanics of the rule engine this guide applies, including check types and monitor mode.
Export audit and policy decisions to a SIEM
Stream DLP decisions to a central security system.