Where your own provider keys live, and where they never go

Some Players want to use their own accounts with model providers rather than rely on keys the platform supplies. Fabulator supports this, and because a provider key is a credential that can spend money, it is worth being clear about what the platform does with it and what it does not do.

This is a description of the design as documented, in everyday language. It is not a security audit, and it is not a promise that nothing can go wrong. Where there are limits, they are stated.

The short version

Your keys are encrypted in your browser, using a passphrase only you know, before they are sent anywhere. The server stores the encrypted result and treats it as an opaque blob. It never receives the passphrase, and it is built not to decrypt, parse or log the contents.

The platform's own database has no columns for plaintext keys. Everything you supply lives inside one encrypted field on your account.

What happens when you add a key

When you set up the vault in your settings, you choose a Vault Passphrase. Your browser uses it to derive an encryption key with a deliberately slow key-derivation function, then encrypts a small document holding your provider keys with a standard authenticated cipher (AES-GCM). Only the encrypted output is uploaded.

The setup also generates a recovery key and shows it to you once. The design uses two separate wrappers around one underlying data key: one unlocked by your passphrase and one by the recovery key. That is why a recovery key can open the vault without the passphrase, and why changing your passphrase does not require re-encrypting your provider keys.

The passphrase has a minimum strength requirement, enforced before the vault is created. This matters because anyone who obtained the encrypted blob could try guesses offline, with no server to rate-limit them.

What happens when you play

When you open the game on a device, your browser fetches the encrypted blob and decrypts it locally with your passphrase. When a turn needs a model call, the decrypted key travels with that request to the gateway and orchestrator as request-scoped metadata, and is used for that call. The orchestrator is specified to hold keys in byte slices for the shortest practical time, clear them after the provider request completes, and keep them out of logs and error messages. The documentation is candid that this is defense in depth rather than an absolute guarantee, since runtimes can copy memory in ways application code does not control.

Between the gateway and the orchestrator, the channel carrying keys is meant to be encrypted with TLS whenever the two services do not share a host.

What community rulesets can see

Authors can publish rulesets compiled to WebAssembly, and they run inside a sandbox. That sandbox does not receive environment variables, request headers or the memory where provider keys are held. A ruleset is a guest with only the capabilities the host explicitly gives it, and keys are not among them.

The trade-offs you should know about

• Forgetting the passphrase has a real cost. The server cannot reset it, because it never had it. If you lose both the passphrase and the recovery key, the stored keys cannot be recovered, and you would add them again. Resetting your account login password does not change this.
• A compromised browser is outside the protection. The design defends against a compromised server or database. It cannot defend against malicious software or an injected script running in your own browser while the vault is unlocked, because that is where the keys are in use. The portal restricts script sources to reduce that risk, but you should still keep your devices in good order.
• Keys are decrypted client-side by design. Because the server never learns your passphrase, decryption has to happen in the browser before a request is made.

Is it worth it?

If you are happy playing on the platform's own provider setup, you do not need any of this. The vault exists for Players who already hold provider accounts and want their turns to run through them, or who want to use a specific model. If that is you, the practical advice is simple: pick a long passphrase you will not forget, store the recovery key offline when it is shown, and revoke any provider key at the provider itself if you ever suspect it has been exposed.

You can find the key vault in your account settings, and the design notes are in the project's BYOK specification for anyone who wants the details.