# Content scanning and redaction

Apply supported secret and PII detectors to proxy traffic with visible scope.

Updated: 2026-09-22

Canonical: https://docs.kastra.ai/proxy/content-guardrails

## Choose a detector and an effect

The native registry includes `secrets`, `pii-lite`, and `pii-br`. Rules select supported content surfaces and detector categories. Depending on the rule and stage, effects include monitoring, denying, holding, and redacting matched spans. Authoring permissions follow the content-guardrail entitlement.

| Detector | Scope |
| --- | --- |
| `secrets` | Supported credential and secret patterns; bounded by its pattern set |
| `pii-lite` | Supported general PII patterns, including validation and contextual checks |
| `pii-br` | CPF/CNPJ checks, supported formatted Brazilian phone numbers, contextual PIX keys, and labeled bank-account patterns |

Brazilian scanning is part of the current source implementation. Confirm that your server release includes it before writing policies that depend on it. A category name is not a guarantee of exhaustive detection or regulatory compliance.

## Roll out a rule

1. Select the relevant input or output surface in the policy editor.
2. Start with synthetic examples and monitoring in a test environment.
3. Confirm detector findings and the exact spans to be redacted.
4. Test false positives and valid variants, then enable the intended enforcement effect.
5. Check the recorded decision and what reached the provider or tool.

## Know the boundary

Native content scanning on proxy traffic does not imply equivalent prompt-content scanning on every coding-agent hook. Tool arguments and model output have their own shapes. A regex-based detector can miss encodings, unrecognized formats, or content beyond the inspected bounds.

Redaction of a forwarded request and masking of a stored decision are separate operations. Read [data handling](https://docs.kastra.ai/evidence/data-handling) before treating a UI mask as proof that no original content was retained.