The vault is the vault. This is documentation.
Most documentation platforms store your clients' passwords next to their printer IPs. Trove KB stores a reference plus the non-secret metadata it needs to display and search, and brokers access to your own Bitwarden, Vaultwarden, 1Password, or HashiCorp Vault when somebody with the permission asks.
Start with a link. Broker when you trust it.
An MSP inherits whatever each client already uses, so a company can name its own provider and a company that names none uses the instance default. Two vaults can map the same company without colliding.
A secret field stores a deep link to the item. Zero trust required, nothing to run. The default.
Search and pick items, username and URI inline, reveal password and TOTP on click, create an item from a document, map companies to collections.
A self-hosted Connect server on your own network. Search, reveal, TOTP, item creation. A company maps to 1Password vault ids.
A company maps to a path prefix; each secret under it is an item. Read-only by design. Not yet proven against a live Vault.
The official CLI, as a sidecar.
Bitwarden's vault data is end-to-end encrypted; no server-side API returns a plaintext item. The one thing that can is bw serve from the official CLI, running locally with an unlocked vault. So that is what the sidecar runs, signed in as a dedicated service account scoped to the client collections Trove KB should see, with the master password in a Docker secret file rather than an env var.
docker compose --profile vault up -d and the sidecar is on the internal network with no published port. Trove KB syncs it on a schedule and before creating an item.
Non-negotiables.
- →Reveal requires can_reveal_secrets. Every reveal and TOTP copy writes an audit entry.
- →Revealed values go out with Cache-Control: no-store and are never logged.
- →Never in a revision, an export, a search index, a webhook payload, or an MCP response.
- →API keys need an explicit secrets:reveal scope. Off by default.
- →The item picker only searches the collections mapped to the current company. No cross-client leakage.
- →If the sidecar is down or locked, secret fields degrade to link mode and say so.
- →The bw-serve sidecar never publishes a port. It has no authentication of its own, so it lives on the internal network only.
Worth being plain about
In brokered mode, anyone who fully compromises the Trove KB host can read everything the service account can read. That is the tradeoff any platform that brokers credentials makes. Scope the service account tightly, keep the sidecar internal, and stay on link mode if that risk is unacceptable.
Keep the passwords where they are.
Link mode works on day one with no setup. Brokered mode is one compose profile away.