Procurement & security review
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
A one-page orientation: what Privian is, what it is not, and 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.
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
Supported entities are detected in-process and replaced with placeholders before any outbound provider call. The provider sees masked text only.

Section 3
Which data classes cross the BYOK boundary to the LLM provider.
| Data type | Reaches the model? |
|---|---|
| Masked prompt text | Yes — 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 entities | No — replaced with placeholders before the outbound call. |
| Decrypted BYOK provider credential | Used to authenticate the outbound request; not sent as content. |
| Privian gateway API key | No — terminates at the Privian gateway. |
| Internal gateway secrets, signing keys | No — never sent to providers. |
| Entity map (placeholder → original value) | No — in-memory only; discarded after rehydration. |
Section 4
Persistence is intentionally narrow. Prompt and response bodies are not part of Privian's stored record.
| Class | Detail |
|---|---|
| Account, billing, team metadata | Required to operate the service and bill correctly. |
| BYOK provider credentials | Encrypted at rest with AES-256-GCM; decrypted in-process per request. |
| Privian gateway API keys | Shown once at creation; stored as SHA-256 hash. |
| Usage rollups | Token counts, request counts, latency aggregates. |
| Sanitized observability events | Status, model, route, timing. No bodies. |
| Class | Detail |
|---|---|
| Raw prompt bodies | Discarded after the outbound provider call completes. |
| Rehydrated response bodies | Returned to the caller, not persisted. |
| Per-request entity map | Lives in process memory; cleared after rehydration. |
| Decrypted provider credentials | Held in memory for one request; never written to disk. |
See /security/data-handling for the full reference.
Section 5
BYOK is the default. You provide a credential for the provider you want to use; Privian authenticates the outbound call with that credential.
Your provider credential belongs to your account at the provider. Revocation, rotation, and provider-side billing remain under your control.
Provider usage is billed by the provider to your provider account. Privian's invoice covers the gateway service only.
See /docs/concepts/byok for the implementation reference.
Section 6
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
Concise, citation-friendly answers for procurement and security review.
Section 8
Privian's scope is intentionally narrow. Knowing what is out of scope is as important to a review as knowing what is in scope.
Share it
Download the Privian Blueprint and send it to your security or procurement team before the call.