vaultgate

vaultgate

A self-hosted, remote MCP server that lets hosted AI agents such as Claude, Claude Cowork, Claude Code and Codex use your credentials without ever seeing them. The credentials stay in your Bitwarden (or Vaultwarden) vault. vaultgate uses them on the agent's behalf against systems you define (an HTTP API, Microsoft Graph, a SQL Server or PostgreSQL database, an SSH or WinRM host, a GitHub repository searched with Semble) under your policy, and hands back only the result. It is its own OAuth 2.1 authorization server, so the agent holds a short-lived, scoped, revocable token and nothing else.

Status: release candidate. Milestones M1 to M7 are merged: configuration, SQLite store,

operator identity with TOTP, the OAuth 2.1 authorization server, the MCP tool surface, the

managed bw serve backend, the audit trail, packaging and the Azure template. M8 (hardening and

compatibility evidence) is in progress. The actions layer, opt-in and off by default, has landed

through M14: M9 the engine, the operator pages and the http connector, M10 the Microsoft Graph

credential adapter, M11 sql, M12 ssh, M13 winrm, and M14 the policy-form validation

messages, the call-history and writes views and grant management from the connected-clients

list. M16 adds the code connector: Semble code search over private GitHub repositories, with

its sidecar (guide). An http destination may pin its certificate

or trust a private certificate authority, and the oauth2 credential mode obtains tokens from

any OAuth 2.0 token endpoint (guide). vaultgate's own per-call

write confirmation is withdrawn: approval belongs to the agent's client. The opt-in credential

relay serves bw serve's read API to programs on tagged Tailscale nodes

(guide). browser is M15; see docs/PLAN.md.

Why

A credential an agent can read ends up in the transcript. Once an agent reveals a password in order to use it, the value sits in the model's context, in the chat transcript, in the client's logs and on whatever command line the agent builds, and revoking the agent does not take it back. vaultgate is built so that the agent never needs the value:

• Use, don't read. With the actions layer enabled (guide, spec 13 and 13a, ADR 0007), an agent names a target you defined and describes an operation: an HTTP request, a SQL query or statement, a command on an SSH or WinRM host, a Semble search of a GitHub repository. vaultgate fetches the credential from the vault, connects to the pinned destination, runs the operation inside your policy, scrubs every injected value from the result and returns what is left. An agent never supplies a host, a URL base, a database name or a credential; its arguments change what runs, never where or as whom.
• Writes are opt-in twice, and approved where you work. A write needs its own scope at consent and a target policy that allows it. Approving each call is the agent's client's job — Claude Code, for one, asks before it runs a tool its permissions do not allow — and the console lists every call that changed something.
• One audited door for the rare value that must be read. The vault tools return metadata. A single tool returns a secret value, one field of one item per call, behind its own scope, with every call audited.
• Nothing runs on the vaultgate host. No tool runs whatever an agent sends wherever it likes: ssh_run and winrm_run run one command on one configured host under your allowlist (a target that accepts any command needs both its own flag and the deployment's consent), and every operation executes at its target.
• The agent holds a token and nothing else. The master password and API key live only in the vaultgate process on your host, encrypted under your secret key once you connect the vault on the console's Vault page.
• Standards as written. OAuth 2.1, PKCE, RFC 9728 / 8414 / 8707 / 7591 / 7009 / 9207 and Client ID Metadata Documents, per the MCP authorization specification (2026-07-28).
• Any Bitwarden. bitwarden.com, bitwarden.eu, self-hosted Bitwarden and Vaultwarden.
• Boring to operate. One process, one SQLite file, structured logs, health probes, an audit trail. docker compose up is a complete installation.

Compared with other Bitwarden MCP servers

Hosted agents reach MCP servers over HTTPS and cannot run a process next to your vault, and the other Bitwarden MCP servers are built for exactly that local process:

"Not described" means the project's README does not document one. Dated verification notes with links, and when the official stdio server is the better choice: docs/comparison.md.

Quick start

The current version is 0.1.0-rc.28 (package.json; releases are tagged on GitHub). On a VM with Docker Engine, the Compose plugin, a DNS name pointing at it and ports 80 and 443 reachable from the internet:

git clone https://github.com/adamrowles1996/vaultgate.git

cd vaultgate cp .env.example .env

Set VAULTGATE_DOMAIN, VAULTGATE_PUBLIC_URL and VAULTGATE_VERSION in .env, then:

mkdir -p secrets

head -c 32 /dev/urandom | base64 > secrets/vaultgate_secret_key touch secrets/bw_password secrets/bw_client_secret chmod 0