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. The same tab bar includes Settings, which opens the separate workspace signup-email configuration without mixing that preference into the credential library.

Account signups use an approved email identity

Choose the Settings tab in the Vault to select the Signup email identity agents may use when you approve creating a separate website account. The workspace default applies to every agent unless an agent's Workforce settings select a different login. The setting stores a reference to an active login whose visible username is an email address. It never copies the mailbox password.

Selecting an email does not let agents create accounts on their own. Each website still produces its own request in the Inbox, where you see the website, credential kind, requesting agent, reason, and signup email before deciding. Approval grants the mailbox only to the current task and posts the signup instruction to the assigned agent. The agent then uses tama secret generate to create and seal the new website login without seeing its password.

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. Sealed fields are different, including a login's password, its authenticator key, an API key, and a secret. You can save or replace these values, but you can never read them back through the interface, an export, administrator access, or the account that entered them. The vault has no reveal control because no path returns a sealed value to a screen. When a password changes, its previous value is discarded and never shown again. Editing a login with an authenticator key leaves that key unchanged unless you paste a replacement. Removing it is a separate action beside the setup-key field with its own confirmation, so changing the login's other details cannot remove two-factor authentication. A two-factor code is the only output produced from a sealed field. Task Machine generates the six-digit code at the point of use without revealing its key.

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. Task Machine accepts the write only from the agent's active run, and every write is audited and raises a workspace notification, so a new credential is visible rather than appearing quietly. When metadata search finds no suitable credential, tama secret request sends the missing website, kind, and reason to the Inbox without including a secret. Resolving a known credential field without a grant likewise stops before running the command and raises an access request. Everything an agent does with the vault follows the same boundary: values are decrypted only at the point of use and never returned to a model, prompt, or transcript.

Members with credential grant access can manage an entry's agent access from its Vault row. A requested grant can be approved once, for a chosen period, or indefinitely. Active access can be revoked immediately. A revoked row keeps its history and offers Grant again, which asks for current terms instead of restoring the previous duration.

Chat and run transcripts identify Vault activity with a Vault mark rather than a connector mark. When your role allows Vault access, the activity names each referenced credential and shows its website logo where one is available. The command arguments, credential values, and Vault command output remain hidden. Without Vault access, the transcript keeps the activity visible but does not reveal credential metadata.

Workspace connectors use the same boundary. An installed connector can map a vault entry to the environment variable its command expects. A remote connector can either open the service's account consent screen, use vault-backed request headers, or run without authentication. Before Task Machine saves a new or changed remote connection, backend Verification resolves the selected value only for that bounded check and never includes it in the result. Assigning a credential-backed connector raises its agent access decisions in the Inbox instead of silently widening access. If the connector reaches those credentials before approval, its work waits and continues after the grant is approved. Later agent work resolves the value again at the point of use, removes temporary configuration when the work ends, and keeps refresh credentials on the server.

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.