Do You Need an MCP Gateway? Security Trade-offs Explained

An MCP gateway is a proxy that sits between your AI assistants and the MCP servers they use. Instead of every client connecting to every server, clients connect to the gateway, and it decides which servers exist, who may reach them, what credentials they use, and what gets logged. Whether you need one depends on size and shape. A small team using a handful of remote servers that each sign people in with OAuth is usually well served by per-client settings and the servers’ own permissions and logs. A gateway starts to pay for itself when you have many people, many servers, local servers you want to sandbox, or a requirement to enforce and prove policy in one place. It also adds a hop, a single point of failure, and a new place where tokens can be mishandled.

This piece assumes you know the risks a gateway is meant to reduce; they are set out in MCP security risks, and the practices that apply with or without a gateway are in MCP security best practices.

What a gateway does

• A central allowlist. Clients see only the servers and tools the gateway exposes. Adding a server becomes an administrator’s change, not a line in someone’s config.
• Authentication at one door. People sign in to the gateway once; the gateway decides which upstream servers they reach.
• Credential handling. Upstream keys and tokens live in the gateway rather than on laptops, and are injected per request.
• Logging. Every tool call passes through one place, so there is one log to search.
• Policy. Some gateways can block tools, filter inputs and outputs, rate-limit, or run local servers in containers with restricted privileges.

Three examples, structurally

Gateways range from a local process on one laptop to a cluster service. Three open-source projects show the range, described here as their own documentation describes them.

• Docker MCP Gateway↗ (opens in a new tab) runs MCP servers in isolated containers with restricted privileges, network access and resource use. Clients talk to the gateway; it starts the right server when a tool is called, injects the credentials it needs, and provides logging and call tracing.
• Microsoft’s MCP Gateway↗ (opens in a new tab) is a reverse proxy and management layer for MCP servers in Kubernetes, with session-aware routing, a control plane for deploying servers and registering tools, and Entra ID authentication with role-based authorization.
• IBM’s ContextForge↗ (opens in a new tab) describes itself as a registry and proxy that federates MCP, A2A and REST or gRPC APIs, with authentication, rate limiting, OpenTelemetry tracing and an admin interface.

Commercial API gateways and security vendors offer MCP features too. Judge any of them by the questions later in this piece, not by the feature list.

What per-client settings already give you

Before adding infrastructure, look at what your clients and servers already do. Claude Code is a good example. Its managed settings↗ (opens in a new tab) let an organisation set allowedMcpServers and deniedMcpServers, and set individual tools to ask on every call or to be blocked. Servers shared by a project live in .mcp.json, which goes through version control and code review. Remote servers sign each person in with OAuth, so each person has their own token.

claude mcp list          # every server this machine will use
claude mcp logout <name> # clear the stored sign-in for one server

Add to that the servers’ own controls, such as scopes, roles, revocation and a history of changes, and a small team has an allowlist, per-person identity, least privilege and an audit trail without a gateway in the path.

When a small team does need one

• You run local servers that need secrets or file access, and you would rather they ran in a container than as you.
• People use several different clients, and you cannot enforce one allowlist across all of them any other way.
• Some servers you depend on offer only a shared API key, and you want that key held in one place rather than on every laptop.
• You need one log of every tool call across servers, for a customer, an auditor or your own incident response.
• You want to block or filter particular tools centrally, and your clients cannot do it for you.

If none of these is true, the gateway is more to run than it saves. Revisit the question when the team or the server list doubles.

The trade-offs

Another hop, and one point of failure

Every call now goes through one more service, with its own latency, upgrades and outages. When the gateway is down, every assistant loses every tool at once. And because it holds credentials for everything behind it, it is the most valuable thing on your network to attack. Patch it, restrict who administers it, and keep its own secrets out of its config files.

Token handling: the no-passthrough rule

The MCP authorization specification↗ (opens in a new tab) (revision 2026-07-28) is blunt: an MCP server must only accept tokens issued for it, and must not accept or transit any other tokens. If it calls an upstream API, it uses a separate token issued for that API. A gateway that speaks MCP to your clients is an MCP server in the specification’s terms, so this applies to it. It must validate the audience of the tokens clients send it, and must not forward those tokens to the servers behind it.

The specification gives the reasons: forwarding a token bypasses the downstream server’s own controls, and it leaves neither side able to tell clients apart, which breaks the audit trail. A gateway that simply relays whatever Authorization header arrives is the anti-pattern the rule was written for.

Consent when the gateway signs in upstream

If your gateway lets clients register dynamically and then signs in to a third-party service with one static client id of its own, it is the proxy in the specification’s confused deputy example. It must obtain the user’s consent for each client before forwarding to the third party, on a consent page that names the client, shows the scopes and redirect address, and cannot be framed, and it must match redirect addresses exactly.

Who did it, after the gateway

A gateway that uses one shared credential for an upstream server makes every change there look like the same actor. You gain a central log and lose the upstream server’s own record of which person acted. Where the upstream server supports it, prefer a gateway that obtains a token per person for each server, so both logs agree on who did what.

New attack surface of its own

The specification’s security guidance↗ (opens in a new tab) singles out proxies that spawn local servers over stdio: combined with a client-side flaw, they can turn a web bug into command execution on the host, so it recommends sandboxing spawned processes and logging every stdio launch. A gateway that runs as a server and follows OAuth discovery links is also exposed to server-side request forgery, and the guidance suggests an egress proxy that blocks internal addresses.

Questions to ask of any gateway

1. Does it validate that client tokens were issued for it, and use separate tokens upstream?
2. Can it keep per-person identity through to each upstream server?
3. How does it handle consent when it signs in to third-party services?
4. Does it run local servers isolated, and log what it launches?
5. What happens to your assistants when it is unavailable?

A board behind a gateway

fenbs is a task board and a remote MCP server that signs each person in with OAuth. Each token is capped by the read, write and comment scopes ticked at approval and by that person’s role on the board, can be revoked on its own under Settings, “Connect an AI assistant”, and every change is recorded in History as “Claude via” the person it acted for. Most teams need no gateway in front of it. If you do route it through one, give the gateway per-person tokens rather than one hand-issued token for everyone. With a single token, every change would be recorded as the person who issued it.