BYOK for privacy-sensitive AI

BYOK — bring your own key — is one of the recurring requirements in privacy and security reviews of AI products. This article explains what BYOK actually changes, why teams ask for it, and which problems it does and does not solve.

What BYOK means

In a BYOK setup the team keeps its own provider API keys with OpenAI, Anthropic, Google or other providers. The gateway uses those keys to call the provider on the team's behalf. The gateway operator never owns the provider relationship — they route, they do not resell.

The practical consequences:

• Billing stays with the team. Provider invoices go to the team's account, not to the gateway operator.
• Provider-side terms apply directly. Whatever retention, data-usage and regional terms the team negotiated remain in force.
• Rotation is in the team's hands. Keys can be rotated or revoked at the provider without involving the gateway operator.

Why enterprises ask about BYOK

BYOK shows up in security questionnaires for a few overlapping reasons:

• Trust boundaries. A gateway that proxies on its own key effectively becomes a sub-processor sitting between the team and the provider, with all the contractual implications that follow.
• Vendor risk. If the gateway operator goes away, the provider relationship and any committed spend with the provider survive.
• Compliance posture. Existing audits and contracts with the provider continue to apply without renegotiation.
• Cost predictability. Volume discounts and enterprise pricing already negotiated with the provider are preserved.

How BYOK works in Privian

A team adds a provider API key in the Privian dashboard. The key is encrypted at rest with AES-GCM and an organization-scoped key version. Only the last four characters and a key fingerprint are kept in plaintext for identification.

On a request, the gateway resolves the provider from the model namespace (e.g. openai/gpt-4o → OpenAI), decrypts the relevant credential, and calls the provider. The plaintext key never leaves the server and never reaches the caller. See the BYOK concept docs for the full lifecycle.

What BYOK does NOT solve

BYOK is one layer in a privacy and control stack. On its own, it does not:

• Prevent sensitive data from entering prompts. That is what prompt-level masking is for.
• Change what the provider does with the prompt. Provider-side retention is governed by the provider's terms for the account tier you use.
• Replace governance. Acceptable-use policy, access controls, training and incident response still apply.
• Defend against prompt injection or jailbreaks. BYOK has no opinion on the contents of a prompt.

BYOK plus prompt-level masking

The two are complementary. BYOK shapes the trust boundary; masking shapes the contents that cross it. Together they answer two different questions a security reviewer is likely to ask:

• Who has the provider relationship? — BYOK answers: the team does.
• What sensitive values are reaching the provider? — masking answers: only what the detector did not catch, plus anything the team intentionally chose to include.

Where to go next

Read the GDPR and LLMs pillar for the broader framing, or jump to the BYOK concept docs and authentication guide for implementation details.