Microsoft Presidio

How the Microsoft Presidio detection method finds and anonymizes PII in MCP Manager: the analyzer/anonymizer two-pass engine MCP Manager runs for you as a managed add-on, the selectable entity types, the 0.2 default confidence threshold, why it is less reliable for names in free-form text, the Allow/Block failure mode, and the Block and Replace actions.

Microsoft Presidio is a gateway rule detection method in MCP Manager that finds and anonymizes personally identifiable information (PII) in tool messages — credit cards, Social Security numbers, emails, names, locations, and more. Presidio is Microsoft’s open-source PII framework; in MCP Manager it runs as a managed add-on, so you get its detection and anonymization without deploying, scaling, or securing it yourself. Select Microsoft Presidio as the Detection method in the rule editor.

Microsoft Presidio is available as an add-on. If your workspace doesn’t have it enabled, choosing this detection method shows a Schedule consultation option instead of the configuration fields. The built-in regex method is always available. For the framework itself, see the Microsoft Presidio documentation.

How Presidio detection works

Presidio cleanly separates detection from anonymization, and MCP Manager runs both stages for you on each tool message:

1. Analyzer — identifies candidate PII and assigns each finding a confidence score, combining named-entity-recognition (NER) models, regular-expression recognizers, checksums, and surrounding-context cues.
2. Anonymizer — takes the analyzer’s findings and transforms the matched spans according to the rule’s action.

Because detection is model-driven rather than a fixed pattern list, accuracy depends on configuration — chiefly the entity types you select and the confidence threshold (below). A Presidio rule scans on whichever detection hook you chose (request or response).

Entity types

In the rule editor you choose which entity types to detect. If you select none, all supported entity types are detected. The entity types MCP Manager exposes are Presidio’s standard global recognizers:

• Financial — CREDIT_CARD, IBAN_CODE, US_BANK_NUMBER, CRYPTO (wallet addresses)
• Government and national IDs — US_SSN, US_ITIN, US_PASSPORT, US_DRIVER_LICENSE, UK_NHS, MEDICAL_LICENSE
• Contact and identity — PERSON, EMAIL_ADDRESS, PHONE_NUMBER, LOCATION, NRP (nationality, religious, or political group)
• Technical — IP_ADDRESS, URL, DATE_TIME

Selecting specific entities narrows detection to just those categories, which reduces noise when you only care about, say, credit cards and SSNs.

Confidence threshold

The Confidence threshold is the minimum score — from 0.0 to 1.0 — an entity must reach to count as a detection. The default is 0.2. Lower values catch more entities but produce more false positives; higher values are more conservative. Because Presidio’s accuracy is tuning-dependent, treat the threshold as a dial: start at the default, watch what fires in your logs and alerts, and raise it if benign text is being flagged.

Reliability with names and free-form text

Presidio’s reliability is not uniform across entity types, and the difference decides what you can safely trust it for. Structured identifiers — CREDIT_CARD, US_SSN, EMAIL_ADDRESS, IBAN_CODE, IP_ADDRESS, and the like — are found with patterns, checksums, and validation, so Presidio catches them dependably wherever they appear. Names and other context-dependent entities — PERSON, LOCATION, and NRP — are found by NLP models, which are markedly less reliable on short, terse, or loosely structured text. A person’s name in a task title, a column header, or a single-word field can be missed even when the same name in a full sentence would be caught.

Do not rely on Presidio alone for high-confidence redaction of names or other sensitive content buried in free-form text. Presidio is a strong, fast layer for structured PII, and a missed name in unstructured text is an expected limitation of model-based detection rather than a defect. When names in free text must not slip through, add a classifier-based detection method alongside it:

• Amazon Bedrock Guardrails — managed PII and content policies that can detect and de-identify free-form text.
• Lakera Guard — classifier-based detection that blocks messages carrying the flagged content.
• A custom rule engine — your own classifier or data-loss-prevention service.

A practical pattern is to keep a Presidio rule for structured PII and place a classifier-based rule above it for names and other free-form sensitive content.

Failure mode

Presidio runs as a service the gateway calls, so a Presidio rule has a Failure mode for when it’s unreachable, too slow, or errors:

• Allow — let the message through unchanged. This is the default.
• Block — block the message as a precaution.

Choose Block when it matters more that PII never slips through than that the tool keeps working during a Presidio outage. See Failure mode.

Actions

Presidio rules support two actions:

• Block — block the whole message when any selected entity is detected; the anonymizer is not invoked.
• Replace — run the anonymizer to replace each detected entity with a tag naming its type. For example, Customer email: [e-mail] becomes Customer email: <EMAIL_ADDRESS>, and a card number becomes <CREDIT_CARD>. The surrounding text is left intact.

Presidio’s Replace tags each entity by type (<EMAIL_ADDRESS>, <CREDIT_CARD>, …), which is more informative than the single <SENSITIVE> placeholder a regex Replace rule uses. The other regex actions — redact, mask, and hash — are not available for Presidio; use a regex rule if you need those.

Example: broad PII protection

Detection method: Microsoft Presidio · Entity types: none (detect all) · Confidence threshold: 0.5 · Failure mode: Block · Action: Replace

This catch-all rule tags every detected entity by type and fails closed if the service is down. Combine it with more targeted regex rules placed above it — for example, blocking prompt injection first, then replacing PII as a safety net. See Rule order.

Presidio sits at a different layer than Amazon Bedrock and Lakera Guard. Those are policy and safety services that return an allow/block decision on a whole interaction; Presidio is a focused PII detection-and-transformation engine that tags or removes sensitive spans in place. They complement each other — you might screen for prompt injection with one and tag PII with Presidio.

Good to know

Microsoft is candid about Presidio’s limits, and they apply here too:

• No detection is guaranteed. Presidio uses automated detection, so it won’t catch every piece of sensitive data. Treat it as one layer, not a complete guarantee, and pair it with other controls for high-stakes data.
• Accuracy is tuning-dependent. Out of the box it’s strong on common PII, but the confidence threshold and entity selection materially change recall and the false-positive rate. Tune against your own traffic.
• It’s a building block, not a full DLP product. Presidio complements enterprise data-loss-prevention tooling rather than replacing it.
• No per-call charges. Once the Presidio add-on is enabled on your plan, MCP Manager does not meter or charge per scan or per detection. Run Presidio rules on as much traffic as you need — there is no per-call or per-message fee for using it.

Because MCP Manager runs Presidio as a managed service, you don’t take on the open-source project’s deployment concerns yourself — hosting the NER models, securing the API, and scaling the containers — but the detection-quality caveats above still apply.

Further reading

Amazon Bedrock Guardrails

A managed guardrail for free-form text, added as a custom rule engine.

Lakera Guard

Classifier-based detection for names and free-form sensitive content.

Gateway Rules Overview

Detection methods, hooks, failure modes, actions, and rule ordering.

PII Filtering

Where Presidio fits in keeping customer PII out of the model.

External sources

Presidio documentation

GitHub repository

Anonymizer reference

FAQ