Skip to main content

Detect and redact sensitive data

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. 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:

SituationWhat it covers
Stripping PII from prompts before they reach an external providerA pii rule on the input stage with a redact action
Preventing customer records from leaving Agent RouterA detector in the project that handles that data
Stopping API keys and secrets from being sent to or returned by a modelA secrets rule applied on both stages with a block action
Encoding an organisation-specific record format the built-in detectors do not knowA custom pattern added alongside the built-in detectors
Demonstrating sensitive-data controls for a compliance reviewA 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.

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, 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.

CategoryCheck typeWhat it recognises
Personal datapiiNames, email addresses, phone numbers, national identifiers, payment cards, IBANs, and similar well-known classes
CredentialssecretsAWS, GitHub, and Slack credentials, generic API keys, and other credential-bearing tokens
Organisation-specific formatsregexpWhatever 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 and Configure guardrail providers.

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.

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 / modeWhat happens on a matchWhere it fits in a DLP policy
Redact (enforce)The matching span is masked or removed, and the request continues with the sanitised contentPersonal 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 callerSecrets and API keys, where a match means the interaction itself is not permitted
Monitor modeThe content passes unchanged, but the would-be action is recordedObserving 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.

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.

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, not when creating the rule; they are listed in the guardrails reference.

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, 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.

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 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. 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. Retention of the management-plane copy is governed separately; see Manage log retention and purge. For streaming decisions into a central security system, see Export audit and policy decisions to a SIEM.

What to do next​

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.