Keep Sensitive Data Out of LLM Prompts with Privacy-First PII Redactor

Developers are integrating external LLMs into support tools, internal search, document processing, email automation, and AI agents. The problem is that real application data often contains names, email addresses, phone numbers, payment information, customer identifiers, and other sensitive values.

Github link here

Privacy-First PII Redactor is an open-source Python proxy that removes this information before a prompt reaches an external AI provider.

Instead of sending this:

Summarize the account activity for John Smith at john@example.com.
His card number is 4111 1111 1111 1111.

Your application sends:

Summarize the account activity for <PERSON_1> at <EMAIL_1>.
His card number is <CREDIT_CARD_1>.

The original values remain inside your infrastructure.

How it works

The redactor runs between your application and the LLM provider.

Application
    ↓
Privacy-First PII Redactor
    ↓
External LLM Provider

Incoming text passes through multiple detection layers:

• Deterministic regex patterns for emails, phone numbers, credit cards, IBANs, IP addresses, URLs, and similar structured values
• Microsoft Presidio for broader PII analysis
• spaCy named-entity recognition for names, organizations, and locations
• Custom recognizers for internal identifiers such as customer IDs or project codes

Detected values are replaced with consistent placeholders such as <PERSON_1>, <EMAIL_1>, and <CUSTOMER_ID_1>.

When the same value appears several times in one request, it receives the same placeholder. Overlapping detections are resolved using recognizer priority and confidence scores.

Use it as a Python library

Install the package:

pip install privacy-pii-redactor

Then redact text directly in your application:

from pii_redactor import PrivacyRedactor

redactor = PrivacyRedactor()

result = redactor.redact(
    "Contact John at john@example.com, card 4111 1111 1111 1111"
)

print(result.redacted_text)

Output:

Contact <PERSON_1> at <EMAIL_1>, card <CREDIT_CARD_1>

For workflows where the original values are still needed after the LLM responds, the mapping can be restored:

restored = redactor.restore(
    result.redacted_text,
    result.mapping,
)

print(restored.restored_text)

Redaction can also be configured as a one-way operation, without storing any mapping.

Use it as an API or LLM proxy

The project includes a FastAPI service with endpoints for detection, redaction, restoration, and OpenAI-compatible LLM proxying.

Start it with Docker:

docker compose up

Redact a prompt:

curl -X POST http://localhost:8000/v1/redact \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Email john@example.com",
    "store_mapping": true
  }'

The LLM proxy mode handles the complete flow:

1. Receive the original chat-completion request.
2. Detect and redact sensitive values.
3. Forward only the sanitized request to the configured LLM.
4. Receive the generated response.
5. Optionally restore the original values.
6. Return the final response to the application.

This makes it possible to add redaction to an existing LLM integration without placing privacy logic throughout the application code.

Temporary and reversible mappings

Reversible mappings can be stored in Redis with a configurable expiration time. The default lifetime is 15 minutes.

<PERSON_1> → John Smith
<EMAIL_1> → john@example.com

Redis persistence is not required, and mappings can be deleted immediately after restoration. For local development and simple use cases, an in-memory store is also available.

The service avoids logging original request bodies or detected PII values. Authentication can be enabled for sensitive endpoints, and stored mappings are accessed through random identifiers.

Custom application-specific identifiers

Generic PII detection is not enough for many production systems. Internal data may contain customer numbers, contract references, employee IDs, ticket numbers, or project codes.

Custom recognizers can be defined using YAML:

custom_recognizers:
  - name: CUSTOMER_ID
    pattern: "\\bCUS-[0-9]{6}\\b"
    confidence: 0.95

  - name: PROJECT_CODE
    pattern: "\\bPRJ-[A-Z]{3}-[0-9]{4}\\b"
    confidence: 0.90

The following input:

Review customer CUS-123456 under project PRJ-ACT-2026.

becomes:

Review customer <CUSTOMER_ID_1> under project <PROJECT_CODE_1>.

This allows development teams to protect business-sensitive identifiers alongside traditional personal data.

Designed for self-hosting

Privacy-First PII Redactor runs inside your own environment. It can be used as:

• A Python dependency
• A command-line tool
• A standalone REST service
• An internal gateway for multiple applications
• A transparent proxy in front of an OpenAI-compatible provider

Configuration is available through environment variables and optional YAML files. The project supports Docker deployment, API-key authentication, Redis-backed mappings, custom confidence thresholds, and interactive OpenAPI documentation.

An additional security layer, not a compliance shortcut

PII detection is not perfect. Structured values such as email addresses and credit card numbers are usually easier to detect than person names, addresses, or context-dependent identifiers.

The project reduces the amount of sensitive information exposed to external AI services, but it does not automatically make an application compliant with GDPR, HIPAA, or other regulations. It should be combined with normal access control, encryption, retention policies, provider agreements, and security reviews.

Privacy-First PII Redactor provides developers with a practical boundary: raw sensitive data stays inside the application environment, while external LLMs receive only the information required to perform the task.

The project is open source, MIT licensed, Python 3.11+, and designed to be extended for real application requirements.

Disclaimers:

I’ve built this while developing ActorDo, a work assistant over email, calendar and tasks

Project is also described and has links here: https://onemillionlines.com/project/privacy-pii-redactor