What is an MCP gateway?

An MCP gateway is a control point that sits between your AI agents and the tools they use. MCP stands for Model Context Protocol, an open standard for connecting AI agents to tools and data, often described as "USB for agents." Each MCP server exposes one capability, such as your CRM, your codebase, or your calendar, and any compatible agent can plug in. The gateway is the checkpoint all of that traffic passes through: it enforces which agents may reach which tools, logs every call, and screens tool output for malicious instructions.

If you have just been asked to approve an agent deployment, this is the practical version: every MCP server your team connects is a new door into your systems, each with its own rules and its own logs, or none. A gateway collapses those doors into one checkpoint you can watch, configure, and audit in a single place.

Why it exists, and what breaks without one

Two problems drove this category into existence. The first is sprawl. Teams connect MCP servers faster than security can review them, and without a gateway there is no inventory of which agents can call which tools, and no single log to reconstruct what happened when something goes wrong.

The second is prompt injection: attacks that hide instructions in content an agent reads. The danger is not only what users type at an agent. It is what the agent's own tools hand back. In 2026, a tool in Microsoft's official Azure DevOps MCP server returned pull request text without a prompt-injection guardrail, so a single hidden comment could redirect a code-review agent into projects it had no rights to and leak what it found (The Hacker News). That was a first-party server from a major vendor. A gateway is the layer where you screen tool output for that class of attack without trusting every server author to have done it for you.

Without a gateway, your controls live in each server and each agent framework separately. With one, you get an allowlist (only what is explicitly approved may connect), a uniform audit log, and one place to revoke access when an agent misbehaves or a server is compromised.

What the current spec changed

MCP is a moving target, and the revision dated 2026-07-28 changed the shape of the thing a gateway sits in front of. Three parts of it decide questions you will end up asking a vendor (MCP specification release notes).

First, the protocol core is now stateless. The old initialize handshake and the Mcp-Session-Id header are gone, and each request carries its own protocol version, client identity, and client capabilities instead. Requests can land on any server instance behind an ordinary load balancer, so a gateway no longer has to pin a conversation to one backend. The same revision added Mcp-Method and Mcp-Name HTTP headers, which means a gateway, rate limiter, or web application firewall can route and meter on headers rather than parsing every JSON body. The legacy HTTP and server-sent-events transport is deprecated on the way out.

Second, authorization got stricter, and most of the tightening lands on the gateway. Authorization servers should return the issuer (iss) parameter defined in RFC 9207, and clients have to validate it before redeeming a code. Client credentials are bound to the issuer that minted them, with no reuse across authorization servers. Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents, though it keeps working for backward compatibility, so real deployments will straddle both for a while.

Third, the spec locked in a proper extensions framework, with Tasks joining extensions such as MCP Apps and Enterprise Managed Authorization. Capabilities now arrive as named extensions rather than as changes to the whole protocol, which means "we support MCP" is no longer a complete answer from a vendor. The follow-up question is which extensions the gateway understands, and what it does with traffic for one it does not.

What to ask vendors

• Can access be allowlisted per agent and per tool, not just per server? An agent that needs one tool from a server should not inherit all of them.
• Does the log capture the full tool call and the full response, and can we export it to our existing security tooling?
• How is tool output screened for injected instructions, and what happens on a hit: block, redact, or flag for review?
• How do agents authenticate through the gateway? MCP builds on OAuth, the standard way software gets permission to act on your behalf. Ask whether the gateway validates the issuer parameter before a code is redeemed, whether it supports Client ID Metadata Documents or only the deprecated registration path, and how a grant gets revoked.
• Does it still require sticky sessions? The current spec is stateless by design, and a gateway that pins each conversation to one backend hands you back a scaling problem the protocol removed.
• Which spec revision does it implement today, and which extensions does it pass through, inspect, or block?
• Who can change policy, and is every policy change itself logged?
• How much latency does the gateway add per tool call, measured, not estimated?