What is an MCP gateway and when do you need one?

An MCP gateway is a proxy that every agent tool call passes through on its way to a Model Context Protocol server. Without one, an agent holds your credentials and talks to GitHub or Gmail directly. With one, the agent holds a short-lived token and talks to the gateway. The gateway checks each call against a policy. It forwards the call if it is allowed, refuses it if it is not, and records both outcomes. You need one once a second agent, a second tool, or a second person's credentials comes into the picture.

Why did this become a category?

Because MCP became the standard, and that created a new problem.

The protocol went from a December 2024 specification to the default way agents reach tools in about eighteen months. There are now more than 10,000 published MCP servers and roughly 97 million monthly SDK downloads, with first-class client support across the major assistants. In December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. It is now a real standard with neutral governance.

That solved connection. It did not solve control. A protocol says how an agent asks for a tool. It says nothing about whether this agent, today, should be allowed to have it. Once every system in your company speaks one protocol, connecting is easy. The question that matters becomes "who decided they could connect?"

What does a gateway do?

It does four separate jobs:

It issues the credentials. The agent never holds your GitHub token. It holds a short-lived key the gateway issued, scoped to the work it was contracted for. The real credential stays in a vault and never appears in agent context, in a log, or in a trace.

It enforces a policy. Every server registers with a map saying which of its tools are reads, which are writes, what scopes each needs, and what gets redacted. Anything the map does not explicitly allow is refused. Deny by default does most of the work here. The failure it guards against is a capable agent being helpful in a direction nobody considered, rather than a malicious one.

It writes the log. This part is hard to add later and easy to underrate. If the agent reports its own activity, your audit trail is a statement by the party under review. A gateway-written trace is a record made by the system that carried the call.

It intercepts writes. Read-type tools pass through. Write-type tools land in a staging area first, so a change to a live system stays a proposal until something approves it.

When do you need one?

You do not need a gateway to try an agent. Say you have one agent, one tool, one developer's own credentials, and work that is easy to check by eye. A gateway is overhead there, and saying otherwise would be a sales pitch.

You need one when any of these becomes true:

• More than one agent, because now "which one did that?" is a question someone can get wrong.
• A write path to a system you care about. Reading a repository is recoverable. Opening pull requests, sending mail and moving money are not recoverable in the same way.
• Credentials that are not the operator's own. The moment an agent acts with organisational access, somebody has to be able to say what it may do.
• Anyone who will later ask what happened. An auditor, a customer, a regulator, or you in three months.
• Multi-step workflows, which is now most of them. Over half of organisations running agents report multi-step rather than single-action work. Each extra step is another place where an agent can reach past the authority it was given.

Is a gateway the same as agent observability?

No, and the difference matters in practice.

Observability tools record what happened and show it to you clearly: traces, spans, token costs, tool-call failure rates. They sit beside the path of the call. A gateway sits in the path. That is what lets it refuse a call instead of only recording it. The 2026 market reviews say plainly that tooling is thin here, and describe the gap as policy enforcement at execution time rather than depth of monitoring.

A useful test: if the agent does something it should not have, does your tool produce an alert or a refusal? Both are worth having. Only a refusal stops the call.

What should you look for in one?

• It wraps servers generically. If adding an integration means writing connector code, you have bought a connector framework. Registering a server and writing its policy map should be configuration work.
• Traces are append-only and hash-chained. Nobody serious will trust a log the operator can quietly edit.
• Refusals are recorded as well as failures. The blocked calls are the most useful data the gateway produces, and the easiest to lose.
• Redaction happens at capture. If you filter personal data out of a trace store afterwards, it was already stored there.
• A kill switch that is one action. If halting an agent requires a deploy, you do not have a kill switch.

Cognibl is an MCP gateway in this sense. From a vendor's side we are one endpoint URL and a temporary key. The policy and the trace sit behind it, and write tools stay closed until the staging queue is ready. We do not write per-system connectors, because the protocol already handles that.