How do I bring my own model key?
BYOK means Driftless runs model calls on API keys you supply. A connected key is stored in a per-user credential vault, and every model call is proxied by the server with your key attached. This entry condenses the published guarantees on key storage, transit, lifecycle, logging, and export.
Supported providers
Presets cover OpenAI, Anthropic, OpenRouter, and Ollama, each key validated against its provider before anything is saved. OpenRouter reaches its full model catalog; Ollama reaches local and self-hosted models. Any OpenAI-compatible service can be connected as a custom endpoint via its base URL, with named instances so you can hold several.
Key storage
Keys are encrypted at rest with AES-256-GCM in a credential vault scoped to your user account within each organization; provider settings hold only a vault reference, never the raw key.
Key transit
Model calls run through a server proxy: the server resolves your key from the vault, attaches it, and forwards the request to your provider. The key is read for the call, never persisted outside the vault, and accepted once, on save, over your authenticated session; from then on it never reaches client-side JavaScript. The proxy design allows masked display everywhere and clean revocation.
Key lifecycle
Creation, rotation, and revocation are self-service and behave the same way for every provider. An invalid key stores nothing: it is validated before anything is saved. Saving a new key for a connected provider rotates the existing vault entry in place, replacing the old value under the same reference. Deleting a provider connection removes the vault entry and the connection immediately.
Visibility and logging
- Logged: every credential action is written to an audit trail, including each decryption that serves a proxied call.
- Never logged: key material or model request content in any log line or audit field.
- Admin view: organization administrators review the trail for their own organization; one organization's administrators cannot inspect another's.
Data ownership and export
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. Delete your provider connections and the keys are gone from the vault; exported data and provider-side accounts are untouched, and nothing about exporting or revoking locks you out of what you created.
Frequently asked questions
How is my provider key stored?
Each key is encrypted with AES-256-GCM before storage and carries a fresh random 96-bit initialization vector and a 128-bit authentication tag; only the ciphertext, IV, and auth tag are stored, and the encryption key lives in the server environment, never in the database with the values it protects. Storage is a credential vault scoped to your user account within each organization.
Who can see my key after it is saved?
After a key is saved it is displayed masked in the app, and no API response returns it: there is no interface, for any role, that shows a saved key in the clear, and administrators see the same masked representation you do. Listing configured providers returns only the provider identity and model list, with no key material and no vault reference.
What happens when I revoke a key?
Deleting a provider connection removes the vault entry and the connection immediately. Revoking one provider key stops model calls through that provider, for your account, in that organization, and that is the entire blast radius: no other provider, project, task, comment, document, or user is touched. Saving a key for that provider again restores the connection.
What does the credential audit trail record, and who can read it?
Every credential action is written to an audit trail: created, rotated, resolved for use, and revoked, with the acting identity, the credential name, a timestamp, and the source address. Key material is never logged: the audit schema has no field for values, no application log line contains the key, and the records contain no model request content. Organization administrators review the trail for their own organization only; one organization's administrators cannot inspect another's. The 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.