Overview
PII redaction runs automatically on every tool call when enabled. It scans the API response for sensitive patterns and replaces matches with labelled placeholders — for example [email protected] becomes [REDACTED:EMAIL] — before the data is sent to the AI client and/or stored in the call log.
Redaction is configured per server and applies to all tools on that server.
Open GetMCP → Servers → {Your Server} → Settings tab → PII Redaction section.
- Enable PII Redaction — toggle on.
- Scope — choose where redaction is applied.
- Presets — check the built-in patterns to activate.
- Custom Rules — add your own regex patterns (optional).
Redaction Scope
| Scope | What gets redacted |
|---|
| Both (default) | AI response and call log storage |
| Response only | AI response only — raw values stored in logs |
| Log only | Logs only — AI receives unredacted response |
Log only is useful when you need the AI to see full data (e.g. an email tool that must read addresses) but don’t want raw PII in your audit trail.
Built-in Presets
| Preset | Detects | Placeholder |
|---|
| Email addresses | Standard email format | [REDACTED:EMAIL] |
| US Social Security Numbers | XXX-XX-XXXX format | [REDACTED:SSN] |
| Credit card numbers | 13–19 digit sequences | [REDACTED:CARD] |
| Phone numbers | International and US formats | [REDACTED:PHONE] |
| IPv4 addresses | Standard dotted-quad | [REDACTED:IP] |
| AWS access keys | AKIA-prefixed 20-char strings | [REDACTED:AWS_KEY] |
| JWT tokens | eyJ-prefixed three-part tokens | [REDACTED:JWT] |
Custom Rules
Add your own patterns for data that doesn’t match any built-in preset. Each custom rule has:
| Field | Description |
|---|
| Label | Human-readable name shown in the admin UI |
| Pattern | PCRE regex (no delimiters — they are added automatically) |
| Replacement | Text that replaces every match, e.g. [REDACTED:ACCOUNT_ID] |
| Field | Value |
|---|
| Label | UK National Insurance |
| Pattern | \b[A-CEGHJ-PR-TW-Z]{2}\d{6}[A-D]\b |
| Replacement | [REDACTED:NIN] |
Test custom patterns carefully before enabling them in production. Over-broad patterns can redact legitimate data the AI needs, silently degrading tool quality.
How It Works
Redaction happens after JMESPath/JSONPath extraction but before the data is sent to the AI client or written to the database:
API Response
→ JMESPath / JSONPath extraction
→ PII Redaction ← here
→ Template substitution
→ MCP content blocks → AI client
→ Call log (if scope includes log)
- Each active preset and custom rule is applied in order.
- All matches within the string are replaced with the configured placeholder.
- Strings longer than 1 MB are skipped (to avoid PCRE timeouts on huge payloads).
Numeric and boolean values are never modified — only strings are scanned.
Placeholder Labels in AI Responses
Matches are replaced with named labels (e.g. [REDACTED:EMAIL]) rather than blanked entirely. This lets the AI:
- Know that a field existed but was redacted
- Ask the user to provide the value if needed
- Reason about the response without silently missing data
Example AI response with redaction:
“I found 3 orders for customer [REDACTED:EMAIL]. Would you like me to look up more details?”
Log Storage
When scope includes logs, redaction is applied to both:
- Arguments — the input the AI sent to the tool
- Response data — the upstream API response stored in the log
The HMAC signature in the Immutable Audit Log covers the redacted content. This is intentional: the signature verifies what was actually stored on disk, not the original unredacted values.
What PII Redaction Does Not Cover
- Headers — auth headers are masked by a separate allowlist; other headers are not scanned for PII
- Tool configuration — API keys and credentials in tool settings are encrypted at rest, not redacted
- Existing logs — redaction is applied at write time; past logs are not retroactively scanned
