FDE Times: Microsoft Presidio masks PII before LLM calls — but its docs won’t promise it catches everything
A 5 November FDE Times tools guide walks FDEs through Presidio’s Analyzer and Anonymizer: English-only defaults miss many national IDs and non-English names, LiteLLM’s output_parse_pii only restores tokens (it does not scan responses unless you set the filter scope), and the API has no built-in auth—so measure miss rates on labelled customer text before you promise “everything is masked.”
When a customer’s security team asks whether personal data leaves for a model provider, Microsoft’s open-source Presidio is the library many FDEs reach for. A 5 November FDE Times tools guide argues that installing it and claiming “PII is masked” oversells what the authors themselves promise: the FAQ says detection makes errors, there is no warranty or SLA, and SaaS PII services often cover more entities.
Presidio splits into an Analyzer (NER and regex recognizers for cards, email, PERSON, LOCATION and some country IDs) and an Anonymizer (replace, redact, mask, hash, encrypt). Defaults ship only English spaCy models, so Vietnamese names and internal IDs such as KH-482913 routinely slip through unless you write PatternRecognizers with language-appropriate context words. The project now lives under data-privacy-stack with docs at presidio.dataprivacystack.org.
Gateway deployments that mask outbound prompts still fail the return path if LiteLLM’s output_parse_pii only swaps tokens back: set presidio_filter_scope to output or both to scan responses. Presidio’s HTTP endpoints also have no built-in authentication, so they need an auth layer or the masking service becomes an open door to the PII it is meant to protect.
For FDEs, the credible pitch is one measured layer among several: hand-label a sample of the customer’s real text, report miss rates by entity type, then add recognizers for internal identifiers before go-live.
Source: fdetimes.net