Here is the pattern almost every program uses for a cloud API key, and the reason it's quietly wrong. At startup, the program reads the key — from an environment variable, a config file, a secret store — and stashes it in a variable. From then on, every request to the cloud provider reaches for that variable. The key now lives in process memory for as long as the process runs, which is to say: indefinitely, in a place that a crash dump, a memory inspection, or a leaked log line can expose.

For a system whose entire promise is that it holds your secrets carefully, that pattern is a contradiction we weren't willing to ship. So the daemon does something deliberately less convenient: it forgets the key between requests.

Fetch on use, never hold

The cloud-provider keys live in the vault — the encrypted store that holds the things only you should be able to read. They do not get copied out at startup into a long-lived variable. Instead, the moment an actual request to a cloud model needs the key, the daemon retrieves it from the vault, uses it for that one request, and lets it go.

Our design note states the rule and the decision behind it without hedging. The mechanism: "API keys stay in the vault and are retrieved per request" through a dedicated vault bridge, and — the load-bearing clause — they are "never held as instance state." And the decision, listed among the project's key architectural choices: "Vault-on-use API keys. Keys retrieved per request, never held in memory."

"Never held in memory" is the strong claim, and it's the one that matters. The window during which the plaintext key exists is the window of a single request, not the lifetime of the daemon. If you inspect the running process between requests, there is no key sitting in a field waiting to be found. The cost is a vault lookup per cloud call. The benefit is that the most sensitive thing the daemon touches has the shortest possible life.

The vault is the gate, so the UI follows the vault

This composes with something the rest of the system already enforces, and the composition is the elegant part. The vault has a lock. When it's locked — before you've authenticated, after you've stepped away — its contents are inaccessible. Because the API keys live in the vault rather than in a process variable, "the vault is locked" and "the keys are unavailable" become the same fact. There's no separate, looser copy of the key that survives the lock.

And the interface honors that fact. Our note records it plainly: "The provider UI is hidden while the vault is locked." Think about what that prevents. If the key-holding surface stayed visible and operable while the vault was sealed, you'd have a UI promising access to something the security model says is unavailable — a lie at the interface, and exactly the kind of silent inconsistency the project's honesty commitment forbids. Instead, the cloud-provider controls simply aren't there to interact with until the vault is open. The screen tells the truth about what's reachable.

This is the same principle that governs the rest of the system's sensitive surfaces — governance controls, for instance, only come online after authentication completes, the way four independent gates decide who sees your data. A locked vault isn't a soft suggestion that some features prefer you don't use them yet. It's a hard floor: the secret is sealed, and everything that depends on the secret, including its own UI, is sealed with it.

What this design refuses to optimize away

The tempting optimization is obvious: cache the key after the first fetch. You'd save a vault lookup on every subsequent request. It would be faster. And it would reintroduce precisely the thing we built this to avoid — a long-lived plaintext copy of the secret, now in two places instead of one, defeating the lock the moment the vault re-seals.

So we don't. The fetch-per-request cost is the price of the property, and the property — the daemon does not remember your cloud key — is worth more than the microseconds. For a system that asks you to trust it with your memory, the willingness to be slightly slower in exchange for holding your secrets for the shortest possible time is not an overhead. It's the product.

The detection of which cloud vendors you've configured is automatic — the system discovers configured providers on its own, behind one door for every model you run. But discovering that a provider exists and holding its key are different acts. The first can be ambient. The second is deliberate, scoped to a single request, and gone the instant that request completes.

An API key the daemon forgets between requests. That's not a limitation we apologize for. It's the behavior we designed for.

Written by AI agents from real project logs; owned and edited by Mujo.