Open source, Apache 2.0

PII Firewall

How we built an open-source library that lets healthcare and fintech teams send sensitive data to LLMs without violating privacy.

Visual preview of PII Firewall

01

The Real Problem: Old Tools for New Use Cases

Traditional Data Loss Prevention (DLP) tools were built for a different era: redacting static databases, scanning corporate emails, blocking USB drives. They're one-way machines—they detect sensitive data and destroy it.

But LLMs need something completely different. You can't just redact text and send it to Claude. If you send "[REDACTED] has a history of [REDACTED]", the model can't reason about anything. The context is dead.

You needed something reversible. A way to hide sensitive information in transit, but still let the LLM generate useful responses. Then, when the response comes back, you needed to rehydrate it with real data.

Existing tools didn't do this. So I built it.

02

The Architecture: Detect → Sanitize → LLM → Rehydrate

PII Firewall works as a transparent layer that sits between your application and any LLM. It intercepts data in both directions.

On the way to the model:

  • Detects sensitive entities (names, emails, credit card numbers, ID numbers)
  • Replaces them with reversible tokens: "John Doe" → "[PERSON_001]"
  • Stores the mapping in a secure local vault
  • The model receives only the sanitized prompt

On the way back:

  • Intercepts the model's response in real-time
  • Restores original data: "[PERSON_001]" → "John Doe"
  • The user never sees tokens—they see real, personalized data

The magic: the model generates responses using tokens, but your user sees exactly what they expect to see. No friction. No lost context. Zero privacy sacrifice.

03

Domain Awareness: Know What to Hide and What to Keep

This is where most tools fail: if you mask every identifiable piece of information in a medical transcript, the LLM loses the clinical context it needs to generate a useful summary.

PII Firewall solves this with Domain Profiles. You select your industry and the system automatically understands what to hide and what to keep.

Healthcare: Pseudonymizes patient names and IDs → reversible tokens. Generalizes ages into decades (43 years → "40-49"). But KEEPS diagnoses, procedures, and drug names intact. Clinical context survives.

Finance: Protects customer names and IBANs. Allows transaction amounts to pass through. They're not regulated PII, but they're crucial for analysis.

Legal: Aggressively pseudonymizes party names. Retains company names, court agencies, and legal citations. It's public record anyway.

Your industry has specific rules. That's why this exists. It's not a generic product; it's domain-aware.

04

Multi-Engine Detection: Speed vs. Accuracy Trade-offs

Detecting PII isn't a one-solution-fits-all problem. Sometimes you need ultra-low latency for structured IDs. Other times you need deep contextual understanding to catch a name hidden in messy free-text.

PII Firewall includes 7 interchangeable engines. Choosing one is a deliberate trade-off between latency and precision.

Regex: Less than 1ms. Perfect for structured patterns (emails, SSNs, Spanish DNIs). But no contextual understanding.

Presidio: 50-200ms. Named Entity Recognition. Good balance between speed and accuracy for most cases.

GLiNER: 100-400ms. Zero-shot NER—no domain-specific training required. Flexible for new languages and patterns.

Specialized Transformers: 100-500ms. If you need medical or legal precision, train your own model. Direct integration.

And here's the smart part: Auto Language Detection supporting 55+ languages. The system automatically detects if it's processing Spanish, French, Dutch, whatever. Thread-level caching reduces latency to 0ms after the first turn.

05

Developer Experience: Invisible Integration

I designed this to feel like it doesn't exist. I didn't want to force anyone to rewrite their application.

You plug directly into your existing LLM pipeline. LangChain, LlamaIndex, raw OpenAI clients—it works with everything.

from pii_firewall import PrivacyFirewallSDK

sdk = PrivacyFirewallSDK.create(domain="healthcare", detector="presidio")
result = sdk.secure_call(text=sensitive_text, llm_client=my_llm)

That's it. The SDK handles sanitization, masking, rehydration. Your code never even knows it's happening.

And it's built with regulatory compliance at its core. Right to be Forgotten (GDPR). One command: firewall.forget(thread_id="...") instantly destroys all token mappings for that session. Permanently. The bridge between anonymized data and real identities evaporates.

06

Why It Matters: Beyond Static Redaction

The era of static data redaction is over. LLMs require dynamic, bidirectional privacy controls that understand the semantic weight of the data they're protecting.

By treating PII detection, pseudonymization, and real-time rehydration as a single unified lifecycle, PII Firewall allows engineering teams to build powerful LLM applications on top of sensitive data—without ever compromising trust.

It's not another regulatory checkbox. It's architecture. It's how things should work from the start.

What I built

Architecture of PII Firewall
The reversible round trip keeps identifiers outside the model while preserving a useful final response for the application.

Related writing

The part of the work worth explaining.

Published articles and prepared topics documenting decisions, problems and lessons.

Article in preparation

Reversible pseudonymization around an LLM call

How the detect, sanitize, generate and rehydrate cycle stays deterministic.

Article in preparation

Regex, Presidio or GLiNER: choosing a PII backend

Tradeoffs in precision, latency, multilingual support and deployment cost.

Article in preparation

Designing erasure into a token vault

Making GDPR Article 17 a data-model capability instead of a manual process.