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. Instead of an agent holding your credentials and talking to GitHub or Gmail directly, it holds a short-lived token and talks to the gateway, which checks the call against a policy, forwards it if it is allowed, refuses it if it is not, and records both outcomes. You need one at the point where a second agent, a second tool, or a second person's credentials enters the picture.

Why did this become a category at all?

Because MCP won, and winning 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 a genuine standard with genuine neutral governance now.

That solved connection and left control untouched. 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, the interesting question stops being "can they connect" and becomes "who decided they could".

What does a gateway actually do?

Four jobs, and they are separable:

It mints 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 is doing most of the work here, because the failure you are guarding against is not a malicious agent but a capable one being helpful in a direction nobody considered.

It writes the log. This is the part that is hard to retrofit 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 thing that carried the call.

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

When do you actually need one?

You do not need a gateway to try an agent. One agent, one tool, one developer's own credentials, work that is easy to check by eye: a gateway is overhead, and saying otherwise would be selling.

The threshold is crossed when any of these becomes true:

• More than one agent, because now "which one did that" is a question with a wrong answer.
• A write path to a system you care about. Reading a repository is recoverable. Opening pull requests, sending mail and moving money are not, 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, and each extra step is another place authority gets stretched.

Is a gateway the same as agent observability?

No, and the distinction is the practical one to get right.

Observability tools read what happened and show it to you well: traces, spans, token costs, tool-call failure rates. They sit beside the path. A gateway sits in the path, which is what lets it refuse a call rather than record one. The 2026 market reviews are blunt that this is where the tooling is thin, describing 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 one of them stopped it.

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.
• Traces are append-only and hash-chained. A log the operator can quietly edit answers no question anybody serious will ask.
• Refusals are recorded, not just failures. The blocked calls are the most interesting data the gateway produces, and the easiest to drop on the floor.
• Redaction happens at capture. Filtering personal data out of a trace store afterwards means it was in 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 exactly this sense: from a vendor's side we are one endpoint URL and a temporary key, and the policy, the staging queue and the trace sit behind it. We do not write per-system connectors, because the protocol already solved that part.