Redact PII

Redaction is for data the model does not need in order to be useful. A support agent drafting a reply does not need the customer’s real email address to write a good sentence — so replace it, forward the prompt, and let the work happen.

vulnetix ai-firewall policy guardrail redact-pii \
  --rule-type pii_redact \
  --action redact \
  --priority 20 \
  --enable

No --pattern. Leaving it empty is what selects the built-in detectors.

What the user typed:

Draft a follow-up to jane.doe@acme.com, card ending 4242 4242 4242 4242,
callback +1 415 555 0100

What the provider actually received:

Draft a follow-up to [REDACTED], card ending [REDACTED],
callback [REDACTED]

The request succeeds. The model answers. The personal data never left your perimeter.

The four built-in detectors

This is the complete list. There is no NLP, no name detection, no address detection — these four regexes are the whole feature.

DetectsPattern
Email address[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}
Card-like number\b(?:\d[ -]*?){13,16}\b
US Social Security number\b\d{3}-\d{2}-\d{4}\b
Phone number\b(?:\+?\d{1,2}[ .\-]?)?\(?\d{3}\)?[ .\-]?\d{3}[ .\-]?\d{4}\b

Read them carefully, because their limits are load-bearing:

Warning

These are shape detectors, not validators. The card detector matches any 13-to-16-digit run with optional spaces or dashes — it does not run a Luhn check, so a long order number or a hex-free trace ID will match it. The phone detector is North-American-shaped and will miss most international formats while matching some things that are not phone numbers at all.

Assume false positives and false negatives in both directions. If you need to match your own data, write a custom filter.

Notably absent: names and postal addresses are not detected. If your compliance requirement is “no personal data reaches the provider”, these four regexes do not get you there on their own, and you should not tell your auditor that they do.

The placeholder is one literal string

Every detector redacts to the same literal: [REDACTED]. There are no per-entity labels — you will not get [EMAIL] or [SSN]. The model therefore cannot tell what kind of thing was removed, only that something was.

This matters when you write prompts. Email [REDACTED] about the outage reads fine. Compare [REDACTED] with [REDACTED] does not tell the model much.

Redaction is silent

This is the most important operational fact on this page.

A redacted request succeeds. The client gets a normal 200 and a completion. There is no error, no header, no warning. The user simply gets an answer about redacted text, and unless they know the rule exists they will conclude the model is being obtuse.

Consequences worth planning for:

  • Tell your developers the rule exists. A redaction they do not know about is a confusing model, not a security control they respect.
  • If the data is something the model genuinely needs, redaction is the wrong tool. Either narrow the rule so it does not fire on that path, or accept that the request should be blocked outright.

Ordering with other rules

Redaction mutates the request in place, and later rules see the redacted text. Priority is therefore how you sequence them.

Put a redaction before a block if you want the redaction to defuse it:

# priority 20: emails become [REDACTED]
vulnetix ai-firewall policy guardrail redact-pii \
  --rule-type pii_redact --action redact --priority 20 --enable

# priority 30: this now never sees a raw email address
vulnetix ai-firewall policy guardrail no-customer-domains \
  --rule-type blocked_pattern --action block \
  --pattern '(?i)@acme\.com' --priority 30 --enable

Reverse the priorities and the block wins, because a block short-circuits.

Redaction and prompt caching

Note

Redaction rewrites the text of the request. If your client relies on prompt caching — Claude Code does, aggressively — a rule that fires inside a cached prefix changes that prefix and causes a cache miss, so you pay full price for that turn instead of the cached rate.

This is unavoidable given what redaction is. It argues for keeping redaction rules narrow on agent traffic: match the thing you care about, not a broad pattern that fires on every turn.

What is inspected

The system prompt, every message, multi-modal text parts, and tool results — including file contents and command output an agent feeds back into the conversation. That last one is where PII usually enters an agent’s context.

Not inspected: responses, and the arguments a model generates for a tool call. See limitations.