Skip to main content
The Wirebox Vault gives your agents the credentials they need to act in the real world: website logins (with two-factor TOTP), API keys, and freeform secrets. It completes the picture alongside email and phone — an agent can now sign up for a service, receive the verification email, and store and reuse the resulting login, including its 2FA codes.
The vault is zero-knowledge: all encryption and decryption happen on your side (in the SDK, CLI, or your browser). The server only ever stores ciphertext — Wirebox never sees your secrets.

How It Works

Two keys are involved, and only one of them ever reaches the server: When you unlock the vault, your vault key is stretched with Argon2id into a master key, which unwraps an organization encryption key held only in memory. That key encrypts and decrypts each secret with AES-256-GCM. The server stores the ciphertext and some plaintext metadata (a secret’s name and type), nothing more.
There are no recovery codes. If you lose your vault key, the vault cannot be decrypted and must be re-initialized. Store the key somewhere safe — a password manager or your secrets manager of choice.

Secret Types

The totp object on a login holds secret (base32), plus optional algorithm (sha1/sha256/sha512), digits (6/8), and period (30/60).

Two Roles

The vault separates managing secrets from using them:
  • An admin (a Console session or an admin API key) initializes the vault, creates and edits secrets, and grants agents access.
  • An agent (an identity-scoped API key with the vault:read scope) can unlock the vault and read only the secrets it has been granted — the server filters ciphertext per identity, so an agent can never download a secret it was not given, even though it holds the vault key.

Initialize the Vault

Done once per organization. A strong vault key is generated and returned — save it now.
You can also initialize the vault from the Console.

Unlock the Vault

Unlocking derives the key client-side and returns a handle you can read and write secrets through. The vault key is read from the argument, or from the WIREBOX_VAULT_KEY environment variable.

Create Secrets

Payloads are encrypted locally before upload. Secrets are addressed later by name or id, so give them clear names.
TOTP can be added from an otpauth:// URI (as above) or, in the Console, by uploading the QR image shown during a service’s 2FA setup.

Read Secrets

Secrets come back decrypted from the unlocked vault. List metadata without the vault key; read values after unlocking. Secrets are addressed by name or id.

Generate TOTP Codes

For a login that has TOTP configured, generate the current one-time code client-side.

Update and Delete

In the SDK, an update re-encrypts the payload you pass, so provide the complete payload (read it first) to change one field. The CLI merges the fields you pass.

Give an Agent Access

This is the end-to-end flow for letting an autonomous agent use a credential. 1. Create an identity-scoped API key with the vault:read scope. In the Console, create an API key scoped to the agent and check Allow vault access (vault:read). This key authenticates the agent and lets it read the vault. 2. Grant the agent access to specific secrets. Secrets are addressed by name or id; the CLI also accepts an agent handle.
3. Give the agent its two keys — the vault:read API key (WIREBOX_API_KEY) and the vault key (WIREBOX_VAULT_KEY). The agent can now unlock and read only what it was granted:
Revoke access at any time; it takes effect on the next unlock:

API Reference

For the raw REST endpoints — remember that payloads are ciphertext produced client-side — see the Vault API reference.