Detection coverage
Implemented detectors
The current PII engine implements detection for 13 entity types across three detection levels:
| Entity type | Level 1 (regex) | Level 2 (spaCy NER) | Level 3 (GLiNER) |
|---|---|---|---|
| Yes | — | Yes | |
| PHONE | Yes | — | Yes |
| SSN (US Social Security) | Yes | — | — |
| PERSONNUMMER (Nordic) | Yes | — | — |
| IBAN | Yes | — | — |
| CREDIT_CARD | Yes | — | — |
| IP_ADDRESS (v4) | Yes | — | — |
| IP_ADDRESS_V6 | Yes | — | — |
| DATE_OF_BIRTH | Yes | — | Yes |
| PASSPORT | Yes | — | — |
| NAME | — | Yes (PERSON) | Yes |
| ADDRESS | — | Yes (GPE, LOC) | Yes |
| ORGANIZATION | — | Yes (ORG) | Yes |
Total implemented entity types: 13.
Methodology
Level 1 — Regex
Structural PII with well-defined formats (email, phone, SSN, IBAN, credit card numbers, IP addresses, dates of birth, passport numbers) is detected using regular expressions compiled against the shared pii-patterns/patterns.json pattern library. Regex patterns are exact-match optimised for speed; they trade recall for near-zero false-positive rates on canonical formats.
Level 2 — spaCy NER
Names, organisations, and addresses are detected using spaCy’s en_core_web_sm English NLP model. This adds contextual understanding for entities that have no fixed format. Level 2 is additive — regex detections from Level 1 are retained and deduplicated by span overlap.
Level 3 — GLiNER
GLiNER (urchade/gliner_small-v2.1) is a generalised NER model that uses a free-text label set. Level 3 runs GLiNER over the same labels (person, organization, location, email, phone, date, money) and merges results with Levels 1 and 2. Level 3 improves recall for context-dependent mentions that regex and spaCy miss.
The three levels are composable, and all of them run on your own device — the gateway is a pure blind relay and performs no server-side detection on relayed content. The desktop app runs all three when the local Python sidecar is available; the browser chat and extension run Level 1 (regex, in-browser WASM) plus an on-device name model; the local proxy runs Level 1 plus an optional on-device NER model (Ollama + Phi).
Known evasions
The following techniques are known to bypass or degrade detection. We document them because honest scoping helps customers make informed decisions.
Unicode normalisation attacks
Inserting Unicode look-alikes, combining characters, or zero-width characters into PII values can break regex matching. For example:
john.doe@example.com(zero-width space before the dot) — fails the EMAIL regex.4111‑1111‑1111‑1111(en-dash instead of hyphen) — fails the CREDIT_CARD regex.
Mitigation status: Preprocessing to strip zero-width characters before regex evaluation is implemented. Full Unicode confusable normalization (UAX #39) is not yet implemented.
Base64 encoding
PII encoded as Base64 (e.g. am9obi5kb2VAZXhhbXBsZS5jb20=) is not recognised by any current level of detection. Base64-obfuscated content passes through as an opaque token.
Mitigation status: Not implemented. Detecting base64-encoded PII requires a decode-and-re-detect pass, which is on the evaluation roadmap.
Homoglyph substitution
Replacing characters with visual look-alikes from other Unicode scripts (e.g. Cyrillic о for Latin o in an email address) evades both regex and spaCy detection.
Mitigation status: Not implemented. Homoglyph normalisation is a roadmap item.
Non-English names and addresses
The spaCy Level 2 model (en_core_web_sm) is English-only. Names and addresses in non-Latin scripts, or in languages where spaCy’s English model has poor recall, will not be detected at Level 2. GLiNER (Level 3) has somewhat better multilingual coverage, but this has not been formally evaluated.
Mitigation status: Multilingual NER evaluation is planned post-launch.
Semantic PII without structural markers
Information that is personally identifying in context but has no structural marker — for example the patient in bed 7 or the employee who resigned last Tuesday — is not detected by any current level.
Mitigation status: Out of scope for the current engine. This is a research-grade problem requiring domain-specific context understanding.
Roadmap
| Item | Status |
|---|---|
| Evaluate against Ai4Privacy benchmark | Planned post-launch |
| Evaluate against PII-NER benchmark | Planned post-launch |
| Unicode confusable normalization (UAX #39) | Planned |
| Base64 decode-and-re-detect pass | Planned |
| Multilingual NER (non-English names, addresses) | Planned |
| Publish precision/recall numbers for each entity type | Planned post-benchmark evaluation |
We will publish benchmark results when they are complete. We will not claim precision or recall numbers that we have not measured.
What this means for your deployment
If your use case involves:
- Structured PII (emails, credit cards, SSNs, IBANs, IP addresses) — coverage is high via regex.
- Names, organisations, locations in English — covered by Level 2/3 with moderate recall.
- Adversarial inputs designed to evade detection — the known evasions above apply; consider additional customer-side sanitisation.
- Non-English or multilingual content — coverage is limited today.
For high-assurance environments, treat the PII engine as a defence-in-depth layer, not a sole control. Pre-tokenisation at the application layer (explicitly tokenising known sensitive fields before they enter any text prompt) provides stronger guarantees than relying on automatic detection.