Vault

Every workspace accumulates credentials — a login for a service with its own username and password, an API key for an integration, a signing secret you paste once and reference forever. The vault is the one place those credentials live, so they sit under a single protection model instead of scattered across notes, environment files, and chat messages. Staying in control is not only about approving work and capping spend; it is also about knowing your credentials are held safely, on terms you can explain to anyone who asks.

A credential is split into what is safe to see and what must stay hidden. For a login, the site it signs in to and the username or email it uses are ordinary metadata — visible in the list, editable at any time — while the password is sealed. A login can also carry an authenticator (2FA) key: paste the setup key your authenticator app shows and it is sealed as a second, independent secret, so codes can be produced later at the point of use without the key itself ever being shown. An API key or a secret works the same way: an optional label and address stay visible, and only the key or secret itself is sealed. You always know which login goes with which account; you just cannot read the password or the 2FA key back.

The vault keeps a growing list navigable with tabs — All shows every active credential, and Logins, API keys, and Secrets narrow to one kind — each on its own address, so a view can be bookmarked or shared. A search field filters the current tab by name, website, or username; it never searches a sealed value.

Each secret is encrypted under its own key

A credential in the vault is sealed the moment you save it, and it is sealed with a key that belongs to that one credential — never a single shared key protecting everything at once. Each value gets its own data key, and that data key encrypts the value with authenticated AES-256 encryption. Two credentials in the same workspace are protected by two different keys, so the compromise of one value's key tells an attacker nothing about any other.

This per-secret design is what lets the vault stay both safe and practical. The value's own key is small, so the master key that protects it can change, and the protection can be rotated, without ever re-encrypting the secret itself. You get strong isolation between secrets and cheap key management at the same time, rather than trading one for the other.

The workspace is authenticated into the encryption

Isolation between workspaces is enforced by the cryptography, not by an access check bolted on top. When a value is sealed, the workspace's identity is bound into the encryption itself as authenticated data. Decryption only succeeds in that same workspace's context — a ciphertext carried into another workspace's context will not decrypt at all, because the identity bound into it no longer matches.

The difference matters. An access check is a rule the application chooses to enforce, and a rule can be bypassed by a bug that forgets to run it. Binding the workspace into the encryption means one workspace's secrets are undecryptable in another's context as a property of the math, so a mistake in application code cannot quietly hand one workspace another's values.

Master keys stay in Scaleway Key Manager

In production, the master key that wraps every credential's data key is held in Scaleway Key Manager, an EU-resident key management service. Task Machine never holds that master key in plaintext: to protect a data key it asks Key Manager to wrap it, and to use a data key it asks Key Manager to unwrap it, and the master key never leaves the service. Workspaces are kept apart over that shared master key by the same workspace binding described above, authenticated into each wrap.

Because the value's encryption is independent of how its data key is protected, the vault can move from local development protection to Scaleway's key management — or rotate the master key on a schedule — without touching a single stored ciphertext. The secret you saved stays exactly as sealed; only the small wrapped key changes.

The sealed value is write-only, and that is the point

The visible metadata is yours to read and edit, but every sealed field — a login's password, its authenticator key, an API key, a secret — is different: you can save it and you can replace it, but you can never read it back. Not through the interface, not through an export, not as an administrator, not even as the person who entered it. There is no reveal control anywhere in the vault, because there is no path that returns a sealed value to a screen. When a password needs to change, you replace it with a new one; the previous value is discarded and is never shown again. A two-factor code is the one thing produced from a sealed field, and even then only the six-digit code is generated at the point of use — never the key it came from.

This is a protection, not a limitation. A secret you cannot read back is a secret that cannot leak through a screenshot, a support session, a copied field, or a screen recording. The vault trades the convenience of looking a value up — which you rarely need and which is the exact moment secrets escape — for the guarantee that a stored secret has one way out, and that way is not a person reading it off a page. Keep your own copy of anything you might need to enter somewhere else; the vault's job is to hold the workspace's copy safely, not to be your notebook.

Deleting a credential sends it to the trash first

Deleting a credential does not destroy it on the spot. It moves to the trash, where it stays recoverable for 30 days before it is permanently purged. The trash view shows each credential's countdown — how many days remain before it is gone for good — so a mistaken delete is a quick restore, not a lost secret. If you are certain, you can delete a trashed credential permanently right away instead of waiting out the window.

The 30-day purge runs on its own: a scheduled job deletes credentials whose trash window has passed, so nothing lingers sealed-but-forgotten. Restoring a credential before then returns it to the active list exactly as it was, sealed value and all. Moving to the trash, restoring, and permanent deletion are all gated by the credential-management permission.

What the vault does today, and where the boundary is

Today the vault stores your workspace's credentials under the protection described above: you add a login, an API key, or a secret; edit its visible name, site, and account; set or replace a sealed value or a login's authenticator key; and move it to the trash, restore it, or delete it permanently — and none of those operations ever surfaces a sealed value. Naming stays out of your way: leave the name blank and the vault fills in a sensible default from what you entered, so a login becomes its site and account and a key becomes its address, and you can always type your own name instead. Every mutation is gated by the credential-management permission, while viewing the list needs only the credential-read permission — and neither permission ever exposes a sealed value, because no permission can.

Agents can now use those stored secrets, on the same terms — an agent never sees a sealed value. An agent browses only metadata: tama secret list and tama secret search return a credential's name, kind, site, and username and whether it carries an authenticator, and never a password, secret, or seed. To actually use a credential the agent references it by name and runs the consuming tool under tama secret exec, which decrypts the field at the point of use and injects it into that child process only — as a short-lived 0600 file on tmpfs, or an environment variable when asked — while the value is scrubbed from the child's output and never reaches the agent's own prompt, transcript, or model. A login's authenticator produces a fresh six-digit code the same way, server-side, without the seed ever leaving the vault. When the agent needs a strong password it does not invent one: tama secret generate has the server mint and seal it, returning only metadata.

Agents can also write credentials — tama secret set creates a login when signing up for a site, or an API key or secret for a tool — but a write is not a quiet side effect. It requires the credential-management grant, is audited, and raises a notification to the workspace, so a new credential an agent creates is something you see rather than something that appears unannounced. And resolving a field the agent has not been granted does not run the command: the request lands for a human to approve first, exactly as approvals and budgets gate the rest of an agent's reach. Everything an agent does with the vault builds on the model above — values decrypted only at the point of use, never returned to a model, a prompt, or a transcript.

Managing who can see and change credentials is part of the wider permissions story, and the vault sits alongside approvals and budgets as one of the places you stay in control of what your agents can reach.