BYOK and key sovereignty

Supported providers

Bring your own key for any of the preset providers, or point Driftless at any OpenAI-compatible endpoint you control.

Key storage

Your provider key is encrypted before it is written to storage, and it is stored in a credential vault that belongs to you, not to a shared pool.

• Encryption at rest. Keys are encrypted with AES-256-GCM. Each key gets a fresh random 96-bit initialization vector and a 128-bit authentication tag, and only the ciphertext, IV, and auth tag are stored. The encryption key is held in the server environment and never in the database with the values it protects.
• Per-user vault. Keys live in a credential vault scoped to your user account within each organization. Your provider settings hold only a vault reference, never the raw key.
• Masked everywhere. After a key is saved, it is displayed masked in the app. No API response returns it. Listing your configured providers returns the provider identity and model list, with no key material and no vault reference.

Key transit

Stated plainly: Driftless uses a server proxy model. Your key transits the Driftless backend.

• Model calls are proxied by the server. When a model call runs, the Driftless server resolves your key from the vault, attaches it, and forwards the request to your provider. The key is read for the call and never persisted outside the vault.
• Keys never reach the browser. The key is accepted once, on save, over your authenticated session. From then on it is never sent to client-side JavaScript: no page, no API response, and no log line contains it.
• No client-held end-to-end claim. This page does not claim keys are held client-side end to end, because they are not. The proxy design is what lets Driftless show you a masked key everywhere and revoke cleanly.

Key lifecycle

Creation, rotation, and revocation are all self-service, and each behaves the same way for every provider.

• Creation. A key is validated against the provider before anything is saved. An invalid key stores nothing: no vault entry and no provider connection.
• Rotation. Saving a new key for a provider you already connected rotates the existing vault entry in place. The old value is replaced under the same reference, so no duplicate entries pile up and nothing dangling survives.
• Revocation. Deleting a provider connection removes the vault entry and the connection immediately.

What revocation kills

Revoking one provider key stops model calls through that provider, for your account, in that organization. That is the entire blast radius. It does not touch any other provider you connected, any project, task, comment, or document you own, or any other user. Saving a key for that provider again restores the connection.

Visibility and logging

Because model calls are proxied, the Driftless server processes your key at call time. What the platform does around that is bounded and logged.

• What is logged. Every credential action is written to an audit trail: created, rotated, resolved for use, and revoked, each with the acting identity, the credential name, a timestamp, and the source address. Every decryption of your key to serve a proxied call is part of that record.
• What is never logged. Key material. The audit schema has no field for values, and no application log line contains your key. The audit records also contain no model request content.
• Who can see the record. Organization administrators can review the credential audit trail for their own organization. It is scoped per organization: one organization's administrators cannot inspect another's.
• What nobody can see. There is no interface, for any role, that shows a saved key in the clear after it is stored. Admins see the same masked representation you do.

Data ownership and export

Your work product is yours, and you can take it with you without asking anyone.

• Read your data out. Tasks, initiatives, PRDs, and tech specs are exportable at any time, and projects, comments, and media are accessible through the same surfaces, the REST API and the MCP tools, so your content can be extracted in full.
• Export the credential record. The credential audit trail exports to JSON and CSV, and a compliance report covers credential inventory, rotation status, and access patterns, in a format suitable for SOC 2 and security review.
• Leaving. Delete your provider connections and the keys are gone from the vault. Your exported data and your provider accounts on the provider side are untouched. Nothing about revoking keys locks you out of what you created.

Exportability

Sovereignty includes the ability to take your work with you. What is exportable is published, and the mechanism is documented, so the claim can be checked rather than taken on faith.

• Your work product is exportable at any time. Tasks, initiatives, PRDs, and tech specs are exportable at any time. The mechanism is the documented one: the REST API serves initiatives and PRD / tech-spec section management alongside tasks, comments, and media, and the MCP tools expose the same surface. See the API Reference and the MCP documentation.
• Published surfaces are the check. The API reference, MCP documentation, and this page are crawlable, so the guarantees on this page can be verified against published behavior.
• Leaving stays clean. Exporting your data and revoking your keys are independent actions: nothing about either locks you out of what you created.