01
Tokenization, not redaction
Redaction and masking destroy the context a model needs to reason. Deterministic tokens preserve it: same value, same token, full output quality.
PII protection for LLMs
Prevent sensitive data from reaching your AI.
Use customer data in AI without sending the identifiers.
NoPII is an LLM privacy proxy that detects and tokenizes sensitive values before your application calls a model, then restores those values in the response.
One million protected tokens a month. No credit card. Live in minutes.
Real data goes into your application.
Tokens go to the model provider.
Your users never see the difference.
One proxy. Every provider.
Switch providers without reconfiguring your security.
- OpenAI
- Anthropic
- Google Gemini
- xAI
- DeepSeek
- Mistral
- Groq
- Together
- Fireworks
Every prompt is a data transfer. Almost no one treats it like one.
The fastest-growing data flow in your company is the one with the least oversight: the prompts. Names, account numbers, clinical notes, and salary figures leave your environment thousands of times a day, bound for third-party model providers, because that is what makes the AI features work. Their logs. Their retention. Their jurisdictions. Your liability under HIPAA, GDPR, and every contract you have signed.
Compliance responds the only way it can: it says no. The roadmap stalls, or it routes around them. So engineers reach for redaction, stripping the sensitive values out before the prompt goes. And redaction breaks the model. Replace a customer's name with [REDACTED] in sentence one and the model can no longer connect it to the account in sentence three. You protected the data by removing the intelligence you shipped the feature for.
The model never needed the real values. It needed consistent ones.
The dilemma is false. Swap every sensitive value for a stable token before the prompt leaves, restore it when the response returns, and the model reasons exactly as before while the provider never holds a single real identifier. That is NoPII, and it deploys in the time it takes to change a base URL.
Built for LLM traffic, not retrofitted from a data-loss tool.
02
Round-trip detokenization
Responses come back with real data restored. Your application behaves exactly as before. Users never see a token.
03
Fail-safe by default
If tokenization ever fails, the request is blocked. Sensitive data never leaks on a best-effort basis. That is not a setting, it is the architecture.
04
Context phrase neutralization
Phrases that trigger model safety refusals on tokenized data are neutralized in the proxy. A real failure mode that an in-house build rarely anticipates.
05
Secret and API key detection
Fourteen pattern families of credentials, from cloud keys to database connection strings to private keys, caught in the same pass as PII detection, on every request including streaming.
What two lines of code does for your PII privacy.
The launch unblocked
Compliance gets architecture instead of assurances: tokenized traffic, per-request audit logs, block-by-default failure, BAA available. The “no” becomes “yes, through the proxy.” NoPII is not just a privacy layer; it is an AI adoption layer, built for teams navigating HIPAA, GDPR, CCPA, PCI DSS, SOX, and the EU AI Act.
Model freedom kept
One proxy fronts 9 providers. Switch models, run several at once, test next week's release. Your privacy controls do not reset when your model choice changes.
Intelligence preserved
Deterministic tokens keep multi-turn conversations coherent and multi-step reasoning intact. You shipped an AI feature. NoPII does not lobotomize it at the proxy.
Run it where your data lives.
The same proxy, the same detection engine and the same fail-closed behavior, on NoPII Cloud or inside your own perimeter.
NoPII Cloud
Managed by Enigma Vault. Sign up, register a provider key, change your base URL. Lite through Business, plus Enterprise with a custom token band and retention. Billed on protected tokens.
Start free, upgrade in the console
Start freeSelf-hosted edition Enterprise
Run the NoPII proxy and vault inside your own environment under an annual license. No token meter. For teams whose data residency, network boundary or procurement rules keep LLM traffic on their own infrastructure. Enterprise only.
Annual license, no per-token billing
Talk to us about self-hostedDetection, tokenization, restore and fail-closed block are identical on every plan and both editions.
Tokenization is not masking. The difference decides whether your AI still works.
Most tools that touch sensitive data in the AI path redact: they replace values with placeholders or scrub them entirely. The data is protected and the reasoning is destroyed, in one move, and nothing can be restored in the response. NoPII tokenizes deterministically and round-trips, which protects the data and preserves the reasoning.
Broader data-loss suites and AI gateways are useful for their jobs; inline masking inside them is a feature. For NoPII, compliance-grade tokenization of LLM traffic is the entire product.
↳If your problem is employees pasting data into consumer chatbots across hundreds of SaaS apps, you need endpoint data-loss prevention, and we will tell you so. NoPII protects the LLM traffic your applications generate.
| Redaction and masking | NoPII tokenization |
|---|---|
| Placeholders destroy entity relationships | Deterministic tokens preserve them |
| Placeholder redaction leaves nothing to restore | NoPII restores its own tokens, so your app gets real data back |
| Models often refuse scrubbed prompts | Context neutralization prevents refusals |
| Best effort on failure | Block-by-default on failure |
The details that matter when you are building for the AI world.
How tokens behave, what gets logged, and what happens when something fails.
Deterministic tokenization
The same plaintext always produces the same token. “John Smith” in message 1 and message 10 map to the same
[NAME: Ry0Ixd1] token, preserving cross-message context without ever exposing real data to the model.Context phrase neutralization
NoPII does not just mask values. It neutralizes data-type labels that could trigger model safety refusals or re-identify sensitive categories.
Social security number becomes ID number, credit card number becomes account number, date of birth becomes date, so the model processes tokens without recognizing the underlying data type.Fail-safe architecture
If detection encounters an error, the proxy blocks the request rather than letting unprotected data through. Every decision is logged for audit.
Streaming support
Standard and streaming
SSE responses are both supported. Token replacement happens on the fly as chunks arrive, so latency impact is minimal even for long streaming completions.Configurable token retention
Vault tokens carry a time-to-live that controls how long tokenized data is stored. Tokens expire after one day on Lite and after 30 days on Starter. Growth and Business can keep them up to permanently, and Enterprise sets custom retention. When a token expires, the underlying data is permanently deleted from the vault.
Secret and API key detection
Cloud provider keys, model API keys, payment and code-platform tokens, database connection strings, private keys, and auth tokens are detected across 14 pattern families, replaced with vault tokens, restored in the response, and logged in the audit trail. On by default for new accounts.
Reveal policy
A token is revealed only to the end user who created it, within a session that belongs to no one else, under a time-boxed reveal grant, or by a server key with an opt-in scope. Every reveal attempt is logged, refusals included. If the reveal cache is unavailable, reveals are refused, not allowed. How the reveal policy works.
The log is not a second leak
Audit entries record the token, a masked form of the value, entity type, confidence, session, provider, model and timestamp. Plaintext is never written to the log. Purging a token for an erasure request keeps the entry, stamps it with
purged_at and purged_by, and leaves nothing it can resolve to.Drop-in authentication
There is no NoPII-specific header or key to add. Register your OpenAI, Anthropic or other provider key once in the console; NoPII recognizes it on every request, routes to the right provider, and passes it through. Multiple providers can be registered under one account, each independently mapped, with one audit log across all of them.
Observability
Langfuse tracing is opt-in per workspace and records tokenized content only, never plaintext. NoPII honors the W3C
traceparent header for distributed tracing through OpenTelemetry context propagation. Tracing failures never affect proxy requests. Available on Growth and above. Langfuse integration docs.A single unified dashboard for all your teams.
Security, compliance, and engineering share one admin console.
Dashboard
A real-time view of your deployment: total requests, detections, entity-type distribution, provider breakdown.
PII settings
Choose which entity types to detect and adjust detection sensitivity, per tenant.
Configuration
Manage provider keys, configure behavior, connect Langfuse for per-tenant observability. Traces carry tokenized input and output only, so observability never becomes a PII store.
Live chat playground
See the raw input, the tokenized version sent to the model, and the restored response, side by side.
Usage dashboard
API volume, detection rates, and token usage, plus exportable audit and request logs.
Audit log
Every detection and tokenization event, logged with timestamp, entity type, confidence, provider, model and session. The log stores the token and a masked form of the value, never the plaintext, so the audit trail cannot become a second copy of the data.
Token purge
Delete every token for a list of values in one request, to fulfill a GDPR erasure request. The proof is in the log.
One organization, many workspaces.
Isolate teams, products or customers in their own workspace, assign roles, enforce SSO, and keep every detection in a log the auditor can read.
01 Growth and above
Workspaces
A workspace is one tenant: its own provider keys, its own PII settings, its own audit log. Run one per product, per environment or per customer. Billing aggregates at the organization level across all of them.
02 Growth and above
Roles
Owner, Admin and Member. Owners control billing, roles and ownership transfer. Admins manage PII settings, key mappings and members. Members view and update settings but cannot invite. Exactly one owner per organization.
03 Business and above
SSO and access logs
Enforce SSO for everyone in the organization, and review the staff access log alongside the detection and reveal logs.
| Action | Member | Admin | Owner |
|---|---|---|---|
| View dashboard, logs and usage | |||
| Update PII settings and vault configuration | |||
| Invite and remove members | |||
| Change roles, transfer ownership, delete organization |
Multiple workspaces and roles from Growth · Unlimited seats, SSO enforcement, device enrollment and staff access log on Business and Enterprise
Identifiers from every market you operate in.
Eleven entity types on by default, more than twenty-five opt-in, switchable per workspace in the console. Checksum-validated where the format allows it.
Everywhere
Person names
Email addresses
Phone numbers
Street addresses
Credit and debit cards
IBAN
IP addresses (v4 and v6)
API keys, secrets and connection strings
Crypto wallet addresses
URLs
Dates
United States
Social Security numbers
Passport numbers
Driver’s license numbers
Bank account numbers
Medicare Beneficiary Identifiers
Tax IDs (ITIN, TIN, EIN via neutralization)
India
Aadhaar (checksum-validated)
PAN
Passport Beta
Voter ID / EPIC Beta
Vehicle registration Beta
Indian address formats and PIN codes
Devanagari digits
United Kingdom
National Insurance numbers
NHS numbers
UK street address formats
Europe
Spain NIF, DNI and NIE Beta
Italy fiscal code Beta
Italy VAT number Beta
Italy passport Beta
Italy ID card Beta
Italy driving licence Beta
Poland PESEL Beta
Finland personal identity code Beta
Australia and Singapore
Australia TFN Beta
Australia ABN Beta
Australia ACN Beta
Australia Medicare Beta
Singapore NRIC Beta
Singapore FIN Beta
Regional types are off by default and switched on per workspace. Several are in beta, and some are detected only when a label such as “TFN” or “NRIC” precedes the number, because plain numbers pass those check digits too often.
The numbers.
2 lines
total code change to deploy
<5 min
from signup to protected traffic
9 LLMs
providers supported under one proxy
30+ IDs
identifier types across 9 countries
109 tests
published test report
Built on the Enigma Vault, which is PCI DSS Level 1 and SOC 2 Type II · BAA available · Patent Pending
Ship the AI feature. Keep the data.
Start free with one million protected tokens a month, or talk to us about Enterprise.
How NoPII protects each LLM request.
The integration is a base URL swap. Behind it, a full tokenization pipeline built on the Enigma Vault.
# Before: PII goes straight to OpenAI client = OpenAI(api_key="sk-...") # After: PII is intercepted and tokenized by NoPII client = OpenAI( api_key="sk-...", base_url="https://api.nopii.co" )
No new SDK. No middleware rewrite. No NoPII API key. NoPII identifies your account from the provider key already in the request and passes it through; the key is never stored. SSE streaming fully supported.
How PII tokenization works for LLM APIs.
01
Intercept
Your app calls the same SDK it always has. NoPII receives the request first, before it reaches the provider.
02
Detect
Personal data, secrets and API keys are identified in free text, in one pass over everything the model will read.
03
Tokenize
Each detected value is replaced with a deterministic token stored in Enigma Vault. Same value, same token, every time, so the model's reasoning stays consistent across the prompt.
04
Forward
A tokenized request reaches the model provider, which never sees the real data.
05
Detokenize
Tokens in the response are swapped back to real values before your application sees them. Your app receives a normal response and never knows the difference.
Step 02, in detail
Detection runs on message content, system prompts, tool call arguments and tool results, so agents that call functions are covered on the same pass. Sensitivity is adjustable per workspace.
- 11
- entity types on by default
- 25+
- more, opt-in per workspace
- 14
- credential pattern families, same pass
- 109
- tests in the published report
↳And if tokenization ever fails at any step, the request is blocked, not forwarded. Default-closed, by architecture.
See exactly what changes.
Before: the raw prompt
Please update the account for John Smith (SSN: 123-45-6789) at john@acme.com
Names, government IDs, and email addresses all exposed.
After: the tokenized prompt
Please update the account for [NAME: Ry0Ixd1] (ID number: [IDENTIFIER: k8Lm2n]) at [EMAIL: bN3dF5h]
Every sensitive element replaced with a deterministic, reversible token. Context is preserved and the model still understands the prompt.
Decide where plaintext stops.
The proxy keeps real values away from the model provider. The SDKs keep them away from your own servers, databases and logs as well.
Every NoPII deployment protects the model provider. Where you draw the next line is a choice. With the browser SDK, a message is tokenized before it leaves the user’s page, so your backend stores tokens, logs tokens and forwards tokens to the model. The reply comes back tokenized and is revealed only in the browser of the user it belongs to. Your server never handles the plaintext at all.
01
Proxy
Point your server’s LLM client at NoPII. Two lines of code. Live today on every plan.
- LLM provider
- Tokens
- Your backend
- Plaintext
- Your frontend
- Plaintext
02 Preview
Tier 1: browser reroute
The browser SDK reroutes provider calls made from the page through NoPII. For apps that call a provider directly from the client.
- LLM provider
- Tokens
- Your backend
- Not involved
- Your frontend
- Plaintext
03 Preview
Tier 2: tokenize before your own routes
The browser SDK tokenizes requests to your own API, your server forwards tokens to the model in tokens-only mode, and the reply is revealed in the browser. Your servers never see plaintext.
- LLM provider
- Tokens
- Your backend
- Tokens
- Your frontend
- Plaintext
@nopii/browser · @nopii/react (wires into Vercel AI SDK useChat) · @nopii/node · nopii-sdk (Python, sync and async) · @nopii/mock-server (develop offline)
SDKs are in preview and not yet published to npm or PyPI. Package names and APIs may change before 1.0. The browser SDK client API is available on Starter and above.
Scope. No tier takes your frontend out of scope: your page’s JavaScript runs where the user types, so it can read the text. Hosted input elements that close that gap are planned.
Tokenizing is safe to allow widely. Revealing is not.
A token turns back into plaintext only for the user it belongs to, and every attempt, including every refusal, is logged.
When a token is created, NoPII records who created it. A later reveal is allowed only when one of four conditions holds. Anything else is refused, per token, and the SDK leaves the token in place or shows a placeholder you choose. If NoPII’s shared cache is unavailable, reveals are refused rather than allowed: an outage can cost a user their own history view, never another user’s data.
- The caller’s end user created the token.
- The token was created in the session the caller names, and that session belongs to no other user.
- The caller presents a reveal grant that covers the token.
- The caller’s key has the detokenize-any scope, which is opt-in and server-side only.
Reveal grants Business and above
Temporary permission to reveal tokens the caller does not own, for support tools and other cross-user views. Minted by your server with a secret key, scoped to one user or a token list, 60 seconds to one day, with a recorded reason such as a ticket number.
Reveal log Business and above
Every reveal attempt, one entry per token, refusals included: outcome, end user, key or session, client IP and the grant if one was used. Repeated refusals are how probing shows up.
Three key kinds
Secret keys live on your servers only. Publishable keys are origin-restricted and embedded in a page. Device keys are issued by enrollment. Privileged scopes requested for a publishable or device key are dropped, not granted.
The four conditions apply wherever the client API is available, on Starter and above.
The vector database is a second copy of your customer data.
Every document you embed becomes an input to a provider’s embeddings API. NoPII tokenizes it first, so the index holds tokens and search still works.
RAG pipelines embed support tickets, case files, contracts and clinical notes in bulk, and each one is an API call to a model provider. The identifiers go with it. NoPII proxies the embeddings endpoint the same way it proxies chat: every text in the request is tokenized before it reaches the provider, and the vectors come back exactly as the provider produced them. There is nothing in a vector to restore, so nothing is added to the request and the provider’s token count is entirely your own content.
Because tokens are deterministic, the same name or email becomes the same token in every document and every query. A search for a customer’s record finds every document that mentions them, because the name works as a consistent keyword. What changes is only that the provider never held it.
- Available for keys registered with OpenAI, Mistral, Together, Fireworks and Gemini, whose APIs serve an embeddings endpoint.
- Tokens carry nothing of the value they replace, so similarity between two tokenized names says nothing about how alike the names are. Match and deduplicate names on your side before they reach the proxy; use NoPII embeddings for search over documents that mention people.
Before: the document you index
Case notes for John Smith, john@example.com. Follow-up scheduled.
After: what the embeddings API receives
Case notes for [PERSON: aBcDeFgH12], [EMAIL: bN3dF5h]. Follow-up scheduled.
Same vectors, same similarity search, same hits for the same person. The provider never saw the name.
PII and API-key detection.
NoPII also neutralizes the labels that tell the model what kind of data it is looking at.
Without this, models recognize tokenized data as sensitive and trigger safety refusals, breaking the user experience and pushing teams to bypass privacy controls entirely.
Without neutralization
The model still reads the category labels.
social security number
credit card number
date of birth
bank account
passport number
The model recognizes sensitive data categories and refuses to process the request.
With NoPII
With NoPII
Categories become neutral, harmless labels.
social security number→ID number
credit card number→account number
date of birth→date
bank account number→account number
passport number→document number
Neutral labels let the model process the request without safety refusals.
Why teams route their AI through it.
01
Fastest time to protected
No SDK to adopt, no middleware project, no re-architecture. Signup to protected production traffic in minutes, on the free tier, without talking to us.
02
Protection that preserves intelligence
Deterministic tokens keep reasoning intact across related data and across conversation turns. The feature you shipped still works.
03
Built on certified custody
Tokens map to values held in the Enigma Vault, which is PCI DSS Level 1 and SOC 2 Type II, under per-customer keys. The two-line integration stands on enterprise-grade ground.
The questions an engineer asks next.
Streaming and multi-turn token restoration
SSE responses detokenize in flight, so real-time chat keeps streaming. Deterministic tokens keep multi-turn conversations coherent: the same person is the same token across every turn of the session.
Why tokens, not redaction
NoPII restores its own tokens on the way back, so your application receives real values in the response. Placeholder redaction destroys the entity relationships a model needs to reason. Tokens preserve structure in both directions, which is the only approach that protects data without breaking the model.
Agents, tool calls and the Responses API
NoPII scans every text field a model can read or write: user and assistant messages, the system prompt, function call arguments and the tool results you feed back. The OpenAI Responses API is served alongside Chat Completions, and Anthropic tool use and tool results are sanitized in the Messages endpoint. Streamed tool call arguments are held until the call completes and released as one piece, so a token split across chunks never breaks the JSON your agent is parsing.
- messages
- system prompt
- tool call arguments
- tool results
Tracing without exposure Growth and above
With Langfuse enabled, every proxied request produces a trace with three spans: sanitize, the LLM call, and desanitize. The LLM call is recorded as a generation with model, token usage and status, so Langfuse’s cost tracking works. Both the logged input and the logged output are the tokenized versions; the output is captured before detokenization specifically so plaintext never reaches your traces. Send a W3C traceparent header and the NoPII trace appears as a child of your own span, so one view runs from your application through NoPII to the model. Tracing never blocks a request; if Langfuse is unreachable, the proxy carries on.
your traceparent
nopii-proxy root
sanitize → llm-call generation → desanitize
Input logged: tokens. Output logged: tokens. Plaintext logged: none.
The same AI feature, two realities.
Without NoPII
Sensitive data rides the prompt, and redaction breaks the model.
Customer data accumulates in model provider logs
Redaction breaks the model's reasoning
Compliance approval rests on provider promises
A detection failure leaks silently
Erasure means chasing third-party retention
With NoPII
With NoPII
Tokens ride the prompt, and your app gets real data back.
Providers receive tokens that reference nothing
Deterministic tokens preserve it in both directions
Compliance approval rests on your own architecture
A detection failure blocks loudly
Erasure resolves at the vault level
Why not build it yourself?
Teams that build this in-house end up assembling and maintaining a stitched stack: a detection library, a token vault, a proxy layer, an admin console, and audit logging. Each piece works. The seams are where data leaks. And the stack is never finished: new providers, new streaming formats, new entity types, and new compliance questions arrive faster than a side project can absorb them.
NoPII replaces the entire build with one base URL swap, maintained as a product instead of a backlog item.
Detection library
Token vault
Proxy layer
Admin console
Audit logging
● Each piece works. The seams are where data leaks.
The architecture, in writing.
What a security review will ask about, answered in one sheet.
01
Infrastructure
Built on the Enigma Vault, which is PCI DSS Level 1 and SOC 2 Type II.
02
Encryption
AES-256 at the field level on vaulted data.
03
Key management
Per-customer AES-256 keys in a managed secrets store, rolled over after a specified time. No key is shared between customers.
04
Authentication
OAuth2 machine-to-machine, client credentials.
05
Audit
Request-level logging, reviewable in the admin console. BAA available.
06
Credentials
Your LLM provider key is read from the request, used to identify your account and provider, and forwarded. NoPII stores only a hash of its own keys and never stores yours.
07
Deployment
NoPII Cloud, or a self-hosted edition for Enterprise under an annual license with no token meter.
Research
See the results of 109 automated tests on the NoPII engine.
Deterministic PII Tokenization for LLM API Traffic: Test Suite Results and Empirical Analysis of the NOπI Redaction Engine
Read the whole page, or just change the base URL and watch the logs.
NOPII · USE CASES
Where LLM data privacy becomes business-critical.
PII protection for workflows already in production, where sensitive data is already reaching model providers. For sector context, see AI data security by industry, and NoPII pricing for what each plan covers. Find yours below, and trace exactly where it leaks.
TRACE 01
Healthcare and life sciences: the deepest exposure in the market.
Clinical AI is not coming; it is deployed. Ambient documentation tools sit in thousands of exam rooms. Chart abstraction runs across records for real-world evidence. Coding automation reads encounters to bill them. Prior authorization platforms process millions of requests a year.
Where the PII actually leaks
Trace one ambient documentation session end to end. The clinician greets the patient by name, and the transcript captures it. The patient recites their date of birth for verification, mentions their address changed, describes their diagnosis history. All of it lands in the transcript, the transcript becomes the prompt, and the prompt lands in a model provider's infrastructure, under their logs, their retention, their jurisdiction. Multiply by every visit, every day. The same trace runs through chart abstraction, where the record itself is the input; through coding, where the encounter note carries the MRN; and through prior auth, where patient notes, documentation, and orders travel together. None of these leaks is a bug. Each one is the workflow operating as designed, which is exactly why nobody has mapped it.
That unmapped flow is the regulatory exposure. Enforcement in this space keeps tracing back to one finding: a defective risk analysis, meaning the organization could not say where its protected data went. A BAA with your model provider does not close the gap, because a BAA is a liability contract, not a control: it decides who pays after the data has moved, and it has never been the mitigating factor in a settlement. Regulators also pursue software vendors directly, not just the health systems using them.
Where NoPII sits
In front of every one of these workflows, tokenizing patient identifiers before the prompt reaches the model provider. The scribe drafts a perfect note on consistent tokens. The abstraction pipeline reasons over de-identified structure. The coding engine reads the encounter without reading the patient. Real values restored on the response path, every detection logged, BAA available, and a defensible sentence for your risk analysis: the model provider never held an identifier.
Point it at first
Ambient documentation
Adverse event narratives
Chart abstraction
Coding and revenue cycle
Prior authorization
See your own PHI exposure this week. Route one workflow through the free tier and read the detection log. The first million protected tokens cost nothing, and the log is usually the whole argument.
TRACE 02
Pharmacovigilance and clinical operations: mandated work, regulated data.
Safety teams do not choose whether to process adverse event reports; the obligation is regulatory, and AI-assisted intake and triage is now standard practice.
Where the PII actually leaks
An adverse event case arrives as a narrative: the patient's name, age, medications, dosing history, and outcome, written as prose, because that is what a case narrative is. AI triage means that narrative becomes a prompt, verbatim. Trial operations leak the same way: pre-screening runs patient EHR data through eligibility logic, monitoring agents read patient records and lab results, and submission drafting is built on clinical study data. For US sponsors running EU trials, the European layer sharpens it: regulators have said plainly that a trained model cannot be assumed anonymous, and unlawful processing upstream can taint everything downstream. The only control that holds is removing identifiers before the data reaches the model provider.
Where NoPII sits
Between your PV and clinical systems and every model call, with deterministic tokens keeping each case narrative internally coherent so causality assessment still works, and an exportable per-transaction audit trail for inspection readiness.
Bring your inspection-readiness question to a working session. Thirty minutes, your workflow, your regulators.
TRACE 03
Legal: privilege, and the files that contain everything.
The heaviest AI adoption in law sits exactly where the data is worst, and the volume center is mass tort and personal injury, where platforms process tens of thousands of cases a week across the market.
Where the PII actually leaks
Open one claimant file: name, date of birth, SSN, address, complete medical history, employment records, financial details, lien data, sometimes a minor's records. AI-drafted chronologies and demand letters mean that entire file becomes prompt material, page after page. Document review leaks differently: it sweeps whole custodian corpora, entire mailboxes and HR folders, so the PII sent to the model is not curated, it is whatever happens to exist. Privilege review sends the most protected material a firm holds, by definition. Deposition summarization sends verbatim testimony, where witnesses volunteer medical history and family details no redaction policy ever anticipated. Client intake leaks earliest of all, often before an engagement letter exists. Meanwhile bar ethics opinions require confidentiality analysis before client data touches a generative tool, and court standing orders govern AI use directly, so "we did not know where the data went" is no longer an available answer.
Where NoPII sits
In front of the chronology, drafting, review, and summarization tools your teams already use. Client names, parties, matter identifiers, and medical details are tokenized before any prompt leaves the firm; the work product comes back with real values restored; privilege never transits a provider's logs. Deterministic tokens keep a thousand-page chronology coherent, because the same claimant is the same token on page one and page nine hundred. The same tokens flow through your embeddings pipeline, so document review indexes and claims search hold tokens, not names.
Point it at first
Claimant intake and medical chronologies
Demand drafting
Document and privilege review
Deposition summaries
Immigration filings
Give your ethics analysis its missing artifact. The per-request detection log answers the confidentiality question in writing. Request a demo or start free on a single matter type.
TRACE 04
Financial services: identifiers in every prompt, regulators at the door.
Where the PII actually leaks
A support agent opens the copilot and pastes the case: customer name, full account number, recent transactions, the complaint. That paste is the leak, and it happens hundreds of times a day per team. Fraud narratives leak by design, because the narrative is the transaction history with a name attached. Compliance review leaks in bulk, because the documents under review are dense with customer identifiers. And one leak nobody budgets for: engineers and analysts paste connection strings, API keys, and credentials into internal copilots daily. All of it moves under GLBA, SOX, PCI DSS, and state privacy law simultaneously.
Where NoPII sits
Tokenizing financial identifiers in transit while deterministic tokens preserve analytical structure: the same account is the same token across a multi-step fraud narrative, so the reasoning holds while the identifiers never reach the model provider. Secret and API key detection runs in the same pass across fourteen credential pattern families, on by default.
Run one week of copilot traffic through the free tier. The detection dashboard tells you what has been leaving the building.
TRACE 05
Insurance: the densest files anyone sends to a model.
Where the PII actually leaks
An adjuster drops a claims file into the summarization tool. That single PDF holds medical records, financial details, an identity document, and payment data, four regulated categories, one prompt. Triage and correspondence drafting repeat the same transfer across the whole book of claims, and underwriting and fraud workflows carry the identical shape. No other industry concentrates this much regulated data into one routine AI action.
Where NoPII sits
One control point in front of claims, underwriting, and service AI, tokenizing across every category simultaneously, so the model summarizes the claim while the provider holds nothing real. Erasure resolves at the vault, not across a provider's retention policy, and every detection is logged for the market-conduct exam. The same tokens flow through your embeddings pipeline, so document review indexes and claims search hold tokens, not names.
See what one claims file actually contains. Run a redacted sample through the live playground and watch the detections light up.
TRACE 06
Customer support: volume, streaming, and erasure rights.
Where the PII actually leaks
Support AI runs at conversation speed. The customer types their name, order number, address, and card's last digits into chat; the ticket history carries every previous interaction; summarization, drafting, and routing each re-send the thread to the model, streaming, in real time. The exposure compounds with volume, and once customer data is distributed across provider logs, GDPR and CCPA erasure requests become promises you cannot keep.
Where NoPII sits
In the streaming path, tokenizing in real time with SSE support so the chat experience is unchanged, and resolving right-to-erasure at the vault level with token purge: delete every token for a list of values in one request.
Protect your first million support tokens free. Two lines of code, live before the next shift starts.
TRACE 07
HR and people operations: the data your own employees would object to.
Where the PII actually leaks
A recruiter pastes a resume into the assistant: name, address, work history, sometimes visa status. Feedback summarization reads performance reviews with names attached. People analytics reads compensation by employee. Every one of these is employee and candidate data leaving for a third-party model, with employment law exposure in every jurisdiction you operate, and it is exactly the data internal AI pilots reach for first, usually before legal has seen the tool.
Where NoPII sits
Tokenizing employee identifiers, salaries, and personal details before people workflows touch a model, preserving the analytical value while giving legal the control layer they need to approve the program at all.
Get the people-AI pilot approved. Bring legal to a demo; the audit trail does the convincing.
TRACE 08
Software teams everywhere: the secrets nobody meant to send.
Where the PII actually leaks
An engineer pastes a failing config into the AI assistant, and the config contains the database connection string. A stack trace carries a bearer token. A debugging session includes a cloud key. None of it was meant to leave; all of it did. This exposure crosses every vertical, because it is not a workflow, it is a habit.
Where NoPII sits
Fourteen credential pattern families detected in the same pass as PII, on every request including streaming, replaced with vault tokens, restored in the response, logged on every catch. On by default, because the first week of logs is usually the argument. The same coverage extends to agents: function call arguments and tool results pass through detection, so an agent that reads a ticket and calls a CRM never ships the customer’s identifiers to the model.
Turn it on and read Friday's log.
Different industries. Same blocker.
The pattern is remarkably consistent. Teams want AI, the workflows are obvious, and the value is real. The hesitation starts when sensitive data enters the picture. NoPII exists to remove that hesitation without wrecking usability: it is not just a privacy layer, it is an AI adoption layer. Sensitive data is detected, tokenized, logged, and handled through a controlled layer, which makes AI projects easier to approve, easier to explain, and much easier to move forward.
What the audit trail actually looks like.
Every detection is logged with entity type, confidence score, session ID, provider, model, and timestamp. Searchable, filterable, exportable. An entry never holds the plaintext. It holds the token and a masked form, such as the first character of a name or the last four digits of a number. When a token is purged for an erasure request, the entry is kept and stamped with who purged it and when, and the token can no longer be resolved to anything.
{
"timestamp": "2026-03-24T09:14:03Z",
"session_id": "sess_7f2a9c",
"provider": "openai",
"model": "gpt-4o",
"entities": [
{ "type": "PERSON", "score": 0.98, "token": "[PERSON: aBcDeFgH12]", "masked": "J*** S****" },
{ "type": "US_SSN", "score": 1.00, "token": "[US_SSN: iJkLmNoPqR]", "masked": "***-**-6789" }
],
"tokens_issued": 2,
"action": "TOKENIZED_AND_FORWARDED",
"purged_at": null,
"purged_by": null
}
No plaintext field exists in the schema. Retention runs 7 days on Lite, 30 on Starter, 90 on Growth, 365 on Business and unlimited on Enterprise, with CSV export from Growth.
If sensitive data appears in the workflow, the privacy layer cannot be optional.
That does not mean adoption has to become painful. Two lines of code, live in minutes, first million tokens free every month.
Your questions about NoPII, answered.
Privacy and tokenization
What is NoPII?
NoPII is a PII-tokenizing reverse proxy for LLM APIs, built by Enigma Vault. It sits between your application and model providers, detects sensitive data across 30+ configurable entity types, tokenizes it before it reaches the model provider, and detokenizes responses on the way back. Your application works with real data; the provider only ever sees tokens.
How is tokenization different from redaction or masking?
NoPII restores its own tokens in the response, so your application receives real values back. Placeholder redaction replaces sensitive values with text that destroys the relationships a model needs to reason. NoPII tokenizes deterministically: the same value always maps to the same token, so reasoning stays intact, and round-trip detokenization returns real data to your application. Tokens preserve structure in both directions; redaction preserves it in neither.
What happens if detection or tokenization fails?
The request is blocked, not forwarded. NoPII is fail-safe by default: sensitive data never proceeds on a best-effort basis. The block is logged so your team sees it immediately. This is architecture, not a configurable setting.
Does it catch API keys and secrets, not just personal data?
Yes. Fourteen credential pattern families are detected in the same pass as PII: cloud provider keys, model API keys, payment and code-platform tokens, database connection strings, private keys, and auth tokens. Detected secrets are replaced with vault tokens, restored in the response, and logged in the audit trail. It is on by default for new accounts.
How accurate is detection?
Detection covers 30+ configurable entity types and is validated in a published 109-test report. Detection sensitivity is adjustable, and custom phrase rules are available on paid plans.
Does NoPII support HIPAA and GDPR workloads?
Yes. It is built for HIPAA, GDPR, CCPA, and PCI DSS requirements, with BAA availability for healthcare deployments and request-level audit logs for every transaction. Right-to-erasure resolves at the vault level, because identifiers never reach provider logs in the first place, and token purge deletes every token for a list of values in one request.
Does NoPII protect consumer chatbot websites?
No. NoPII protects application traffic that is routed through its proxy. If your application calls an LLM API through the NoPII base URL, every request and response on that path is covered. Traffic that never passes through the proxy, such as an employee pasting data into a consumer chatbot website in their browser, is outside its scope.
Does NoPII only protect the model provider, or my servers too?
Both, depending on tier. The proxy keeps plaintext away from the provider. The browser SDK, in preview, tokenizes in the user’s browser so your backend and logs hold only tokens and the reply is revealed only to the user it belongs to.
Does NoPII detect identifiers outside the US?
Yes. Beyond the global types, it covers India (Aadhaar, PAN, voter ID, vehicle registration, Hindi names and addresses), the UK (National Insurance, NHS), Spain, Italy, Poland, Finland, Australia and Singapore. Regional types are off by default and switched on per workspace. Several are in beta.
Does NoPII scan images, audio or files?
No. NoPII scans text: messages, system prompts, tool call arguments and tool results. Images, audio, files and documents are not scanned, so extract the text from a document before it goes to the model if it needs protecting.
Providers and integration
How long does integration take?
Two lines of code. Point your existing SDK at the NoPII base URL,
https://api.nopii.co. No new SDK, no middleware, no application logic changes. Most teams go from signup to protected traffic in under five minutes.Which model providers does it support?
OpenAI, Anthropic, Google Gemini, xAI, DeepSeek, Mistral, Groq, Together, and Fireworks, all under one proxy. It also works with LangChain, LangGraph, LlamaIndex, LiteLLM, and the Vercel AI SDK, with Langfuse tracing available. Switching providers does not reset your privacy controls.
Does it work with streaming responses?
Yes. SSE responses detokenize in flight, so real-time chat keeps streaming while detection and restoration run in the path.
Does it stay coherent across a multi-turn conversation?
Yes. Because tokenization is deterministic, the same entity carries the same token across every turn of a session, so the model's context and reasoning hold across the whole conversation.
Why not build this in-house?
Building it yourself means assembling and maintaining a stitched stack: a detection library, a token vault, a proxy layer, an admin console, and audit logging. Each piece works; the seams are where data leaks. And the stack is never finished, because new providers, streaming formats, entity types, and compliance questions keep arriving. NoPII is that entire build, maintained as a product.
Does NoPII work with embeddings and RAG?
Yes. The embeddings endpoint tokenizes every text before it reaches the provider, vectors return unchanged, and deterministic tokens keep similarity search working for documents that mention the same person. Available on providers that serve an embeddings API: OpenAI, Mistral, Together, Fireworks and Gemini.
Can NoPII run inside our own environment?
Yes. Enterprise can run the self-hosted edition under an annual license with no token meter. Every other plan runs on NoPII Cloud.
Can different teams share one NoPII account?
Yes. Growth and above support multiple workspaces, each with its own keys, settings and audit log, under one organization and one bill, with Owner, Admin and Member roles. Business adds unlimited seats and SSO enforcement.
Retention and pricing
What is the security and certification posture?
NoPII is built on the Enigma Vault, which is PCI DSS Level 1 and SOC 2 Type II. Tokenized values are stored in the Vault with AES-256 encryption and per-customer keys.
What does it cost to try?
Nothing. The free tier covers one million protected tokens per month with no credit card, indefinitely.