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:

• 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 on every call and curates which tools are even exposed (see 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. 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.
• 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.
• Custom engines and bring-your-own models — for advanced or domain-specific policy: connect AWS Bedrock Guardrails, Lakera Guard, or your own webhook 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, and the broader in-path enforcement story is in 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, which is what turns “we filter PII” into something you can show an auditor.

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.
• 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 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 on, watch what it catches in your traffic, and switch it to Block once you trust it.

Get started

1. Open a gateway's Rules tab

   From Gateways, pick the gateway that handles sensitive data and open its Rules tab.

2. Add a PII rule

   Choose a detection method — regex for structured IDs, Presidio for names and contact details — set the response hook, and pick an action such as Replace or Block.

3. 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.

4. Watch, then enforce

   Turn alerts on, review what the rule catches in your logs, tune the threshold or patterns, and tighten to Block once you’re confident.

Further reading

Gateway Rules

The full rule model — detection methods, hooks, actions, ordering, and alerts.

Microsoft Presidio

Context-aware PII detection and anonymization, run as a managed add-on.

Regex

Fast, in-process matching for structured secrets and IDs.

Custom Rule Engines

Bring AWS Bedrock, Lakera Guard, or your own model for field-level policy.

Runtime Protections

How inline inspection and data-loss prevention work across the gateway.

Audit & Observability

The audit trail that proves your PII controls to an auditor.