BYOK Done Right: Per-Workspace LLM Keys, Encrypted at Rest, Routed at Runtime

None of these are hypothetical. All of them have happened to vendors that shipped BYOK as a checkbox feature.

The fix isn't "encrypt the column." The fix is to treat the key like a payment credential — never in plaintext outside the smallest possible execution window, never in logs, never in the same memory space as user code.

How AACFlow Stores BYOK Keys

In AACFlow every workspace can attach its own keys for OpenAI, Anthropic, Google, Mistral, xAI, Groq, DeepSeek, Cerebras, Fireworks, and every other provider in the registry. The keys live in a dedicated table — workspaceBYOKKeys — with the following invariants:

• The keyCiphertext column is the only place the secret exists at rest. It is never the plaintext.
• A workspace-scoped Key Encryption Key (KEK) is derived from the platform ENCRYPTION_KEY plus the workspace ID using HKDF.
• The Data Encryption Key (DEK) is randomly generated per key and wrapped by the KEK. We store the wrapped DEK alongside the ciphertext.
• The encryption mode is AES-256-GCM. The IV is unique per row and authenticated against the workspace ID as additional data.

The schema looks roughly like this: (id, workspaceId, provider, keyPrefix, keyCiphertext, wrappedDek, iv, createdAt, rotatedAt, lastUsedAt). We store the keyPrefix — first 7 characters — so the UI can show sk-proj-A... without ever decrypting. We log lastUsedAt so workspaces can prove their key was actually used.

Decrypt Only Inside the Executor

The most important rule isn't about encryption — it's about scope.

In AACFlow the plaintext key exists in memory for exactly one moment: inside the executor process, inside the handler that is about to call the provider SDK, for the duration of that single call. The decryption happens at the boundary, the buffer is zeroed when the handler returns, and nothing else in the pipeline ever sees it.

That means:

• The Next.js app server never holds plaintext keys. It can fetch ciphertext rows but cannot decrypt them — it doesn't run with the decrypt grant.
• The Socket.IO realtime server never sees keys. It runs on a separate node with no encryption material.
• The BullMQ worker that schedules workflow runs sees only the workflow definition. It does not unwrap keys.
• The Trigger.dev v4 background task that owns workflow-execution is the only context where decryption is allowed, and only inside the agent handler that is about to make the LLM request.

If an attacker compromises any other surface, BYOK keys do not fall out.

Per-Workspace Routing at Runtime

When workspace A runs an agent block configured for OpenAI, the executor resolves the provider in this order:

1. Look up workspaceBYOKKeys for workspaceId = A and provider = 'openai'.
2. If a row exists and is not rotated/disabled, unwrap the DEK with the workspace-scoped KEK, decrypt the ciphertext, and pass the plaintext into a freshly-created OpenAI client.
3. Otherwise, fall back to the platform key — but only if the workspace's plan allows fallback. Enterprise tenants can require BYOK and refuse to run without it.
4. Emit an audit_log row with action='byok.decrypt', the provider, the workspace, the executor instance, and the workflow execution ID. No key material in the log.

When workspace B runs an agent on the same node in the same second, it gets workspace B's key. There is no shared client cache that could leak between tenants — clients are created per execution, bound to the workspace, and discarded.

Rotation, Revocation, and Audit

Static keys age badly. AACFlow treats key rotation as a first-class operation:

• A workspace owner can rotate a key. The new key gets a fresh DEK and a fresh IV; the old row is marked rotatedAt and kept for 30 days for incident response, then hard-deleted.
• A workspace owner can revoke a key. Revocation marks the row inactive and invalidates the in-process cache across all executor instances via a Redis pub/sub channel — within seconds, no node will decrypt that key again, even if a workflow is mid-run.
• Every decrypt is auditable. Customers on the Enterprise plan can export audit_log rows filtered by action LIKE 'byok.%' and prove to their security team exactly which workflow used which key at which timestamp.

The audit trail is what turns BYOK from a marketing feature into a compliance feature. Without it, BYOK is just a settings page.

What This Buys You

Two things, and they matter more than the encryption itself:

The first is economic isolation. When customers bring their own OpenAI account, they get their own rate limits, their own discounts, their own enterprise agreements with OpenAI. AACFlow doesn't proxy the bill, doesn't add a markup, doesn't pool quota. Your $50k Anthropic commit is yours.

The second is blast-radius isolation. If the platform's primary OpenAI key ever leaks, customer keys are not affected — they live in a different envelope, derived from a different KEK, encrypted with a different DEK. A compromise of one tenant's key does not cascade. That is the whole point of multi-tenant encryption, and most BYOK implementations skip it because plaintext is easier to ship.

Ship BYOK like you ship payment credentials. Anything less is a settings page pretending to be security.

Try AACFlow today and bring your own keys — properly encrypted, scoped, and audited from the first run.