Procurement & security review

Privian Blueprint

A practical guide for evaluating how Privian handles prompts, provider credentials, retention, masking, and data flow.

Everything on this page is grounded in the current implementation. The PDF version mirrors this content for internal distribution.

Section 1

Executive summary

A one-page orientation: what Privian is, what it is not, and who it is for.

Privian helps you

  • Reduce prompt-level exposure of supported sensitive entity types.
  • Mask supported entities before prompts reach the model.
  • Route requests to your own provider account under BYOK.
  • Reduce the risk of accidental disclosure through model prompts.

Privian does not

  • Provide self-hosted inference.
  • Provide a governance or policy-management program.
  • Provide compliance certification (HIPAA, PCI, SOC 2, ISO).
  • Prevent prompt injection or jailbreak attacks.
  • Control downstream provider behavior, retention, or training policies.

Who it is for

Teams that already use a managed LLM provider, want to reduce prompt-level exposure of supported entity types, and prefer to keep their own provider account and billing relationship.

Who it is not for

Teams that require fully self-hosted inference, formal compliance attestations today, or a behavioral DLP product that prevents users from sharing information they intend to share.

Section 2

Clean data path

Supported entities are detected in-process and replaced with placeholders before any outbound provider call. The provider sees masked text only.

Privian data path: the application sends a raw prompt to the Privian Gateway, which detects supported entities, masks them to placeholders like PERSON_1 and EMAIL_1, and resolves the BYOK credential in memory. The masked prompt crosses the BYOK boundary to the LLM provider (OpenAI, Anthropic, Google), which only sees masked content. The raw model response returns to the gateway, which rehydrates placeholders to originals, emits a sanitized event with no bodies, and discards the entity map and decrypted key. Persisted: account, BYOK credential (AES-GCM at rest), hashed API keys, usage rollups, sanitized events. Not persisted: raw prompt body, rehydrated response body, entity map, decrypted provider key.
Supported sensitive values are masked before prompts reach the model and rehydrated after the response returns.
  • Masked prompt is what reaches the model.
  • Supported entities are stored in-memory only, per request.
  • Raw prompt bodies are not persisted.
  • Raw and rehydrated response bodies are not persisted.
  • BYOK is supported across OpenAI, Anthropic, Google (Gemini), and DeepSeek.

Section 3

What reaches the model

Which data classes cross the BYOK boundary to the LLM provider.

Data typeReaches the model?
Masked prompt textYes — this is the substrate the provider receives.
Placeholder tokens (e.g. PERSON_1, EMAIL_1)Yes — embedded inside the masked prompt.
Provider-side instructions (system, model, params)Yes — forwarded to the provider as supplied.
Raw values of supported sensitive entitiesNo — replaced with placeholders before the outbound call.
Decrypted BYOK provider credentialUsed to authenticate the outbound request; not sent as content.
Privian gateway API keyNo — terminates at the Privian gateway.
Internal gateway secrets, signing keysNo — never sent to providers.
Entity map (placeholder → original value)No — in-memory only; discarded after rehydration.

Section 4

Retention model

Persistence is intentionally narrow. Prompt and response bodies are not part of Privian's stored record.

Stored

ClassDetail
Account, billing, team metadataRequired to operate the service and bill correctly.
BYOK provider credentialsEncrypted at rest with AES-256-GCM; decrypted in-process per request.
Privian gateway API keysShown once at creation; stored as SHA-256 hash.
Usage rollupsToken counts, request counts, latency aggregates.
Sanitized observability eventsStatus, model, route, timing. No bodies.

Not stored

ClassDetail
Raw prompt bodiesDiscarded after the outbound provider call completes.
Rehydrated response bodiesReturned to the caller, not persisted.
Per-request entity mapLives in process memory; cleared after rehydration.
Decrypted provider credentialsHeld in memory for one request; never written to disk.

See /security/data-handling for the full reference.

Section 5

BYOK — bring your own provider key

BYOK is the default. You provide a credential for the provider you want to use; Privian authenticates the outbound call with that credential.

Credential ownership

Your provider credential belongs to your account at the provider. Revocation, rotation, and provider-side billing remain under your control.

Provider billing

Provider usage is billed by the provider to your provider account. Privian's invoice covers the gateway service only.

What Privian stores

  • Credential ciphertext, encrypted at rest with AES-256-GCM.
  • Last-4 digits and a label for identification in the dashboard.

What Privian does not store

  • Plaintext provider credentials.
  • Long-lived decrypted keys outside of a single request.

See /docs/concepts/byok for the implementation reference.

Section 6

Subprocessors

A small set of operational subprocessors run the service. The BYOK provider you select becomes part of your data flow under your own credential.

Privian uses operational subprocessors for hosting and managed database, payment processing, and transactional email. BYOK providers (OpenAI, Anthropic, Google, DeepSeek) are listed for transparency but are selected and authenticated by you.

The canonical, up-to-date list lives at /resources/subprocessors. Material changes are notified in accordance with the executed DPA where applicable.

Section 7

Security review questions

Concise, citation-friendly answers for procurement and security review.

What reaches the model?
The masked prompt. Supported entities are replaced with placeholders such as PERSON_1 or EMAIL_1 before any outbound provider call.
Who owns API keys?
You. Privian gateway API keys are shown once at creation and stored only as SHA-256 hashes. BYOK provider credentials are yours and are encrypted at rest with AES-256-GCM.
Do you train models?
No. Privian does not train models on customer prompts or responses. Detection uses deterministic in-process detectors.
What is retained?
Account, billing and team metadata; encrypted BYOK credentials; hashed gateway API keys; usage rollups; sanitized observability events that do not contain prompt or response bodies.
Can I self-host?
Not today. Privian is operated as a managed gateway. Self-hosted inference is out of scope.
Can I use OpenAI directly?
Yes. Provide your OpenAI key and the outbound call is authenticated with your credential. Provider billing and terms apply between you and OpenAI.
Can I use Anthropic directly?
Yes. The BYOK model is the same for Anthropic, Google (Gemini), and DeepSeek.
Does Privian support regional residency?
Region selection is not a contracted feature today. Provider-side region behavior is governed by your relationship with the provider.
Can Privian stop employees from pasting sensitive data?
Privian masks supported entity types before prompts reach the provider, reducing prompt-level exposure. It is not a behavioral DLP product and does not prevent a user from intentionally bypassing the gateway.
What does Privian actually protect?
The prompt path. Supported sensitive values are removed from outbound prompts and restored only in the response returned to your application.

Section 8

Limitations and trust boundaries

Privian's scope is intentionally narrow. Knowing what is out of scope is as important to a review as knowing what is in scope.

What Privian does not claim

  • No HIPAA, PCI, SOC 2, or ISO certification.
  • No guarantee of detection for entities outside the supported set.
  • No prevention of prompt injection or model jailbreaks.
  • No control over provider-side retention, logging, or training policy.

Customer responsibilities

  • Selecting which provider(s) to use and accepting their terms.
  • Managing rotation and revocation of BYOK credentials.
  • Governing how end-users interact with the application that calls Privian.
  • Determining whether masking coverage matches the data classes you handle.

Provider responsibilities

  • Processing the masked prompt under the provider's own terms.
  • Provider-side logging, retention, and training opt-outs.
  • Regional behavior and availability.
  • Billing and rate limits on the provider account.

Share it

Need to explain Privian internally?

Download the Privian Blueprint and send it to your security or procurement team before the call.