BYOK and key sovereignty
Driftless runs on your model keys. This page states the concrete guarantees behind that: who can see your API key, who can see your data, and how you leave. Every claim below is written against the shipped implementation, and the runtime source is public, so you do not have to take our word for any of it.
Supported providers
Bring your own key for any of the preset providers, or point Driftless at any OpenAI-compatible endpoint you control.
| OpenAI | Connect with an OpenAI API key. The key is validated against OpenAI before it is saved. |
|---|---|
| Anthropic | Connect with an Anthropic API key, validated the same way. |
| OpenRouter | Connect with an OpenRouter key to reach its full model catalog. |
| Ollama | Connect to an Ollama host for local and self-hosted models. |
| Custom endpoints | Any OpenAI-compatible service via its base URL, with the key stored in your vault and the request proxied by the server. Named instances, so you can hold several. |
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. Projects, initiatives, tasks, comments, and media are accessible through the REST API and the MCP tools, so your content can be extracted in full at any time.
- 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.
Self-hosting verification
The strongest guarantee on this page is not a promise, it is a repository. The driftless runtime is open source under the MIT license, and every claim above can be checked against it: the vault, the encryption, the proxy path, and the audit trail.
- Read the source. The runtime lives at github.com/Iron-Flank/driftless-agent, MIT licensed. Verify the storage, transit, and logging guarantees line by line.
- Run it yourself. The same runtime can be self-hosted, so the sovereignty guarantees are enforceable outside the hosted platform, not just words on a marketing page.