Where should the masking layer sit relative to retrieval?

After retrieval, before the provider call. Your copilot fetches the documents it needs, then forwards the prompt through the gateway, which masks recognized entities before they leave your perimeter.

How do I stop the copilot from leaking another team's data?

Authorization belongs in your application — only fetch the documents the requesting user is allowed to see. Masking complements this by preventing the data you do fetch from being exposed to the provider.

What about employee identifiers like email addresses?

Privian's detector covers EMAIL alongside customer PII. Employee identifiers are masked into placeholders like EMAIL_1 before the provider sees them.

How to build secure internal copilots

The shape of an internal copilot

Most internal copilots follow the same outline: an employee asks a question, the application retrieves relevant context (tickets, wiki pages, CRM records), and an LLM produces an answer. The risk surface is in the middle step — the retrieved context is usually rich in personal data.

A reference architecture

Employee
  │  "Summarize the open issues for ACME Corp"
  ▼
Copilot service (yours)
  ├── authorize the user
  ├── fetch documents the user is allowed to see
  ├── build the prompt
  ▼
Privian gateway
  ├── mask PII (customer names, emails, IDs)
  ├── forward to the model provider
  ├── rehydrate the response
  ▼
Copilot service
  │  return the rehydrated answer
  ▼
Employee

What each layer is responsible for

Authorization. Your service. The gateway does not know who your users are; you do.
Retrieval. Your service. Fetch the smallest set of documents that can answer the question.
Masking. The gateway. Detect and substitute PII before the prompt leaves your perimeter.
Routing. The gateway. Map the model ID to the right provider and credential.
Rehydration. The gateway. Restore real values in the response before returning it.
Audit. Both. The gateway records request metadata; your service records who asked what.

Common mistakes

Wrapping the whole CRM record. Pull only the fields the question needs.
Letting the copilot call the provider directly. Now you have a second prompt path with no policy.
Logging the rehydrated answer. If you store it, you have re-introduced the risk you just removed.

A minimal working call

curl https://api.privian.io/v1/gateway \
  -H "Authorization: Bearer $PRIVIAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-4.5",
    "prompt": "Summarize the open issues from these tickets...",
    "stream": false
  }'

What this does not solve

This architecture reduces what the model provider sees. It does not stop a buggy frontend from rendering the wrong answer to the wrong user, and it does not defend against prompt injection from untrusted content. Address those separately.

How Privian fits

Privian's gateway is the masking and routing layer in this architecture. See Internal Copilots for the worked example and the guide for the step-by-step.

Frequently asked questions

Where should the masking layer sit relative to retrieval?: After retrieval, before the provider call. Your copilot fetches the documents it needs, then forwards the prompt through the gateway, which masks recognized entities before they leave your perimeter.
How do I stop the copilot from leaking another team's data?: Authorization belongs in your application — only fetch the documents the requesting user is allowed to see. Masking complements this by preventing the data you do fetch from being exposed to the provider.
What about employee identifiers like email addresses?: Privian's detector covers EMAIL alongside customer PII. Employee identifiers are masked into placeholders like EMAIL_1 before the provider sees them.