Privacy-first LLM gateways, explained

Why "privacy-first" is a meaningful label

A lot of gateways do many things. A privacy-first gateway makes a specific commitment: data minimization is a property of the request path, not something you add later. That changes how the gateway is built, what it stores, and how it fails.

What to look for

• Masking on by default. If you have to opt in to mask PII, half of your traffic will silently bypass the control.
• No-body retention. Observability records metadata — model, status, latency, masked-entity counts — and skips the prompt and response bodies.
• In-memory mapping. The mapping between raw values and placeholders should live for the duration of a single request, not in a database.
• Encrypted provider credentials. If you bring your own provider key, the gateway should encrypt it at rest with a strong AEAD construction.
• Small attack surface. Fewer endpoints, fewer configuration knobs, clearer trust boundaries.

What "privacy-first" does not mean

It is not a compliance certification. Privian's beta does not claim HIPAA, SOC 2, or PCI compliance. Privacy-first describes engineering posture — what the system does and does not do — not a third-party attestation.

It also does not eliminate the provider relationship. A privacy-first gateway dramatically reduces what the provider sees; it does not remove the provider from the picture.

How Privian implements it

• Masking is the default behavior of every request to POST /v1/gateway.
• Request and response bodies are not persisted. Metadata about the request is. See Zero retention.
• The mapping between raw values and placeholders lives in memory for one request and is discarded after rehydration.
• BYOK provider keys are encrypted at rest with AES-GCM. See BYOK.
• Gateway API keys are stored as SHA-256 hashes, never as plaintext.

For the architectural detail, see Architecture.