Unnecessary egress
Customer identifiers leave your perimeter every time an AI feature runs over a ticket.
Solution
Secure customer support AI without exposing customer data
Mask names, emails and account details before the LLM sees them.
Privian sits between your support tooling and the model provider. Customer identifiers are replaced with deterministic placeholders at the gateway and restored on the way back, so agents and end users see normal text — providers never do.
Problem
Support AI sees more than it should
Modern support workflows pipe ticket context — names, emails, phone numbers, billing references, sometimes whole conversation transcripts — directly into an LLM prompt. The model returns a summary or a draft reply, and the workflow moves on. The customer data, however, has now been forwarded to a third-party provider that has no operational reason to ever see it.
Why this matters
What's actually at risk
Vendor lock-in by data
The more provider-side context you accumulate, the harder it is to switch models.
Audit blind spots
Most support tools don't log what specifically was sent to which model on which ticket.
Accidental secret leakage
API keys and tokens pasted into tickets get forwarded along with the rest of the text.
How Privian fits
One masking hop, every support AI feature
Mask at the gateway
Customer identifiers are replaced with placeholders before any provider call.
Rehydrate on response
Agents and end users see real names; the provider never did.
Centralize the policy
Every support AI surface — summaries, drafts, copilots — flows through the same hop.
Provider-agnostic
Switch between OpenAI, Anthropic and others without changing your data-handling posture.
Architecture
Where Privian sits
Support app → Privian gateway → LLM provider
│ mask
│
(provider sees only placeholders)
│
▼
rehydrate ← provider response
│
▼
Support UI (agent / customer)Your support tool keeps its existing HTTP client. The only change is the base URL and the API key. The provider call still runs on your BYOK credentials, so model usage shows up on your account.
Example flow
Example request
curl https://api.privian.io/v1/gateway \
-H "Authorization: Bearer $PRIVIAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-5.5",
"prompt": "Draft a reply to Michael Olsen at michael@example.com about ticket #4821.",
"stream": false
}'Request shape is intentionally small: model, prompt, and an optional stream flag. See the API reference for the full contract.
Use cases
Where teams plug it in
AI ticket summaries
Summarize long threads without forwarding raw customer details.
Draft reply generation
Generate suggested responses with PII masked end-to-end.
Support copilots
Give agents an in-app assistant that never leaks customer context to the model.
Chat escalation handoff
Hand off chat transcripts to an LLM for triage with identifiers masked.
Implementation
Developer integration path
Step 1
Add a provider key
Add an OpenAI or Anthropic key in the Privian dashboard. Keys are encrypted at rest.
Step 2
Issue a gateway key
Generate a Privian API key (test or live) scoped to your environment.
Step 3
Point your client at the gateway
Set the base URL to https://api.privian.io and send prompt + model.
Step 4
Verify with a test ticket
Send a ticket containing a known identifier and confirm it is masked in transit.
Step 5
Roll out per feature
Migrate summaries, drafts and copilots one at a time. No prompt rewriting required.
Step 6
Observe
Use the dashboard to see request volume, model and entity counts — never raw content.
Transparency
Beta limitations
- No claim of HIPAA, SOC 2 or PCI compliance today
- No OpenAI SDK drop-in — Privian uses a small JSON contract
- No native provider token streaming yet (artificial chunking in beta)
- Detection is best-effort over the supported entity set
- Norwegian fødselsnummer not yet supported
- Does not block prompt injection or jailbreak attempts
FAQ
Frequently asked questions
- How can AI customer support avoid exposing customer data?
- Route every AI call through a gateway that masks sensitive values before egress. Privian replaces names, emails, phone numbers, payment identifiers and developer secrets with deterministic placeholders, so the model only sees structurally similar but de-identified text.
- Does the LLM provider see personal data?
- No. The provider receives the masked prompt with placeholders like PERSON_1 and EMAIL_1. The original values are only restored on the way back, in-memory inside the gateway, before the response is returned to your application.
- What sensitive values can Privian mask in support tickets?
- The current beta covers common personal identifiers (names, emails, phone numbers, IP addresses), financial and national IDs (credit cards, IBANs, US SSN, Canadian SIN) and developer secrets (JWTs, OpenAI keys, GitHub tokens, AWS keys, generic API keys, env-style secrets).
- Does Privian replace compliance programs?
- No. Privian reduces prompt-level exposure of supported sensitive values. It is not a substitute for HIPAA, SOC 2, PCI or any other compliance program, and we do not claim certification today.
- Will the model answer worse if it can't see real names?
- Placeholders are deterministic within a request, so the same value reuses the same token. The model can still reason about who refers to whom — it just never sees the underlying identifier.
- Does Privian store ticket content?
- No. Raw prompts and provider responses are never persisted. Only structural counters used for billing and observability are retained.
Learn more