Most AI platforms store your API keys in a server-side vault. From a threat-model perspective, that vault is a single point of failure: one database breach, one compromised admin panel, or one malicious insider and every customer key leaks at once.
Bring Your Own Key (BYOK) inverts that model. Your key stays on your device, encrypted, and only ever leaves as a short-lived, single-use handoff envelope to authorize one request.
The threat model
We design against three concrete attackers:
- A database breach. There is no server-side keys table. Nothing to exfiltrate.
- A malicious insider. Operators can see requests, not secrets. Keys are unreadable server-side by construction.
- A compromised client. Local encryption raises the bar: a casual attacker with filesystem access gets ciphertext, not keys.
How the handoff works
The flow for a single request:
- Your key is encrypted locally with AES-256-GCM using a key derived from a passphrase or device secret.
- When a request needs the key, the client builds a handoff envelope: the decrypted key is re-encrypted to the server's ephemeral public key.
- The server decrypts the envelope in-memory, uses the key exactly once for the provider call, and discards it.
Envelopes expire in minutes and are single-use. Even a full network capture yields nothing reusable.
Stateless runtimes complete the story
The chat backend runs on Cloudflare Workers: stateless isolates with no filesystem. There is no persistent memory where a key could linger after a request finishes. Combined with client-side encryption, the infrastructure simply has no place where your key could live.
That is the property we mean when we say BYOK is a security architecture, not a billing model.