BYOK Security: Letting Enterprises Control Their AI Keys
TL;DR — BYOK (Bring Your Own Key) lets enterprises control their AI infrastructure by providing their own LLM API keys and encryption keys. For API keys: tenants pay their provider directly, eliminating platform markups. For encryption: tenants provide a KEK in their KMS, and the platform cannot decrypt their data without it. BYOK requires per-tenant key isolation (envelope encryption), encrypted key storage, and tenant-scoped key resolution. Crypto-shredding — revoking a tenant's KEK makes their data permanently unreadable. BYOK is increasingly expected by enterprise customers in regulated industries.
Enterprise customers want control over their AI infrastructure. They want to choose their LLM provider, control their encryption keys, and maintain visibility into their data flows. BYOK (Bring Your Own Key) is the architectural pattern that delivers this control.
BYOK has two dimensions in AI platforms:
1. BYOK for API keys: Tenants provide their own LLM provider credentials (OpenAI, Anthropic, Google). Token costs bill directly to the tenant's account.
2. BYOK for encryption: Tenants provide their own Key Encryption Key (KEK) through their KMS. The platform uses it to wrap the tenant's DEKs.
Both require per-tenant key isolation as the architectural foundation. This post covers the BYOK architecture, security requirements, and implementation patterns. For securing LLM API keys in multi-tenant environments, BYOK is the enterprise tier.
Why Enterprises Want BYOK
| Motivation | What it means | Without BYOK |
|---|---|---|
| Cost control | Tenants pay their provider directly | Platform adds markup on token costs |
| Provider flexibility | Tenants choose their LLM provider | Platform dictates which models are available |
| Key custody | Tenants hold their encryption keys | Platform holds all keys — a breach exposes all tenants |
| Data sovereignty | Tenants control where keys live | Keys in platform's KMS, possibly in another jurisdiction |
| Audit control | Tenants see all key usage in their KMS logs | Platform logs are the only audit trail |
| Revocation | Tenants can revoke access instantly | Platform must manually delete data |
Security teams need proof of key custody, direct visibility into data flows, and evidence that audit controls remain under enterprise control rather than relying on vendor promises (AugmentCode 2026).
BYOK for API Keys
When a tenant brings their own LLM API key, the platform uses that key for all LLM calls related to that tenant. Token costs bill to the tenant's provider account, not the platform's.
Security requirements for BYOK API keys
| Requirement | How it's implemented |
|---|---|
| Encrypted at rest | Fernet encryption or AES-256-GCM before database storage |
| Tenant-scoped resolution | Key resolved from authenticated tenant context, never from request body |
| No cross-tenant access | Workspace A cannot read Workspace B's keys |
| No key round-trip | API responses return only key prefix (first few chars) for identification |
| Scoped container lifetime | LLM client rebuilt per request — no key persistence in memory between tenants |
| Probe at write time | Validate key works before saving — fail fast on invalid keys |
BYOK API key isolation layers
| Layer | What it prevents |
|---|---|
| Database column encryption | Reading the database directly returns ciphertext, not plaintext keys |
| Tenant resolution from auth context | No workspace_id parameter injection — tenant from JWT or session |
| Scoped service container | Client rebuilt per HTTP request — no key leakage between tenants |
| Mutation surface control | Key update/clear endpoints resolve tenant from auth, not request body |
BYOK for Encryption
When a tenant brings their own encryption key (KEK), the platform uses it to wrap the tenant's DEKs. The platform cannot decrypt the tenant's data without the tenant's KEK.
| BYOK encryption aspect | How it works |
|---|---|
| Tenant provides KEK | Tenant creates KMS key in their cloud account (AWS, GCP, Azure) |
| Platform registers KEK | Platform stores the key ARN/URI with tenant configuration |
| Encryption uses tenant KEK | All DEKs for that tenant are wrapped with the tenant's KEK |
| Decryption requires tenant KEK | Platform calls tenant's KMS to unwrap DEKs |
| Revocation | Tenant disables key access → all tenant data becomes unreadable |
| Key rotation | Tenant rotates KMS key → platform uses new version automatically |
This is envelope encryption with the tenant's KMS as the KEK provider. The platform never sees the tenant's key material — it only calls the KMS API to wrap and unwrap DEKs.
Crypto-shredding
When a tenant leaves the platform, they revoke their KEK. All their wrapped DEKs become permanently unreadable. The platform cannot decrypt the data even if it wanted to — the key material is gone. This satisfies data deletion requirements without physically deleting every record.
BYOK Architecture: Platform-Managed vs Customer-Managed
| Feature | Platform-managed keys | Customer-managed (BYOK) |
|---|---|---|
| Key generation | Platform | Customer's KMS |
| Key storage | Platform Key Vault | Customer's Key Vault |
| Key rotation | Automatic (90 days) | Customer-triggered |
| Key revocation | Platform-controlled | Customer-controlled |
| Cost transparency | Platform sees all costs | Tenant sees their own costs |
| Availability | All plans | Enterprise plan |
| Compliance | Standard | Required for some regulated industries |
BYOK Implementation Patterns
Pattern 1: API key injection
The tenant provides their LLM provider API key through a settings interface. The platform encrypts and stores it, then uses it for all LLM calls related to that tenant.
| Step | Action |
|---|---|
| 1. Tenant submits key | Via admin portal or API |
| 2. Platform validates key | Probe call to provider — verify key works |
| 3. Platform encrypts key | Fernet or AES-256-GCM encryption at application layer |
| 4. Platform stores encrypted key | In tenant's configuration record |
| 5. At query time | Platform decrypts key, makes LLM call, discards plaintext from memory |
Pattern 2: Customer-managed encryption key (CMEK)
The tenant provides a KMS key ARN. The platform uses it as the KEK for envelope encryption of that tenant's data.
| Step | Action |
|---|---|
| 1. Tenant creates KMS key | In their AWS/GCP/Azure account |
| 2. Tenant grants platform access | IAM policy allowing platform's service role to use the key |
| 3. Platform registers key ARN | Stored with tenant configuration |
| 4. Encryption | Platform generates DEK, wraps with tenant's KMS key |
| 5. Decryption | Platform calls tenant's KMS to unwrap DEK |
Pattern 3: Secure enclave BYOK
For maximum security, the tenant's key is confined to a secure enclave. The platform's code runs inside the enclave and can access the key, but no one — not even the platform's engineers — can extract it.
| Aspect | How it works |
|---|---|
| Key confinement | Key accessible only inside attested secure enclave |
| Attestation | Key release tied to code hash — only trusted code can fetch the key |
| No key export | Key material never leaves the enclave boundary |
| Insider threat protection | Platform employees cannot access tenant keys |
BYOK and Compliance
| Regulation | How BYOK helps |
|---|---|
| GDPR Article 32 | Tenant controls encryption keys — security of processing |
| HIPAA | Tenant manages PHI encryption keys in their KMS |
| SOC 2 | Customer-controlled keys demonstrate access control |
| EU AI Act Article 9 | BYOK is a risk mitigation for data exposure |
| Data sovereignty | Keys stay in tenant's jurisdiction — data cannot be decrypted elsewhere |
FAQ
What is BYOK in AI platforms?
BYOK (Bring Your Own Key) in AI platforms means enterprises provide their own API keys for LLM providers (OpenAI, Anthropic, Google) and/or their own encryption keys for data at rest. This gives enterprises control over costs, provider choice, and cryptographic isolation.
What is the difference between BYOK for API keys and BYOK for encryption?
BYOK for API keys means the tenant provides their own LLM provider credentials — token costs bill to the tenant's account. BYOK for encryption means the tenant provides their own KEK in their KMS — the platform cannot decrypt tenant data without the tenant's key.
Is BYOK required for enterprise AI compliance?
BYOK is not legally required but is increasingly expected by enterprise customers. HIPAA, GDPR, and SOC 2 do not mandate BYOK, but enterprises in regulated industries often require it to maintain control over their encryption keys and demonstrate data sovereignty.
How does BYOK work with envelope encryption?
The tenant provides a KEK through their KMS. The platform generates DEKs to encrypt tenant data, wraps the DEKs with the tenant's KEK. If the tenant revokes access, their KEK is disabled and all wrapped DEKs become unreadable — crypto-shredding without deleting data.
Does BYOK reduce AI platform costs?
BYOK for API keys shifts LLM token costs from the platform to the tenant. The tenant pays their provider directly. This eliminates the platform's markup on token costs and gives tenants transparency into their actual AI usage spending.
Want a self-hosted AI company brain that does all of this out of the box?
Book a demo →