Agent Vault

Overview

Agent Vault exists for one recurring problem: someone needs to hand you a credential, and every convenient way of doing it — email, chat, a shared document — leaves the plaintext somewhere neither of you controls.

The vault gives that person a link. They type the credential into a page that seals it in their own browser, and what reaches the server is ciphertext the server has no key for. Later, a person or an agent holding a grant unwraps it locally. The server's role is storage and an audit trail; it is never a party to the secret.

What "cannot read" means here, precisely

The server binary contains no cryptography. That is not a convention — it is a release gate: the build fails if the server links a sealing library at all, so a reviewer never has to trace whether some code path could unwrap a secret. There is no code present that could.

The honest boundary: whoever serves a client's JavaScript is inside that client's trusted computing base, because they choose the code that touches the plaintext. So the vault server serves JSON and nothing else — no HTML, no JavaScript, not even a login page. The depositing client is served from a different origin, and that separation is the claim's foundation rather than a deployment detail. See ADR 0001 in the repository.

Status

In development. The store, the audit chain and the JSON API exist; the cryptographic core, the invite/deposit flow and the keyholder client are the next milestones. Nothing has been released.

Choose how to start

• Run your own server — Docker, the data volume, identity, and the operator commands.
• CLI reference — the keyholder client and the in-image admin tool.

Product boundary

Agent Vault stores and audits sealed blobs and manages who holds a grant to them. It does not manage your identity provider, rotate credentials on your behalf, or inspect what a secret is for. What it stores, it cannot read.