PII redaction before the prompt: how on-device detection works

Every PII redaction system has to answer one question first: where does the detection run? Get that wrong and the architecture is unfixable — a system that ships prompt text to a cloud service for scanning has already disclosed the data it was built to protect, just to a different party. This post walks through how on-device detection works in the browser, step by step, and why the order of operations matters more than any individual detector.

Order of operations: redact before send, not after

The moment a prompt is submitted, the data-protection question is settled. The text is on someone else’s servers, subject to their retention and training policies, and no amount of after-the-fact scanning changes that. So the pipeline has to run in the narrow window between composition and submission — while the text exists only in the browser’s memory, in an input field the user can still edit.

That window is real but small. A user pastes, glances at the input, and hits Enter within a second or two. Detection has to complete in tens of milliseconds to intervene without lag, which is a strong argument for doing the work locally: there is no round-trip in the budget.

The pipeline, step by step

1. Capture. A content script observes the prompt input on supported AI sites — the chat textarea on ChatGPT, Claude, Gemini, Copilot, Perplexity — reacting to paste events and typed input before submission.
2. Normalize. Sensitive data arrives mangled: card numbers with spaces or dashes, keys split across lines, homoglyph substitutions. Normalization collapses formatting so detectors see through it.
3. Detect. A battery of category-specific detectors scans the normalized text. This is pattern matching plus validation — patterns alone are far too noisy (see below).
4. Classify. Each finding is assigned a category — PII, secret, PHI, financial — because policy is per-category: a company may warn on PII but hard-block API keys.
5. Act. The configured action fires: warn (show the user what was found), redact (replace the sensitive spans with placeholders, leaving the rest of the prompt intact), or block the submission.
6. Log — without content. The event record is category, action, site, timestamp. The matched text itself never enters the log.

Why validators, not just regex

A regex for "16 digits" would flag every order ID and tracking number on the internet. Production detectors pair each pattern with a validator that exploits the structure of the data itself. Card numbers must pass a Luhn checksum, which eliminates the overwhelming majority of random digit strings. API keys are caught by their issuer prefixes — sk_live_ for Stripe, AKIA for AWS, ghp_ for GitHub — combined with a character-entropy check, since real keys are high-entropy by construction and prose is not. SSNs have structural rules (no 000 area group, no 9xx range) that filter out plausible-looking fakes.

For identifiers with no checksum — names, addresses, medical record numbers — context does the disambiguating: the tokens around a match ("patient", "DOB", "diagnosis") raise or lower confidence. Precision is the whole game here. A detector that cries wolf gets disabled within a week; one that misses a live Stripe key was never worth installing.

What redaction looks like

Note what redaction preserves: the actual question. The model can still help debug a 402 error without ever seeing the key or the cardholder. That is why redact-and-continue outperforms block as a default for most categories — the user gets their answer and the data stays home, so there is no incentive to work around the control.

BEFORE
  "Getting a 402 from our payments code. Key is
   sk_live_51Hx9mKLbQ2p7vN3eR8tY4wZ6 and the test
   customer is Maria Gonzalez, card 4242 4242 4242 4242."

AFTER (redact action, on-device)
  "Getting a 402 from our payments code. Key is
   [SECRET-REDACTED] and the test
   customer is [NAME-REDACTED], card [CARD-REDACTED]."

Audit log entry (content-free):
  { categories: ["secret", "pii", "financial"],
    action: "redacted", site: "chatgpt.com",
    time: "2026-05-27T14:02:11Z" }

On-device versus proxy: the privacy argument

The alternative architecture — routing prompts through a cloud gateway that scans them — has a structural flaw: it creates a new, centralized repository of every sensitive thing every employee almost sent to an AI tool. That repository needs its own security program, its own retention policy, and its own breach line in your risk register. It is also a latency tax on every prompt and a single point of failure for every AI workflow in the company.

On-device detection avoids the whole class of problem. The text is scanned where it already is, by code running in the user’s own browser, and the only thing that ever leaves is content-free metadata. This is the architecture ShieldWays uses: detection for PII, secrets, PHI, and financial data runs entirely in the browser, with warn, redact, and block actions applied before the prompt is sent.

Honest limitations

No detector catches everything. Free-text sensitivity with no structure — "our Q3 numbers are going to miss badly" — is not machine-recognizable as confidential, and organization-specific identifiers (internal project codenames, employee IDs) need custom rules rather than universal patterns. On-device detection raises the floor dramatically and catches the structured data that carries most of the regulatory risk; it does not replace judgment, and a vendor who claims otherwise is selling something.