Explainer
What is a governed
MCP gateway?
A plain answer, including where the idea does not earn its keep. If you are deciding whether you need one, the last two sections matter most.
First: what is an MCP gateway?
The Model Context Protocol (MCP) is how AI agents call tools — reading a document, updating a ticket, querying a database. By default, each agent is configured individually: a file on someone's laptop listing which services it can reach, with the credentials for each.
An MCP gateway replaces that with one server in the middle. Agents connect to a single URL. The gateway holds the connections to the upstream services and routes each tool call to the right one. From the agent's side, everything is reachable through one endpoint; from the organisation's side, there is one place where all of it is visible.
What makes it governed?
Routing alone is plumbing. A gateway becomes governed when it enforces policy rather than only forwarding traffic — and that comes down to three capabilities.
Tool-level access control
Not "this agent can use Jira", but "this agent can read an issue and comment on it, and cannot delete one". The unit of permission is the tool, because that is the unit of damage.
Credential custody
Agents never hold long-lived upstream credentials. The gateway holds them and presents them per call. Revocation is one action in one place, rather than a hunt through every machine that might have a copy.
An audit log
Append-only, recording every tool call: which agent, which tool, when, and whether it was allowed. Without this, "what did the agent touch?" has no answer — only reconstruction.
The common thread is that the policy does not depend on the agent choosing to comply. An instruction in a prompt is advice. A gateway that refuses the call is a control. That distinction is the whole point, and it is why "we told the agent not to" is not a governance story.
Gateway vs per-agent config files
Config files are the default because they are the fastest thing that works. Here is what changes when you outgrow them.
Granting access
Config files: per person, per machine, by hand.
Gateway: once, at a team boundary, with a role.
Revoking access
Config files: find every copy of the credential. You will
miss one.
Gateway: revoke centrally; every agent loses it at once.
Answering "what did it do?"
Config files: reconstruct from upstream logs, if the upstream
kept any.
Gateway: query the event log.
Adding a service
Config files: every developer repeats the setup.
Gateway: connect once; everyone with the role has it.
Latency
Config files: direct call.
Gateway: one extra hop. This one genuinely favours config files.
Failure blast radius
Config files: one agent breaks.
Gateway: it is shared infrastructure — if it is down, everything
behind it is unreachable. Also favours config files.
When you do not need one
A gateway is infrastructure, and infrastructure you do not need is a cost with no return. Config files are the right answer when:
You are one person
One developer, one agent, credentials only you hold, nobody to answer to. The problems above are all coordination problems, and you have no coordination.
Nothing it touches matters
If the agent reads public data and writes to a scratch repo, the audit log has nothing to prove and access control has nothing to protect.
You need the last millisecond
A latency-critical path is a legitimate reason to connect directly. Nothing stops you doing that for one path and using a gateway for the rest.
The moment it flips is usually not a decision — it is a question. Someone asks which systems the agents can reach, or what one of them did, and the honest answer is "I would have to go and look". That question is the signal.
Choosing between gateways
If you have decided you want one, these are the dimensions worth comparing — including on us.
Permission granularity
Per integration, or per tool? Per-integration means granting "Slack" when you meant "post to one channel".
Where credentials live
Who can decrypt them, and can you self-host so the answer is "only us"?
Whether the audit log is a product tier
An audit log you have to upgrade to get is an audit log you will not have during the incident that needed it.
Where your data sits
Can it live in a database you own, or only in the vendor's? This decides what leaving costs.
Client compatibility
Does it work with any MCP client and any model provider, or does it assume one vendor's stack?
Exit cost
If you stop paying, what do you keep? Ask this before you start, not after.
For the record, OneDroid Synapse answers these as: per tool; self-hostable so we can see nothing; the event log is in the free tier and will not be gated; your data can live in your own Postgres; any MCP client and any provider; and if you leave, the data was already in your database. The security page states the same in detail, including what we have not done.
Try it against your own setup.
Free for individuals and small teams. No credit card. Connecting an agent takes one command.