PII redaction and data protection

Overview

PII redaction lets DeepintShield find and remove sensitive data from AI traffic as it flows through the gateway. Every prompt, model response, retrieved RAG chunk, and MCP tool result can be scanned for personally identifiable information (PII), protected health information (PHI), and secrets, then masked or redacted in place before the content crosses a trust boundary.

Redaction is not just a finding in a log. When a check returns a redact verdict, the gateway rewrites the content the model actually receives, the response the caller actually gets, and the tool output an agent actually reads. Detection runs entirely inside your own deployment, so no prompt text and no detected identifier is ever sent to a third-party classifier or billed as model tokens.

Key benefits

• Prevention, not after-the-fact logging. Sensitive data is stripped from the outbound request so the upstream provider never sees it, and from the response (including streaming output) so the model can’t leak it back.
• Broad out-of-the-box coverage. Built-in detectors and preset banks cover SSNs, credit cards, emails, phone numbers, IP addresses, India PAN and Aadhaar, IBAN, passport numbers, plus API keys, AWS keys, GitHub tokens, Slack tokens, JWTs, and private-key blocks.
• Fewer false positives. Credit-card detection validates candidate numbers so long order IDs and account numbers keep flowing instead of being over-masked.
• One enforcement point across surfaces. The same policy model covers prompt input, response output, MCP tool I/O, and RAG chunks.
• Audit-safe by design. Detected secrets are reduced to a short, length-only hint in findings, so the audit trail never becomes a second copy of the leaked value.
• Self-hosted. Detection and redaction run in your VPC, on-prem, or air-gapped, with no data egress.

Note

PII redaction is delivered as part of DeepintShield’s guardrails policy engine. You enable it by adding PII and secret checks to a guardrail policy and choosing a Redact action - there is no separate switch to turn on.

When to use it

Turn on PII redaction when you need to:

• Ship a customer-facing or internal AI assistant in a regulated domain (finance, healthcare, insurance) without leaking data you are legally bound to protect.
• Keep customer PII out of third-party model providers while still using their models.
• Stop the model from echoing secrets, credentials, or personal data back to end users.
• De-identify retrieved documents in a RAG pipeline so useful context reaches the model but embedded PII does not.
• Keep sensitive data pulled by agent tools out of an agent’s reasoning context.

Configuration

PII redaction is configured as one or more checks inside a guardrail policy. A policy is a set of detection cards plus the scope (where it runs) and the enforcement behavior (what happens on a match). You build and manage policies in the Web UI policy builder.

1. Open the guardrails workspace. Go to Guardrails in the workspace and create or edit a policy.

2. Choose the scope. Select where the policy runs. Available scopes are Input (the prompt), Output (the model response), Action, MCP (agent tool I/O), and RAG (retrieved chunks). Enable Output in addition to Input to also redact what the model sends back.

3. Add a sensitive-data card. Add the Sensitive information disclosure card (OWASP LLM02). It exposes two groups:

   • PII categories - Email, Phone, SSN, Credit card.
   • Secret detectors - API keys, Private keys, Auth headers / bearer tokens.

   Select the categories and detectors you want to catch. You can also paste a Custom secret regex to match proprietary identifier formats.

4. Set the action to Redact. In the card’s Failure action, choose Redact content. On a match, the gateway replaces the detected value inline instead of blocking the request. Other actions are Block request, Sandbox, and Monitor only.

5. Pick an enforcement and execution mode. Set the policy Enforcement mode to Redact, and choose an Execution mode:

   • Sync - evaluation runs inline and redaction is applied before content moves on (standard).
   • Shadow - runs inline to validate a new check without changing the payload, so you can confirm matches before enforcing.
   • Async - logs results only and never alters traffic. Async is not allowed for enforcement-class checks, because redaction has no effect once the content has already gone out.

6. Publish and set as default. Save the policy version and Publish it. Optionally set it as the default so it applies to traffic that doesn’t specify a policy. Policy versions support publish and rollback so you can change checks with full history.

Tip

Vertical domain packs (BFSI, healthcare, insurance, and others) ship pre-wired with the right PII, payment-card, and PHI presets for that industry. Adopting a domain pack is the quickest way to stand up redaction tuned to your sector.

Note

The detailed PII checks - which categories and presets are selected, and the replacement text used on a match - are stored in the policy definition that the Web UI builder produces. Author and version those policies in the Guardrails workspace.

Custom redaction text

By default a redacted value is replaced with [REDACTED]. Each check can override that with its own replacement string, so you can tune masked output to match downstream parsing or a compliance format (for example a fixed-width token) instead of a one-size-fits-all label.

What gets detected

The built-in detectors and preset banks cover global PII formats and common credential leaks. You don’t have to author these patterns - selecting the matching card or domain pack enables them.

Category	Examples covered
Identity PII	SSN, email, phone, IP address
Financial	Credit-card numbers (validated to cut false positives), payment-card markers, IBAN
Government IDs	Passport numbers, India PAN, India Aadhaar
Health (PHI)	Medical record number / MRN, patient ID, PHI markers
API & cloud secrets	API keys, AWS access keys, Google API keys, bearer / auth tokens
Developer secrets	GitHub tokens, Slack tokens, JWTs, private-key blocks

Note

Credit-card detection validates candidate numbers before flagging them, so a 13–19 digit run that isn’t a real card (a long order ID or account number) is not redacted. This keeps operational data intact while real card data is still caught.

Where redaction applies

Redaction is enforced at every boundary the policy scope covers:

• Prompt input. Sanitized content is sent upstream so the model never sees the raw PII.
• Response output. The model’s response - including streaming deltas - is rewritten before it returns to the caller.
• MCP tool I/O. Tool inputs and outputs are scanned and masked before results return to an agent, keeping sensitive data out of the agent’s context.
• RAG chunks. Retrieved chunks are evaluated against RAG-scoped policies and individual chunks can be redacted, so useful context is surfaced while embedded PII is stripped. See RAG security.

Field and option reference

Setting	Where	Values	Purpose
Scope	Policy	Input, Output, Action, MCP, RAG	Which surface(s) the policy inspects.
PII categories	Sensitive-information card	Email, Phone, SSN, Credit card	Structured PII to detect.
Secret detectors	Sensitive-information card	API keys, Private keys, Auth headers / bearer tokens	Credential material to detect.
Custom secret regex	Sensitive-information card	Any regex	Match proprietary or org-specific identifier formats.
Failure action	Card	Redact content, Block request, Sandbox, Monitor only	What happens on a match.
Enforcement mode	Policy	Monitor, Block, Redact, Sandbox	Policy-level default behavior on a violation.
Execution mode	Policy	Sync, Shadow, Async	Whether evaluation blocks the request and alters the payload.
Replacement text	Check	Any string (default [REDACTED])	Token written in place of a detected value.

Examples

Mask PII in both prompts and responses

1. Create a policy with Input and Output scopes enabled.
2. Add the sensitive-information card; select Email, Phone, SSN, and Credit card.
3. Set Failure action to Redact content and policy Enforcement mode to Redact.
4. Use Shadow execution first to confirm matches in your traffic, then switch to Sync to enforce.
5. Publish the version and set it as default.

A prompt containing My card is 4111 1111 1111 1111 is rewritten to My card is [REDACTED] before it reaches the provider, and any card number the model emits is masked before it reaches the user.

Strip secrets from agent tool output

1. Create a policy with the MCP scope enabled.
2. Add the sensitive-information card and select the secret detectors (API keys, Private keys, Auth headers / bearer tokens).
3. Set the action to Redact content.

Now when an agent tool returns a result containing an API key or bearer token, the value is masked before it enters the agent’s reasoning context.

Industry-tuned redaction with a domain pack

Adopt the healthcare or BFSI domain pack to enable the PHI / payment-card presets for that sector in one step, then set the policy enforcement mode to Redact. The pack pre-selects the relevant categories so you don’t have to assemble them by hand.

Next steps

• Guardrails - the full content and prompt-security policy engine that PII redaction is part of.
• RAG security - per-chunk evaluation and redaction for retrieval pipelines.
• Virtual keys - scope which keys and workspaces a redaction policy applies to.
• Audit logs - tamper-evident evidence with secrets recorded as length-only hints.