How Vaubaan compares
Vaubaan Gateway differs from the usual ways of giving an agent access in one respect: the agent never holds the credential, and every call it makes is decided against a mission a person wrote, permission by permission, with limits and approvals, then recorded.
Handing the agent a token
The common way: create a token at the service and paste it into the agent's configuration.
| A token in the agent's configuration | A mission of Vaubaan Gateway | |
|---|---|---|
| What the agent holds | the credential itself, which it can print, copy or leak | a mission key, which opens this mission and nothing else |
| What it may do | everything the token's scopes allow, on every resource the token reaches | the permissions and resources of the mission, named one by one |
| How much | unlimited until the token expires | a limit per period and a rate for each permission |
| Dangerous actions | nothing asks you | "ask me first" makes each use wait for the mission's creator |
| Afterwards | the service's own logs, if any | every call recorded, allowed or refused, with the permissions it needed and whose key made it |
| Revoking | rotate the token at the service, everywhere it is used | stop the mission or replace its key; the account stays connected |
What it costs: an instance to run, a mission to write, and only the service tools a plugin covers — see plugins.
A secrets manager
A secrets manager stores credentials and hands them to the programs allowed to read them: whoever reads the secret can then do anything it allows. Vaubaan Gateway never hands the stored secret over: it uses it for one call it has decided, and returns the result. The two fit together — the gateway's own master key can live in your secrets manager — but the gateway is not one: it stores only the credentials of the accounts connected to it, and only to use them itself.
Other MCP gateways
Many MCP gateways and proxies put several MCP servers behind one endpoint and add sign-in, logging and lists of allowed tools. What Vaubaan Gateway adds, and what it gives up:
- Decisions below the tool name. A plugin classifies each call, with its arguments, into named permissions of a reviewed catalog (
github.merge-protectedis notgithub.git-push); a call that touches a permission the mission does not hold is refused, and an unknown tool or an unclassified call is refused too. - Limits and approvals per permission, counted per mission, answered by a person in the interface; an agent can neither widen its own mission nor approve its own action.
- Your infrastructure only. One instance per company, behind your identity provider, with your company's own app at each service; no hosted tenant.
- Fewer services. Only the services a plugin covers, and only their tools the plugin declares; it does not relay arbitrary MCP servers.
What it is not
- Not a secrets manager (above).
- Not a proxy for command-line tools or SDKs: only MCP calls and git over HTTPS go through it. A credential an agent finds elsewhere on its machine is outside its reach.
- Not highly available: one process, one embedded database.
- Not finished: pre-release, never run in production, no third-party audit (known limitations, trust center).