The Model Context Protocol went from a niche idea to infrastructure in about a year. Anthropic now counts more than 10,000 active public MCP servers and over 97 million monthly SDK downloads, and the protocol is wired into most of the major coding assistants. Once a company has more than a handful of MCP servers in play, something has to sit in front of them and manage the traffic. That something is usually called an MCP gateway.
Gateways solve a real problem. They give you one endpoint instead of twenty, a single place to handle sessions, routing, rate limits, and discovery. What most of them do not solve is the question that actually matters once an agent can reach real systems. Not "can this request find the right server," but "should this agent, acting for this user, be allowed to run this tool on this data right now." That is an authorization question, and routing infrastructure was never designed to answer it.
This piece explains what an MCP gateway is, what it does well, and where the authorization gap sits. It is the anchor for a set of deeper articles on MCP authorization standards, enforcing tool gates outside the agent, and vetting third-party MCP servers.
What is an MCP gateway?
An MCP gateway is a proxy that sits between MCP clients and one or more MCP servers. It presents a single endpoint, aggregates the tools those servers expose into one catalog, and handles routing, session management, discovery, rate limiting, and observability. It is the traffic and management layer for an MCP deployment, in the same way an API gateway is for a set of microservices.
That analogy is worth holding onto, because it also tells you what a gateway is not. An API gateway routes and shapes traffic. It is not the thing that decides whether a given caller is allowed to perform a given action on a given resource. The same split applies here. The gateway gets the call to the right MCP server. Whether the call should happen at all is a separate decision.
Why gateways appeared in the first place
The MCP ecosystem grew faster than anyone planned for. When a developer connects a handful of servers to one assistant, there is nothing to manage. When an organization has dozens of internal and third-party servers, each with its own tools, its own auth, and its own operational quirks, the sprawl becomes the problem. A survey of the aggregation and gateway tooling that emerged through 2025 and early 2026 describes the pattern that most of them settled on. One gateway endpoint fronts many backend servers and exposes a unified tool catalog to the client.
This is genuinely useful. It means a client integrates once, not once per server. It means routing, retries, and session state live in one place. It means you get a single stream of logs instead of twenty. For the operational side of running MCP at any scale, a gateway is the obvious move.
The trouble is that consolidating the traffic through one point makes it look like you have also consolidated control. You have not. You have a single place where requests pass through, which is the right place to make an authorization decision, but the gateway does not make that decision unless something is wired in to make it.
What the gateway does well, and where it stops
A gateway is strong at everything that is about moving the request. Routing to the correct server. Aggregating tool definitions. Managing the session lifecycle. Enforcing rate limits. Producing telemetry. If your problem is operational sprawl, that is the answer.
Where it stops is the decision layer. As Frederic Lardinois of the New Stack put it, MCP's built-in security story stops at authentication and OAuth, and does not reach fine-grained authorization. A gateway inherits that limit. It can confirm a token is valid and route the call, but out of the box it has no opinion on whether this particular tool call, with these particular arguments, on behalf of this particular user, should be allowed. That gap is the subject of the rest of this article.
Why authentication at the gateway is not authorization
It helps to be precise about the two things people tend to blur. The MCP authorization specification defines how a client proves who it is. A protected MCP server acts as an OAuth 2.1 resource server, clients present access tokens, and servers must validate that the token was issued for them as the intended audience. This is solid, and it answers the authentication question. It does not answer the authorization question, and the spec is honest about that. Authorization support is marked optional, and even where it exists it governs whether a token is valid for the server, not whether a specific action should run.
The distance between those two things is where real incidents happen. When the AI feature on a widely used work-management platform exposed data across tenants in mid-2025, roughly a thousand customers were affected. The cause was not a broken login. Requests were authenticated with valid credentials. The failure was that the server did not properly check whether the authenticated user should see the specific resource being returned. Authentication passed. Authorization was missing. That is the exact shape of the gap a gateway leaves open if nothing fills it.
The MCP spec's own security guidance names the deeper version of this problem. A proxy that forwards tokens can become a confused deputy, using its own trusted position to do something on behalf of a caller who should not have been allowed. The spec is blunt about the mitigation. An MCP server must not pass through the token it received, and must reject tokens that do not list it in the audience claim. Those are authorization rules, and a gateway that only routes will not enforce them on its own.
Where authorization actually fits
If the gateway is the single point every request passes through, it is also the natural place to enforce a decision. The pattern that the identity community converged on across several 2026 conferences is the same one that has governed microservices for years. The gateway acts as a policy enforcement point, and before a tool runs it asks a policy decision point a specific question.
I spoke on this question precisely during the AuthZEN masterclass at Identiverse 2026. Can this agent, acting for this user, invoke this tool with these arguments. That is a richer question than a token can answer. The token says who the agent is. It does not say who the human behind the agent is, and it does not describe the specific resource the call will touch, which usually depends on the arguments of the invocation. Answering it means evaluating the principal, the action, the resource, and the context together, as a policy decision, at the moment of the call.
There is one more thing the gateway view makes clear, and it came up repeatedly at EIC Berlin 2026. The chain does not end at the MCP server. As Martin Kuppinger of KuppingerCole put it during the EIC agent workshop, the MCP server itself accesses something downstream, and the authorization question follows the request all the way to the data. A decision made only at the gateway, and then trusted blindly the rest of the way, is a decision made too early. The useful pattern is a policy check at each hop, so the answer reflects what is actually being reached, not what was requested at the front door.
This is also why the runtime decision has to stay deterministic. Nathan Harris of Gartner made the point directly at Gartner IAM London 2026, that AI can help build and improve authorization policies but must not be the thing making the runtime access decision, which needs to be fast and deterministic every time. The gateway asks a policy engine, and the policy engine gives the same answer for the same inputs.
What good looks like
Put those pieces together and the target pattern is not complicated. The gateway, or the MCP server behind it, acts as the enforcement point. Every tool call is checked against policy before it runs, and the decision considers who the agent is, who it is acting for, which tool is being called, and what the arguments touch. Access is scoped to the specific tools an agent needs rather than the whole catalog. When policy says no, the call does not execute, and the denial is recorded. When policy says yes, the same record captures why.
The OpenID AuthZEN Authorization API, which reached final specification status in January 2026, is what makes this portable. It defines a standard way for an enforcement point to ask a decision point for a yes or no, which means the gateway and the policy engine do not have to come from the same vendor and are not a lock-in decision. We have written more on what AuthZEN means for enterprises, and it is the connective tissue underneath the pattern described here.
The last property that matters is the decision log. Because every call flows through one enforcement point, you get a complete record of who asked for what, which policy fired, and what the outcome was. That record is what turns "we think the agent is scoped correctly" into "here is the decision, with the policy version that produced it." It is the same reason audit logs matter for any authorization layer, applied to agents.
How Cerbos fits
Cerbos is an authorization management platform that runs as its own component, separate from application and agent code. For an MCP deployment, that means the gateway or the MCP server can call Cerbos as the policy decision point before any tool runs, and get back a deterministic allow or deny based on the agent, the user it acts for, the tool, the arguments, and the context.
The open-source Cerbos PDP is stateless and lightweight, runs anywhere from a sidecar to an air-gapped network, and evaluates checks in sub-millisecond time, so putting a decision in the path of every tool call does not become a latency problem. Policies are written as code, versioned, and tested, so a change to what an agent can do is a reviewed policy edit rather than a redeploy of the agent. Cerbos Hub manages those policies at scale and holds the unified decision log. Because the PDP speaks AuthZEN, it slots in behind a gateway as a standards-based decision point rather than a proprietary one. We go deeper on this in our guide on the dynamic authorization for MCP servers.
The same model covers the rest of the estate, which matters because agents are the fastest-growing part of it. Machine identities already outnumber human ones by more than 80 to 1, and Gartner expects 40% of enterprise applications to include task-specific agents by the end of 2026, up from less than 5% in 2025. Governing agents and non-human identities under the same policy model as human users keeps that growth inside one governed layer.
An MCP gateway is the right place to stand. It gives you one point of control over a sprawling set of servers. The thing to be clear about is that the gateway gets you the standing point, not the control. The control is the authorization decision you put behind it. Get that decision right, make it at every hop, and log it, and the gateway becomes what it looked like it already was.
Try Cerbos to see how policy-based authorization works behind an MCP gateway, or book a call to walk through your agent architecture with the team.
Go deeper:
- Zero Trust for AI: Securing MCP servers (eBook) for a full walkthrough of authorization patterns for MCP
- The Authorization Maturity Model: A CISO's Benchmark (eBook) for where agent authorization fits in a wider program
FAQ
Tagged in
