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 unexpected-write views, grant management from the connected-clients list and the elicitation hardening. M16 adds the code connector: Semble code search over private GitHub repositories, with its sidecar (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 three times. A write needs its own scope at consent, a target policy that allows it and, when you ask for it, a human confirmation on every call; the console lists every write that ran without one.
• 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: