How your keys are stored
The security model behind every key you connect: encrypted at rest, scoped narrowly, delivered in the safest way for each type, and revocable at any time.
How we keep your keys safe
Every credential you connect is encrypted at rest using AES-256-GCM before it is stored. It is never written into a container image and never visible in plain text in the product. This is the foundation of the trust model: the key on file is unreadable without the platform’s protected decryption.
Keys are also scoped narrowly. A secret has exactly one of two homes: it is either tenant-wide — a shared "skill secret" available to the AI capabilities your whole organisation uses — or per-user, an "integration" such as your personal git token or an OAuth login that belongs only to you. Nothing is shared more widely than it needs to be.
Crucially, how a key reaches the AI employee depends on what kind of key it is. Provider keys for AI and media services stay at our backend and are proxied. Operational secrets like git tokens and database passwords are injected into your container only for the lifetime of a running session. Both paths are revocable at any time.
Proxied vs injected
Proxied keys cover AI and media providers — for example Google or Gemini, ElevenLabs, HeyGen, and Firecrawl. These keys never enter your workroom. When the AI employee needs one of these services, it calls a backend proxy that holds the key and makes the request on its behalf. The key stays at the platform, so even code running inside the container cannot read it.
Injected keys cover operational credentials such as git tokens, database passwords, and your Tailscale network key. These are decrypted and set as environment variables inside your container only at the moment a session starts, because the AI employee genuinely needs them present to do the work — to push to your repository or connect to your database. When the session ends, that injected value is gone.
The split is deliberate: a provider key that only ever makes outbound API calls never has to touch your environment, while a credential the tools must use directly is present only as long as it is actually needed.
Revoking access
Because nothing is permanently embedded in the workroom, you can cut off access whenever you choose. Remove a key from the platform and it stops being proxied or injected from that point on.
You can also revoke at the source — rotate or delete the token in the provider’s own console (GitHub, your database, Tailscale, and so on) — and the stored copy becomes useless. This means you always retain ultimate control over every credential you have shared, independently of the platform.