MCP Gateway: When You Need One and When Direct MCP Is Fine

An MCP gateway is a single controlled path between your agents and your MCP servers. It handles auth, allow-lists, logging, and rate limits in one place.

You probably do not need one for two or three servers owned by one team. You probably do once you have ten or more, spread across teams, with some run by third parties.

This post covers what a gateway does, how to decide, and how to run server approval. It builds on our MCP security guide.

Direct MCP and where it hurts

Direct MCP means each agent or client connects straight to each MCP server. Each connection has its own credentials, its own config, and its own logs. If you are new to the protocol, start with what MCP is.

With a few servers, this is fine. With many, four problems show up.

1. Credentials sprawl. Every client-server pair holds a secret or token somewhere. Nobody has a full list.
2. No single list of approved servers. Developers add servers to config files. Security finds out later, if ever.
3. Fragmented logs. Each server logs in its own format. Reconstructing what an agent did means pulling from many places.
4. Uneven controls. One server rate-limits. Another does not. One checks tokens properly. Another trusts anything.

These are not theoretical. A few real cases from 2025:

• In April, Invariant Labs described tool poisoning attacks. Hidden instructions in a tool description are visible to the model but not to the user. A server can also change a tool’s description after you approved it. They call that a rug pull.
• In July, JFrog disclosed CVE-2025-6514, a critical flaw (CVSS 9.6) in mcp-remote, a proxy many people use to connect clients to remote servers. A malicious MCP server could make the client machine run OS commands.
• In September, The Register reported on a fake postmark-mcp package on npm. It published 15 clean versions, then added a line in version 1.0.16 that copied every outgoing email to an attacker. Koi Security estimated about 1,500 downloads in a week.

A gateway does not fix all of that. But it gives you one place to enforce a rule instead of fifty.

What an MCP gateway does

A gateway sits between clients and MCP servers. Kong, one vendor that sells one, describes it as a reverse proxy and management layer that handles authentication, authorization, routing, and policy. That is a vendor view, but it matches how I use the term.

In practice, it does five jobs:

1. Authenticates the caller. It knows which user and which agent is making the request.
2. Authorizes the call. It checks the caller against a policy for that server and that tool.
3. Routes the request to the right backend server.
4. Enforces limits. Rate limits, timeouts, and size limits.
5. Logs everything in one format.

A gateway is not a replacement for good servers. The MCP spec says each server must still validate its own inputs and access controls. The gateway is one layer. The server is another.

Auth and allow-lists

How do I authenticate MCP servers?

The MCP spec makes authorization optional. When a server uses HTTP transport, the spec says it should follow its OAuth 2.1-based flow. A few points from that document matter for gateway design:

• The MCP server acts as an OAuth resource server. It checks access tokens.
• Servers must validate that a token was issued for them, not for something else. Clients use resource indicators (RFC 8707) to bind a token to the target server.
• An MCP server must not accept tokens meant for other services, and must not pass the client’s token on to an upstream API. The spec calls out “token passthrough” as forbidden.
• Servers on the stdio transport are not covered. They take credentials from the environment.

For a gateway, here is what that means. It is my reading, not spec text. Treat the gateway as the front door that owns identity. Users sign in through your identity provider. The gateway issues or exchanges tokens bound to each backend server. It never forwards one token blindly to everything behind it. That keeps one stolen token from working everywhere.

For agents, use their own identity, not a shared service account. See AI agent identity and non-human identity.

Allow-lists

Allow-listing has two levels:

• Server level. Only approved servers are reachable through the gateway. Everything else is blocked at the network edge.
• Tool level. Each agent sees only the tools it needs. Kong’s example is a backend with 40 tools where a security-scanner agent is shown only 2. Default deny is the right starting point.

Tool-level control matters because of the spec’s own warning. Tool annotations are untrusted unless they come from trusted servers. Hidden instructions in a description reach the model whether you meant them to or not. The gateway can pin the approved tool list and flag any change.

Logging and rate limits

What does a gateway add to logs?

The spec says clients should log tool usage for audit. A gateway makes that one log for all clients. Here is what I’d record per call:

Field	Why it matters
Timestamp and request ID	Tie events together
User and agent identity	Who or what acted
MCP server and tool name	What was called
Policy decision, with reason	Allowed or denied, and why
Argument summary or hash	Evidence without storing secrets
Result status and size	Success, error, big data pulls
Latency	Spot slow or stuck servers
Approval ID (if human-approved)	Link to the sign-off

Store arguments carefully. They may hold personal or regulated data. Hash or redact first, and keep the raw form only where policy allows. For more on what to log and why, see what to log in an AI agent audit trail.

Rate limits

The spec says servers must rate limit tool calls. A gateway lets you set limits per user, per agent, and per server in one place. I’d set:

• A per-agent call limit per minute, to stop loops.
• A per-server limit, to protect fragile backends.
• A cap on result size, to limit data pulls.
• A daily budget alert for anything that costs money per call.

When a limit trips, return a clear error to the agent and alert a human. Pair this with a kill switch so someone can cut off one agent or one server fast.

Registry and approval flow

How do I approve new servers?

A registry is the catalog of servers you have approved. A gateway enforces it. The registry is the list. The gateway is the lock.

The official MCP project launched the MCP Registry in preview on September 8, 2025. It is an open catalog of public servers. The announcement says organizations can build sub-registries, including private ones inside enterprises with strict security needs. It also says maintainers publish self-reported information, and the registry relies on community reports to catch spam, malicious code, or impersonation. So a public listing is a starting point, not an approval.

Here is the approval flow I’d use:

1. Request. A team asks for a server. They state the business need, the owner, and the data it will touch.
2. Triage. Is there already an approved server that does this? Many requests end here.
3. Source check. Who wrote it? Is it the vendor’s own? Is the code open? Are there signs of copied code or a changed owner? (The postmark case was a copy of a real project.)
4. Review the surface. List every tool, scope, and network destination. Flag write actions and anything that reaches personal data.
5. Test in a sandbox. Run it with fake data. Watch its network calls.
6. Set policy. Which agents and roles may use which tools. Default deny.
7. Pin the version. Record the version and a hash of the tool list.
8. Publish to the internal registry. Only now can the gateway route to it.
9. Re-review on change. A new version, a new tool, or a changed description sends it back to step 4.

Keep the whole flow short for low-risk read-only servers and strict for write access. And find out what is already running first: a shadow AI agent inventory will show servers nobody told you about.

When direct MCP is fine

Do not build a gateway because it sounds mature. Kong suggests adding one beyond two or three servers. That is a vendor’s line, and I’d set the bar higher. These are my rules of thumb, not a standard.

Direct MCP is fine when:

• You run fewer than about five servers.
• One team owns all the servers and all the agents.
• Servers are internal, read-only, or low risk.
• Nothing regulated passes through them.
• The agents are in a pilot, with a human approving actions.
• Local stdio servers are used by developers on their own machines. A gateway does not add much there. Sandboxing and consent do more.

Add a gateway when any of these is true:

• You have ten or more servers.
• More than one team builds or connects servers.
• Third-party or remote servers are in use.
• Agents can write to systems of record.
• Auditors or customers ask who accessed what.
• You cannot list your servers from memory.

Situation	My call
3 internal read-only servers, 1 team	Direct, with a written server list
6 servers, 2 teams, some write access	Direct plus a registry list, plan the gateway
10+ servers, third parties, regulated data	Gateway
Any server that moves money or sends external messages	Gateway, plus human approval

In the direct case, you still need three basics: an approved server list, per-agent credentials, and logs you can read.

Build or buy

For most enterprises, I’d buy or adopt first. Gateways are security infrastructure. Writing your own proxy to learn the lessons others already learned is a slow way in.

Questions to ask any vendor or project:

• Does it support OAuth 2.1 and your identity provider?
• Does it bind tokens per backend server and refuse passthrough?
• Can it enforce tool-level policy, not just server-level?
• Can it pin tool lists and alert on description changes?
• Does it write structured logs you can send to your own systems?
• Can it run in your cloud or on-premises? This matters for data residency.
• What happens to a session when the gateway fails? Fail closed is the safe default.

Build your own only if you already run an API gateway with strong policy tooling, and you only need a thin MCP layer on top. Even then, plan for upkeep. The protocol keeps changing. See the MCP 2026 roadmap for where it is heading, and how to build an MCP server if you will write backends yourself.

Watch for one trap. A gateway is a single point of failure and a single point of compromise. It holds the keys to everything behind it. Secure it harder than any single server.

Bottom Line

A gateway gives you one place to authenticate, allow-list, log, and limit MCP traffic. It earns its cost at about ten servers, multiple teams, or third-party servers.

Below that, direct MCP is fine if you keep an approved server list, give each agent its own credentials, and keep readable logs.

My recommendation: start with the registry and the approval flow. They work with or without a gateway. Add the gateway when the list stops fitting in your head.

FAQ

What is an MCP gateway? It is a proxy that sits between AI clients and MCP servers. It handles authentication, authorization, routing, rate limits, and logging in one place. Agents connect to the gateway, and the gateway connects to approved servers.

Do I need an MCP gateway? Not for a handful of internal, read-only servers owned by one team. You likely need one at about ten servers, with several teams, third-party servers, or write access to systems of record. Those thresholds are my rule of thumb, not a standard.

How do I authenticate MCP servers? For HTTP servers, follow the MCP authorization spec, which is based on OAuth 2.1. Servers validate that tokens were issued for them, and they never pass a client’s token to another service. Use your identity provider, and give each agent its own identity.

How do I approve new MCP servers? Run a short review: check the source and owner, list every tool and scope, test in a sandbox, set a default-deny policy, pin the version, then add it to an internal registry. Send it back for review whenever the version or tool list changes.

What does a gateway add to logs? One log for all calls, with the user, the agent, the server and tool, the policy decision, an argument summary, the result, and the time taken. That lets you answer who did what, and why it was allowed.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect