What counts as sensitive in a prompt?

At minimum: direct identifiers (name, email, phone, address), account identifiers (customer IDs, IBANs, card numbers), and any developer secret. Internal hostnames, support ticket IDs, and free-text customer messages often qualify too.

Should I let the application decide, or enforce it at the gateway?

Enforce at the gateway. Application-level checks are useful as a first line, but the gateway is the only place where you can guarantee that every service is subject to the same policy.

What does Privian actually detect?

Privian's beta detects 15+ entity types including PERSON, EMAIL, PHONE_NUMBER, CREDIT_CARD, IBAN, and developer secrets like OPENAI_API_KEY and AWS_ACCESS_KEY_ID. Norwegian fødselsnummer and custom entities are planned but not yet supported.

How to prevent sensitive data in LLM prompts

Why this gets missed

Sensitive data ends up in prompts the same way it ends up in logs: nobody plans it, everyone does it by accident. A copilot wraps a full record. A debugging request includes a stack trace with a bearer token. A summarization endpoint takes whatever the customer pasted. By the time anyone looks at the data flow, it has already been sent.

A checklist that actually works

Minimize upstream. Only fetch the fields you intend to send. A prompt that needs the customer's question does not need their billing address.
Mask at the gateway. Treat detection and masking as a non-optional step between your service and any provider. If it can be bypassed, it will be bypassed.
Strip secrets, not just PII. API keys, JWTs, and OAuth tokens are sensitive too. A leaked key in a prompt is a rotation event.
Cap input size. Bound the maximum payload to stop accidental "dump the whole table" prompts. Privian enforces 32 KiB by default.
Never persist raw prompts. Record metadata — model, latency, masked-entity counts — and skip the body.
Rotate keys on incident. Treat any masking failure as a potential exposure event.

What detection covers

Privian's PII detector covers names, emails, phone numbers, addresses, dates of birth, credit cards (with Luhn validation), IBANs, SWIFT codes, IP addresses, URLs, and developer secrets including OPENAI_API_KEY, AWS_ACCESS_KEY_ID, generic JWTs, and Slack tokens. See the full list on the PII Masking page.

Norwegian fødselsnummer and arbitrary user-defined entities are not yet supported. Track progress on the Updates page.

What detection cannot do alone

No detector catches everything. Build defense in depth:

Limit which services can call the gateway in the first place
Cap retention on the application side too
Treat the gateway as one layer, not the whole answer

How Privian fits

Send your prompt to POST /v1/gateway. Privian masks recognized entities, forwards the masked text to the provider, and rehydrates the response. The raw values stay in memory for the request and are discarded afterwards. See First request for a working example.

Frequently asked questions

What counts as sensitive in a prompt?: At minimum: direct identifiers (name, email, phone, address), account identifiers (customer IDs, IBANs, card numbers), and any developer secret. Internal hostnames, support ticket IDs, and free-text customer messages often qualify too.
Should I let the application decide, or enforce it at the gateway?: Enforce at the gateway. Application-level checks are useful as a first line, but the gateway is the only place where you can guarantee that every service is subject to the same policy.
What does Privian actually detect?: Privian's beta detects 15+ entity types including PERSON, EMAIL, PHONE_NUMBER, CREDIT_CARD, IBAN, and developer secrets like OPENAI_API_KEY and AWS_ACCESS_KEY_ID. Norwegian fødselsnummer and custom entities are planned but not yet supported.