BYOK and secrets: your keys never touch my server
Every user brings their own API keys. AES-256-GCM encryption in the browser, zero secrets in your database, and an audit of each use.
The server does not need to know everything
When your product consumes paid models, somebody pays the inference bill. Reselling the margin looks like business until the first surprise invoice or the first key leak. The BYOK model (bring your own keys) flips the relation: each user connects their own provider API keys, the ones they already pay for, and your server never sees the secret in the clear.
The exact flow
- The user pastes their key once in the dashboard.
- The browser generates a symmetric key, encrypts the API key with AES-256-GCM via WebCrypto, and sends only the ciphertext to the server for safekeeping.
- On each run, the server returns the ciphertext, the browser decrypts it in memory and signs the provider request from the client or through a proxy that never logs the secret.
- The plaintext key lives in no database, no log and no backup of yours. What was never stored cannot leak.
What you must never do
Store keys in plaintext localStorage, pass them as URL parameters, print them in error logs, or share one master key across all users. Each of these turns a minor breach into a major incident. The rule is binary: the plaintext secret exists only in its owner browser memory, and only during execution.
Audit and rotation
Every use of every key gets recorded (when, which model, how many tokens) so users see their consumption and catch anomalies. Rotation is one button: new key, new ciphertext, the old one ceases to exist. No migrations, no downtime.
Exercise
Draw where your system secrets live today as a three-box diagram (client, your server, provider) and mark in red every place a secret appears in the clear. Each red mark is one line of this chapter you still owe yourself.
Next lesson: how to know whether your prompt change improved anything or just moved it.