RHETRA / Guides / PII & LLMs

Stop PII leaking to LLMs

PII leaks to LLMs at the moment of the prompt: an employee pastes a customer record, a contract, a log file into a chat window, and the data is on someone else's infrastructure before any network control sees it. Policies don't stop this, and network DLP mostly can't. What works is moving detection to where the leak happens — on the device, before the prompt is sent, with a scanner that blocks when in doubt.

1 · Shadow AI: the actual threat model

Employees use AI because it works. Bans produce workarounds, not compliance: private phones, personal accounts, unmonitored browsers. The realistic threat model is therefore not "malicious insider" but helpful employee, wrong channel: customer PII in a translation prompt, source code with embedded API keys in a debugging request, financial figures in a "summarise this" paste.

What makes this worse than classic shadow IT: the pasted data doesn't sit in an unapproved app you can later audit — it enters a third-party model where retention, logging and training use depend on the provider's terms, tier and configuration at that moment.

2 · Why the classic controls miss it

• Policy documents govern intentions, not keystrokes. Nobody re-reads the AI usage policy before pasting.
• Network DLP faces TLS-encrypted traffic; inspecting it means breaking encryption at scale, and even then free-form prompts defeat rigid pattern rules — too many false positives to keep it strict, too many misses to trust it.
• Provider-side controls (enterprise agreements, zero-retention tiers) matter, but they only cover the sanctioned channel. Shadow AI is by definition the unsanctioned one.
• Timing: every control that acts after the prompt left the device is forensics, not prevention.

3 · On-device detection: the architecture that works

The only point where prevention is still possible is the device itself, between typing and sending. That implies a specific architecture:

• Local scanning: the detector runs in the browser or endpoint and inspects the prompt before submission — credit cards, IBANs, national IDs, API keys, names, addresses.
• Zero egress by design: the scanner itself must not phone home. A PII scanner that uploads text for classification is a second leak, not a control. Detection stays on the device; nothing is transmitted to the vendor — RHETRA's Shield is built exactly this way.
• Mask, don't just alert: replacing the detected value (⟨IBAN⟩, ⟨CARD⟩) keeps the employee productive — the prompt still works, the data stays home. Alert-only tools train users to click through.

4 · Fail-safe vs fail-open — the deciding detail

Every scanner will eventually hit input it cannot process. The design question is what happens then. Fail-open treats scanner failure as "no PII found" and lets the prompt through — every bug becomes a silent leak. Fail-safe blocks when the scanner cannot deliver a verdict — every bug becomes a visible inconvenience. For personal data, the choice is not aesthetic: under GDPR you answer for the leak, not for the inconvenience. Ask any vendor this one question; the answer sorts the market.

5 · From one browser to the whole organisation

On-device shielding protects the endpoint. The organisational layer is an enforcement gateway in front of every sanctioned AI call: it classifies each request, applies BLOCK / SANITIZE / ALLOW centrally, routes sensitive workloads to local models, and signs every decision into an audit trail — which is also how EU AI Act logging duties get met as a side effect. The full architecture, including how to prove where your AI actually runs, is in the pillar guide: What is Sovereign AI?

You can test the endpoint layer right now: the OSI Shield Community Edition is free — install it, paste a test credit-card number into any chatbot, and watch it never arrive.