Vault

The vault keeps the secrets a project shares — connection strings, API keys, passwords — so that members stop passing them around by chat and agents use them without the value ever showing in the conversation.

Turn it on

The vault is off by default and needs the Pro plan. The server's host operator turns it on in Settings › Server › Vault. Turning it on adds a Vault tab to every project and enables the vault skill for agents; turning it off hides the tabs and refuses every vault request. Stored secrets stay encrypted in the database and come back when it is turned on again.

Two levels

• Project — a secret of one project. Available on Pro and Max.
• Organization — a secret of an organization, available in every project of that organization. Available on Max, where organizations exist; managed in Settings › Organization › Vault.

A project secret with the same name as an organization secret replaces it in that project only. The organization value stays in use in its other projects. The project's Vault tab strikes through the replaced line.

Names use upper-case letters, digits and underscores, without a leading digit (DATABASE_URL, STRIPE_SECRET_KEY): it is also the name agents use. A value holds up to 8 KB and may span several lines.

Open the vault

Every member of a project opens its vault from the project's menu (… or right-click on the project) › Vault, from the desktop Repository menu, or from the command palette (⌘P › "Open the project vault"). Project admins also find it as a tab of the project settings.

Who can do what

	Project secret	Organization secret
Create, change, delete	Project admins (and organization admins)	Organization admins
Reveal and copy	Decided by the secret's access (below)	Decided by the secret's access (below)
See the names	Every member of the project	Every member of the organization or of one of its projects

Each secret has an access, set by the admins who manage it:

• All editors (organization: All members) — the default: editors and contributors of the project, or every member of the organization, reveal it.
• Admins only — only the admins of the level reveal it.
• Chosen people — the admins, and the members picked one by one. Someone who leaves the project or the organization loses the secrets they were picked for, and does not get them back by being invited again.

Someone a secret is not shared with still sees its name, marked reserved, without Reveal nor Copy. The access concerns people only: every agent of the project keeps using every secret, whatever its access.

Only a person reveals a value; API keys cannot reach the vault. Every creation, change (access included), deletion and reveal is recorded in the audit log (Max plan).

Agents

Every agent running on a card of the project can use every secret available in that project, project and organization levels alike. It never receives a value in its prompt or its environment: the vault skill teaches it to ask for a private file.

stib vault list                    # names, descriptions, levels — never a value
f="$(stib vault file DATABASE_URL)" # a private file holding the value
DATABASE_URL="$(cat "$f")" npm run test:integration

env_file="$(stib vault env-file)"   # every secret as `export NAME='value'` lines
( set -a; . "$env_file"; set +a; npm test )

The files live in a private temporary folder of the card, outside the repository, and disappear when the agent's run ends. In a sandbox they are mounted read-only.

What the vault protects against

The vault avoids showing a value: it keeps it out of chats, prompts and the conversation, where a value the agent prints anyway is replaced by 🔒 secret. It does not shield a value from an agent that is given it — that agent can still pass it on to its model provider. Values shorter than 12 characters are not masked in the conversation.

Changing or deleting a secret does not remove a file already handed to a running agent; that file goes away when its run ends.

Agent proposals

An agent never writes to the vault. When it produces a value worth keeping — a token it just created, a password it rotated — it proposes it:

printf '%s' "$CF_TOKEN" | stib vault propose CLOUDFLARE_API_TOKEN --description "DNS stib.ai"

The proposal shows up in the card's conversation, with its name and description but never its value. Only an admin of the project decides it:

• Add to vault… opens a prefilled form: the level (project, or organization for an admin of the organization), the name, the description and the access. The value goes straight from the proposal to the vault, never through the browser.
• If a secret of the same name already exists, the tile says so and the button becomes Replace…: the value is replaced, and the secret keeps its name and access; choosing the other level creates a new secret instead. A name only the organization holds is replaced in the organization vault by one of its admins; for anyone else, adding it to the project takes its place in that project only.
• Reject deletes the proposed value.

Either way, a decided proposal keeps no value. Archiving or deleting the card withdraws the proposals still waiting.