Security

Connecting your accounts to any middle layer is a real trust decision. Here is exactly what OpenLLM does with them, so you can judge it honestly.

Credentials are encrypted at rest

Every provider API key you connect is stored only as ciphertext. It is never written to disk in a readable form.

The unlock key that decrypts a credential is derived from your own OpenLLM API key on each request. It is used in memory just long enough to call the provider, then wiped. OpenLLM does not keep a copy of the plaintext key sitting around.

The practical consequence: a database dump on its own reveals nothing usable. The stored ciphertext cannot be decrypted without the per-request unlock that only your key produces.

The vault and your recovery phrase

That ciphertext lives in your vault, the encrypted store that holds every credential you connect. It is created automatically the first time you sign in, and everything you connect afterward goes into it encrypted.

The vault is protected by a recovery phrase shown to you once, at setup. It is the master secret the vault is keyed under, and OpenLLM does not keep a copy of it. Setup makes you prove you saved it by tapping missing words back into place:

This is a deliberate trade:

• Because no one but you holds the phrase, no one (including OpenLLM) can decrypt your vault for you, and a breach of the server does not expose your credentials.
• Because no one but you holds the phrase, losing it is unrecoverable. There is no reset link. Your only move is to reset the vault, which re-keys it from scratch: stored provider credentials are destroyed, existing sk-llm-… keys are invalidated, and saved memories under the old phrase go with them.

Treat it like a crypto wallet's seed phrase: save it in a password manager the moment it is shown, and never paste it into a chat or commit it to a repo. Saved memories are encrypted under this same vault key and shared across every OpenLLM key you derive from the same phrase.

Locking, PIN, and rotation

Under Settings → Security the vault has a few controls worth knowing:

• Vault PIN. An optional convenience so you are not retyping the phrase to re-open a session on a machine you already trust. It is not a second secret protecting the vault; the phrase is.
• Auto-lock. How long the vault stays unlocked on this device after you enter your PIN. It resets on each unlock, is stored per device, and only applies once a PIN is set.
• This device. Clears the encrypted vault data cached in this browser. You will need your recovery phrase to unlock here again.

Subscription credentials never touch the cloud

Subscription accounts (Claude Code, ChatGPT, Kimi over OAuth) are handled differently from API keys. They run through the local daemon on your own machine. When a request needs one, it runs there against the official vendor CLI's own credentials and returns the result. The subscription credential stays on your machine and never routes through the OpenLLM cloud. See Providers.

Your key is the crown jewel

Because your sk-llm-… key is what derives the unlock on each request, protect it like a password:

• Do not commit it to a repo or paste it into a shared chat.
• Create a separate key per machine or tool where you can, so you can revoke one without disturbing the others.
• Revoke a key immediately under Devices & keys if you think it leaked. Revoking it cuts off access to every credential it could unlock.

Verified downloads

The openllmc CLI and openllmd daemon are downloaded and checked against a published SHA-256 checksum before they run, and they self-update through the same checksum-gated swap. This is a checksum, not a signed binary, but it does defend against a corrupted or tampered download.

Verify the source yourself

The pieces that run on or talk to your machine are public repositories under github.com/openllmsh, so you do not have to take this page's word for any of it:

• daemon — the local daemon (openllmd) and its released binaries.
• cli — the OpenLLM CLI (openllmc), the extension runtime and MCP server.
• tunnel — the binary mux behind tunnel and session streams.
• wire — the wire-format transforms.
• protocol — the public type and wire contracts (MIT).
• registry — the bundle registry the setup and skill installers pull from.

If you want to audit what the daemon does with your subscription credentials, or exactly what an installer writes, the code is there to read.

What OpenLLM does not do

• It does not resell your tokens or add a markup. See Compliance.
• It does not store a readable copy of any provider credential.
• It does not route your subscription credentials through its cloud.