Output Filtering & PII Redaction
Before an agent's output leaves the trust boundary, scan and redact for sensitive data, policy violations, and disallowed content.
This page is the complete instruction page for one pattern called "Output Filtering & PII Redaction." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Agents that read sensitive data risk re-surfacing it in outputs — to other users, to logs, to external systems. Sensitive-data DLP is a last line before exposure.
Problem
Upstream controls leak unless the output itself is checked.
Forces
- Output fidelity vs safety
- False-positive redactions vs true-positive leaks
Solution
At the output boundary: scan for PII (names, IDs, card numbers), jurisdictional data (cross-border residency), secrets (tokens, keys), and disallowed topic violations. Redact, refuse, or route for review. Separate scanner from generator to avoid co-training weaknesses.
Applicability
- Customer-facing agents
- Agents producing external communications
- Multi-tenant platforms
Anti-Patterns
- Trusting the generator model to self-redact
- Redaction at ingestion but not at egress
Consequences
- +Last-line defence against data exposure
- +Consistent application across agents
- −Redaction false positives
- −Can break output fluency