> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# PII Filtering

> The role MCP Manager plays in keeping customer PII out of AI: why teams won't connect their most valuable MCP servers until PII is controlled, how the gateway filters PII inline before it reaches the model or an external tool, how detection and actions work at a high level (with links to the rule engines), the compliance drivers (GDPR, HIPAA, SOC 2), and the honest limits of automated detection.

The data that makes AI useful is the same data that makes it risky. The moment you connect a CRM, a project tracker, a support inbox, or a shared drive to an AI client, that tool's responses — names, emails, account numbers, health or financial details — flow straight into the model's context. For many teams this is the single thing standing between them and adopting MCP at all: they will not connect their most valuable systems until they can guarantee that **personally identifiable information (PII) is controlled before it reaches the model**. PII filtering on the MCP Manager gateway is how that guarantee is made.

## Why this is the blocker

Consider a regulated insurer evaluating MCP — a pattern we see constantly. They want to connect their work tools (a project tool like Asana, a CRM, and others) to AI to move faster. They can't, and the reasons are specific:

* **Connecting a tool is all-or-nothing.** Approving a connector in the AI client exposes whatever the connecting user can see. A senior employee with broad access pulls a far wider scope of customer data into the model than anyone intended.
* **Data leaks across a multi-step workflow.** Once customer data from an approved tool is in the model's context, a *different*, unapproved tool used later in the same workflow can end up seeing it — crossing the boundary their data-processing agreements draw.
* **You can't un-send data to an LLM.** There is no "delete" once PII has been handed to a model or a third party. Prevention before the data is exposed is the only reliable control.

A gateway is the one place to enforce a policy on this, because every tool call and result passes through it. PII can be **masked, anonymized, or blocked before it ever reaches the model — or before it leaves your boundary for an external tool**. That is what turns "we can't connect that system" into "we can connect it safely."

## The role the gateway plays

MCP Manager sits inline and filters PII in the path of the call, on whichever leg matters:

```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart LR
  S["🖥️<br/>MCP server result<br/>contains customer PII"] --> GW["🛡️<br/>MCP Manager gateway<br/>PII filtering"]
  GW -->|"PII masked / anonymized / blocked"| M["🤖<br/>AI client & model<br/>sees only safe data"]
  classDef gateway fill:#0086ff,color:#ffffff,stroke:#062b4c,stroke-width:2px;
  classDef client fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
  classDef server fill:#aed8ff,color:#062b4c,stroke:#0b4880,stroke-width:1.5px;
  class GW gateway;
  class S server;
  class M client;
```

* On the **response leg**, the gateway strips PII out of a tool's *result* before it reaches the client and model — the most common case.
* On the **request leg**, it can stop PII in a tool's *arguments* from leaving for an external or ungoverned server in the first place.

Because the gateway also brokers a real [identity](/security/authentication-and-identity) on every call and curates which tools are even exposed (see [Feature Provisioning](/features/feature-provisioning)), PII filtering layers on top of access controls that already narrow *what* a given user can reach — filtering is the safety net for the data that legitimately does come back.

## How PII filtering works

PII filtering is delivered through [gateway rules](/features/gateway-rules/overview). At a high level, every rule pairs a way to **detect** sensitive data with an **action** to take when it's found. You don't have to host or operate any of the detection engines — MCP Manager runs them for you.

**Ways to detect PII**

* **Regular expressions** — best for *structured* values with predictable shapes: card numbers, Social Security numbers, national IDs, API keys. Runs in-process, so it's the fastest option. See [Regex](/features/gateway-rules/regex).
* **Microsoft Presidio** — context-aware detection for *unstructured* PII like names, emails, phone numbers, and locations, using Microsoft's open-source engine, run as a managed add-on. See [Microsoft Presidio](/features/gateway-rules/presidio).
* **Custom engines and bring-your-own models** — for advanced or domain-specific policy: connect [AWS Bedrock Guardrails](/features/amazon-bedrock), [Lakera Guard](/features/lakera-guard), or [your own webhook](/advanced/building-a-custom-rule-engine) that inspects the request/response and can redact at the specific field level or defer the decision to a model you trust.

**What to do when PII is found**

| Action      | Effect                                                                                                                  | Good for                                          |
| ----------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| **Block**   | The whole message is withheld.                                                                                          | High-stakes data that must never pass.            |
| **Replace** | Each detected value becomes a typed tag, e.g. `<EMAIL_ADDRESS>` or `<CREDIT_CARD>`.                                     | Keeping a result readable while removing the PII. |
| **Mask**    | Each character becomes an asterisk, preserving length.                                                                  | Showing a value's shape without its content.      |
| **Hash**    | The value becomes a truncated SHA-256, so the agent can still **correlate repeats without ever seeing the real value**. | Analytics and joins on sensitive keys.            |
| **Redact**  | The matched text is removed entirely.                                                                                   | Stripping values you don't need at all.           |

The full mechanics — detection hooks, rule ordering, alerts, and failure modes — live in [Gateway Rules](/features/gateway-rules/overview), and the broader in-path enforcement story is in [Runtime Protections](/security/runtime-protections).

## Compliance: why filtering at the gateway matters

For regulated teams this isn't a nice-to-have — it's a precondition for using AI at all:

* **GDPR and UK GDPR.** Sending a customer's name or email to a model without a basis, or letting it cross into a tool you don't have an agreement with, is a processing problem. Masking PII at the gateway keeps it out of the model's context to begin with.
* **HIPAA and healthcare-adjacent obligations.** PHI flowing through AI tooling is a gating concern for healthcare and insurance buyers; inline redaction lets you connect systems that would otherwise be off-limits.
* **SOC 2 and internal data-handling policy.** Demonstrating a control that inspects and redacts sensitive data in flight — and proving it — is exactly what reviewers look for.

Two properties make the gateway the right enforcement point. First, **prevention beats cleanup**: because you can't retract data once an LLM or third party has it, filtering *before* exposure is the only control that actually works. Second, **the gateway produces the evidence**: every call — and every time a rule redacts or blocks something — is recorded in your [audit trail](/security/audit-and-observability), which is what turns "we filter PII" into something you can show an auditor.

Filtering shapes what the **client** receives, not whether the call is logged: by default a redaction rule produces an audit record rather than erasing one, and it does not scrub sensitive values from the stored log. If your compliance posture requires that sensitive payloads not be written to the log at all, that can be configured for your workspace — discuss it with your MCP Manager contact. See [Audit & Observability](/security/audit-and-observability#what-every-call-records) for exactly what each leg stores.

## Honest limits

Automated PII detection is a strong control, not a perfect one, and it's worth being clear about that:

* **No detector catches everything.** Pattern- and model-based detection can miss PII, especially in free-text fields like a task title or a comment. Treat filtering as one layer, not a guarantee.
* **Accuracy is tuning-dependent.** Entity selection and confidence thresholds materially change what Presidio catches; test against your own data and adjust. See [Confidence threshold](/features/gateway-rules/presidio#confidence-threshold).
* **Layer your defenses.** Combine engines — for example, a regex rule for structured IDs, Presidio for names and addresses, and a custom engine for domain-specific policy — and choose **Block with a fail-closed [failure mode](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails)** for data that must never slip through, so an engine outage fails safe rather than open.
* **Roll out with alerts first.** Run a new rule on a non-destructive action with [alerts](/features/alerts) on, watch what it catches in your traffic, and switch it to Block once you trust it.

## Get started

Prefer to follow along step by step? [Redact PII from tool responses with Presidio](/tutorials/pii-filtering) does exactly this on a sample gateway.

<Steps>
  <Step title="Open a gateway's Rules tab">
    From [Gateways](https://app.mcpmanager.ai/settings/gateways), pick the gateway that handles sensitive data and open its **Rules** tab.
  </Step>

  <Step title="Add a PII rule">
    Choose a detection method — [regex](/features/gateway-rules/regex) for structured IDs, [Presidio](/features/gateway-rules/presidio) for names and contact details — set the **response** hook, and pick an action such as **Replace** or **Block**.
  </Step>

  <Step title="Set the failure mode and test">
    For high-stakes data, set the failure mode to **Block** so the rule fails closed, then test against representative tool results.
  </Step>

  <Step title="Watch, then enforce">
    Turn [alerts](/features/alerts) on, review what the rule catches in your [logs](/features/viewing-logs), tune the threshold or patterns, and tighten to **Block** once you're confident.
  </Step>
</Steps>

## Further reading

<CardGroup cols={2}>
  <Card title="Gateway Rules" icon="shield-halved" href="/features/gateway-rules/overview">
    The full rule model — detection methods, hooks, actions, ordering, and alerts.
  </Card>

  <Card title="Microsoft Presidio" icon="user-shield" href="/features/gateway-rules/presidio">
    Context-aware PII detection and anonymization, run as a managed add-on.
  </Card>

  <Card title="Regex" icon="asterisk" href="/features/gateway-rules/regex">
    Fast, in-process matching for structured secrets and IDs.
  </Card>

  <Card title="Custom Rule Engines" icon="plug" href="/features/gateway-rules/custom-rules-engines">
    Bring AWS Bedrock, Lakera Guard, or your own model for field-level policy.
  </Card>

  <Card title="Runtime Protections" icon="shield-halved" href="/security/runtime-protections">
    How inline inspection and data-loss prevention work across the gateway.
  </Card>

  <Card title="Audit & Observability" icon="magnifying-glass-chart" href="/security/audit-and-observability">
    The audit trail that proves your PII controls to an auditor.
  </Card>
</CardGroup>