Security

Security & Data Handling

Last updated: 2026-06-07

Privian is in beta. This page describes our current practices and policies in plain language. Material updates will be noted here and on /updates.

Privian is designed to mask configured sensitive data before requests reach model providers. This page is the plain-language summary of what Privian does with your credentials, your prompt traffic, and the data we keep for observability. It complements /resources/security, /resources/architecture and the Privacy Policy.

1. Gateway API keys

  • When you create a Privian API key, the plaintext is shown to you only once, at creation time. It is not recoverable from Privian afterwards.
  • Privian stores the key as a SHA-256 hash. The plaintext is not stored.
  • We display the last four characters and the label you assigned, so you can identify which key is which in your settings.
  • You can revoke a key at any time from settings. Revoked keys stop authenticating immediately on subsequent requests.

2. BYOK provider credentials

  • Provider credentials (for example OpenAI, Anthropic, Google, DeepSeek) are encrypted at rest with AES-256-GCM. The plaintext is discarded immediately after encryption.
  • Decryption happens server-side, on the gateway hot path, only when a credential is needed to perform an outbound request. The plaintext is held in process memory for the duration of that request and is not written to disk.
  • Credentials are injected per request into the outbound provider call. They are not stored in LiteLLM configuration files or in any long-lived process state outside the encrypted database row.
  • Client-visible credential metadata is limited to last four characters and a non-reversible HMAC fingerprint for identification. Ciphertext, IV and master keys never leave the server.

3. Prompt handling

Privian's purpose is to reduce sensitive data exposure in prompts. That necessarily means Privian transiently processes prompts in order to mask them — we do not claim that prompts are never processed. We do design the system so that prompts and responses are not retained.

  • Each request is inspected in-memory. Supported sensitive values are detected deterministically and replaced with placeholders such as PERSON_1, EMAIL_1 before any outbound provider call.
  • Masking is performed in-process by Privian using deterministic detectors. There is no external masking-LLM fallback that sees your raw prompt for detection purposes.
  • The masked prompt is forwarded to the BYOK provider you selected, using your provider credentials. The provider receives only the masked prompt.
  • On the response, Privian rehydrates placeholders in-memory before returning to your application, according to your entity policy. PII placeholders may be rehydrated; values classified as secrets are not rehydrated by default.
  • The per-request placeholder → value map lives only in memory and is discarded once the response is returned. Raw prompts and raw responses are not persisted by Privian.

4. LiteLLM

Privian uses LiteLLM as an execution-only component for outbound provider HTTP calls.

  • LiteLLM does not authenticate customers — customer auth is performed by the Privian gateway.
  • LiteLLM does not handle billing or entitlements — those are enforced by Privian before the call.
  • LiteLLM does not store customer credentials — credentials are injected per request and discarded after the response.
  • The LiteLLM component is reachable only from within Privian's deployment boundary and is not exposed to the public internet as a customer endpoint.

5. Model providers

  • Outbound provider calls are made using credentials you supplied. Privian does not sell or resell model access.
  • Your provider usage is billed by the provider directly under your account with them. Privian fees cover the gateway and security layer only.
  • Provider behavior — retention, training opt-out, region routing — is governed by your relationship with the provider, not by Privian.

6. Observability

  • Privian stores sanitized usage events: model, route, status code, latency, token counts where reported by the provider, and counts of masked entities by class. These are used for billing, quotas, abuse detection, error budgets and product analytics.
  • Prompt and response bodies are not stored intentionally. The observability pipeline is sanitized before persistence and does not accept payload content.
  • Operational logs include only sanitized fields necessary for incident response and are subject to standard log rotation.

7. What this page is not

This page describes the technical data path. It is not a certification statement. Privian does not currently claim SOC 2, HIPAA or PCI compliance. For an explicit list of what is in scope and out of scope today, see /resources/security.

8. Reporting a security issue

Please report suspected vulnerabilities or security issues to support@privian.io. Include steps to reproduce and any relevant request identifiers. We do not operate a paid bug bounty during beta but acknowledge reports and will work with you in good faith.