Skip to main content
Vaults let an Agent use a credential without Avibe exposing its value through Vault responses. Agents refer to secrets by name, field, tag, or Skill tag; Avibe handles storage, policy, approval, and delivery at the boundary where the credential is actually needed.

​
The core rule

Avibe’s Vault APIs return names, value-free metadata, approval states, or public signatures — not secret values. This keeps the value out of chat and model context as long as the command receiving it does not print or otherwise disclose it. vibe vault run cannot sanitize a child process’s stdout or stderr. If that process prints its environment or includes a credential in diagnostic output, the output can return to the Agent and enter model context. Only run commands you trust not to expose secret-bearing output. For a static secret, Avibe can inject the value into a child process or attach it to an authenticated HTTP request. For a signing key, the private key stays in custody and only a public signature comes back.

​
Standard and Protected preview

Protected Vaults are designed for end-to-end encrypted custody, but the current build does not yet enforce the immutable sandbox integrity gate required for real users. The UI demonstrates the passkey flow; Protected must not hold production credentials, wallets, or other real secrets until that gate is enabled.

​
Static secrets and keypairs

  • Static secret — an API key, token, password, or connection string. Use it with vibe vault run for process-local environment injection or vibe vault fetch for authenticated HTTP egress.
  • Keypair — a deployment signing key. Its private key is not exportable and cannot be used with run or fetch; use vibe vault sign to sign a 32-byte digest. Protected keypair custody has the same pre-launch restriction above.

​
Secrets with several fields

A static secret can hold several named fields, like an item in a password manager — for example username, password, and totp for one account. One field is the default. A secret created with a single value has one default field named value.
  • Only static secrets have fields; a keypair keeps its single key.
  • Field names use lowercase letters, digits, and underscores, and start with a letter. A secret holds at most 32 fields.
  • You choose the default field when you create the secret. It can be renamed later but not switched to another field.
  • NAME refers to the default field and NAME.field to a named one; NAME.<default field name> is the default field too.
  • Approving a secret covers all of its fields, and a --tag or --skill selection delivers every field of each selected secret.
vibe vault run names the environment variables like this: vibe vault fetch --auth NAME.field attaches that field’s value to the request; the allowed hosts and auth scheme still come from the secret’s policy. In Vaults, add fields while creating a secret, or choose Use template for Login (username, password) or Login + 2FA (username, password, totp). The editor shows how an Agent will reference each field. On an existing secret you can replace any field’s value, add or remove fields, and rename the default field. Other field names are fixed: to rename one, remove it and add it again. Replacing, adding, or removing a value ends the secret’s active approvals; renaming the default field does not. An Agent can ask for a secret with several fields in one request:

​
When an Agent needs a missing secret

  1. The Agent creates a request with the secret name, reason, and non-secret metadata.
  2. The request appears in Vaults in the Workbench.
  3. You review the request, choose Standard, and enter the value in the browser. Protected is preview-only in the current build.
  4. Avibe resumes the requesting Agent Session after the secret is ready.
This keeps the credential value out of the request and setup conversation even when the Agent is the one that discovers the requirement.

​
When an Agent asks to delete a secret

An Agent never deletes a secret on its own. vibe vault remove NAME creates a delete request and leaves the secret in place until you decide.
  1. The request appears in Vaults and as an approval card in Chat, with the secret’s name, description, tags, and the Agent’s reason. For a secret with several fields, the card lists every field that will be removed.
  2. Delete removes the whole secret. Protected secrets and signing keys need a five-second hold on Delete; other secrets take one click.
  3. Deny keeps the secret.
  4. Avibe tells the requesting Session the outcome. If an Agent asks again while a request for the same secret is pending, it gets the existing request.
Deleting needs instance management access; anyone who can review the request can still deny it. An Agent cannot remove a single field — vibe vault remove NAME.field is rejected — so remove fields yourself in Vaults.

​
Finding secrets

The search box in Vaults matches names, descriptions, tags, Skills, allowed hosts, field names, and NAME.field references — never values. Every word you type has to match. Press / to focus the search and Esc to clear it.
  • Tags filters by one or more tags or Skills, listed by how many secrets use them. A secret has to carry every tag you pick.
  • Quick filters show All, Protected, Signing keys, or Never used secrets, and the list sorts by Name, Recently used, or Recently added.
  • Search, filters, and sort stay in the page URL, so reloading or sharing the link keeps the same view.
Agents search the same value-free metadata with vibe vault find.

​
Authorizing avault on macOS

On a Mac, avault keeps the key that encrypts Standard secrets in your login Keychain. avault 0.1.8 and later are signed by Avibe, and macOS asks once before a newly signed avault may read a key that an earlier avault created. Avibe installs the signed avault automatically, so after that update Vault cannot use the key until you approve it:
  1. Vaults, Settings → Dependencies, and vibe doctor show that avault needs a one-time authorization. A Vault request that hits it fails with avault_authorization_required, and the Agent is told to ask you instead of retrying.
  2. Choose Authorize avault, or run vibe vault key authorize in Terminal on that Mac’s desktop.
  3. A macOS dialog appears on the Mac running Avibe, not in your browser. Enter that Mac’s login password and choose Always Allow.
Later signed avault updates read the key without asking again. If you choose Deny or close the dialog, macOS does not show it again for about two minutes. The dialog needs a logged-in desktop session on that Mac: when you work remotely, reach its screen through Screen Sharing or ask someone at it, and use Authorize avault rather than vibe vault key authorize over SSH. Avibe never shows the dialog on its own: only this explicit action does, and an Agent asks you instead of starting it.

​
Common commands

Use vibe vault find and vibe vault tags when the Agent should select by metadata instead of an exact name. See Commands for the CLI map.