The short answer: a proxy gets a call to the right place. A gateway decides whether that call should happen at all, on whose authority, and writes down that it did. Both sit between an agent and the tools it calls — which is exactly why the terms get used interchangeably, and why that interchangeability causes real problems once agents are doing more than sitting in a demo.
An MCP proxy is a relay for one connection. It presents itself as a normal MCP server to whatever's calling it, and as a normal MCP client to whatever it's actually talking to on the backend. Its job is mechanical: bridge a transport mismatch (an agent speaking stdio, a backend that only speaks streamable HTTP), attach the right credential to the outbound call, and expose only the tools that connection needs. A proxy doesn't know who's calling it in any meaningful sense beyond "this request came with this credential." It forwards. It doesn't decide.
An MCP gateway is a policy layer sitting in front of many connections at once. It knows who the agent is acting on behalf of, what that person or team is allowed to do, and it writes that decision down every time it's made. Where a proxy answers "how do I reach this tool," a gateway answers "should this specific call, from this specific agent, acting for this specific person, be allowed to happen right now" — and it answers that question the same way regardless of which of the dozens of tools behind it someone's trying to reach.
The clean way to hold this: every gateway is built out of one or more proxies. Not every proxy needs to become a gateway. The proxy is the mechanism. The gateway is the decision made using it.
Say an agent needs to read and, occasionally, update records in a CRM.
With just a proxy: the proxy bridges the transport, holds a vaulted credential for whichever user is running the agent, and exposes "read record" and "update record" because that's what the connection was configured to expose. It does this correctly, every time, for this one connection. What it can't tell you: whether this specific update, right now, from this specific agent, acting for this specific person, should be allowed — that's not a question the proxy is built to ask. If the credential it's holding is valid, the call goes through.
With a gateway in front of that same proxy: the request first passes through a policy check — is this person's role allowed to update records at all, or only read them? Is this the kind of update (say, deleting a record vs. editing a field) this role is scoped to make? The gateway answers that, logs the decision against the actual person, and only then lets the call reach the proxy that actually talks to the CRM. Take the gateway away and the proxy still works exactly as before — it just can't tell you whether it should have.
A common assumption: "I'm only running one MCP server, so I don't need a gateway yet." That assumption doesn't hold up against the actual threat model. A single server can still serve a poisoned tool description, leak credentials through the arguments an agent sends, or return a response engineered to manipulate the agent's next action. The number of servers doesn't change what can go wrong — it only changes how many places it can go wrong in. A proxy inspecting one connection can catch some of this for that connection. A gateway sitting in front of everything is what makes catching it a policy, not a hope.
Understanding the full scope of MCP security risks in the enterprise is a prerequisite for knowing when a proxy alone is insufficient and when a gateway becomes mandatory.
Not every situation needs a gateway, and it's worth saying plainly when a proxy is actually enough:
The moment any of those stop being true — more than a handful of connections, more than one team or customer needing different access, or a real requirement to answer "who did what, and was it allowed" after the fact — that's the point a proxy alone stops being the right answer, whether or not anyone's called what comes next a "gateway" yet.
For a deeper look at what a gateway actually is and what it enforces, What Is an MCP Gateway? covers the full picture. And if you're thinking through the MCP authentication and authorization build vs. buy decision, that framing applies directly to whether you roll your own proxy logic or adopt a gateway layer.
The access control requirements for multi-tenant AI agents are a practical forcing function: once you have more than one customer's data in scope, the questions a gateway answers stop being optional. Similarly, audit trails for agent auth in B2B SaaS become a hard requirement the moment you need to answer "who did what" — something no proxy alone can provide. When agents operate across enterprise environments, IT governance requirements mean that AI tools connecting to internal systems carry real accountability obligations that gateway-level policy is designed to meet.
No — it's the other way around. A gateway is typically built using one or more proxies underneath it, plus a policy and identity layer on top. A proxy by itself has no concept of policy.
The number of servers doesn't determine whether you need one — the threat model is the same whether you're running one server or fifty. What determines it is whether you need to answer "should this specific action have been allowed" as more than a hope.
Yes, and in practice this is the normal shape: a gateway sits in front, making the policy decision, and hands the approved call off to the proxy that actually talks to the backend tool.
Some architecture writeups introduce "router" as a middle tier — it knows which tool a request is for, but not who's calling. In practice this is a partial gateway: useful for getting a first version working quickly, but it stops short of the identity and audit questions a full gateway answers.
