Every integration technology eventually grows a gateway. APIs got API management. Service meshes got ingress controllers. Model calls got AI gateways. It is no surprise that MCP is getting one too: a central component that sits between AI applications and MCP servers, decides who may reach what, brokers credentials, enforces quotas, records every call and can switch things off.
The case for one is real. Without it, every host keeps its own list of servers, every server implements its own audit format and the only way to stop a misbehaving server is to change every host that uses it. The case against is also real. A gateway is a new hop, a new team, a new single point of failure and, if it is run badly, a new place where every request for a new tool goes to wait.
This final part is about getting the balance right: when a gateway is justified, what it should do, what it must not be trusted to do and how to keep it from becoming the bottleneck it was meant to remove.
Kwelanga Insurance is fictional, and its systems and figures are illustrative. Kwelanga's security review in Part 5 ended with an uncomfortable finding: switching off a misbehaving server meant redeploying every host that used it, which took about two hours. By then there were three hosts, Kwelanga Assist, a pilot assistant inside the broker portal and an on-call console for platform engineers, and three servers. The question was whether that justified a gateway.
What a gateway is for
An MCP gateway is a control point in front of a set of MCP servers. Done well, it offers a small number of things that are hard to do consistently anywhere else:
- An allowlist. Only approved servers, at approved versions, are reachable, and each host sees only the servers it is approved for.
- Identity and credential brokering. The gateway validates the caller's token and obtains a separate, narrowly scoped credential for each server, so no token is passed through unchanged.
- Policy and quotas per client. Rate limits, spending limits and simple rules such as "the broker portal pilot may not call any write tool".
- A kill switch. Turn off a server, or one tool on it, for every host at once, in seconds.
- One audit format. Every call recorded with the same fields and the same correlation identifier.
Most gateway products advertise these functions, and they are genuinely useful. The MCP specification, at version 2026-07-28 and checked on 14 October 2026, also makes some of them easier than they used to be. Because the protocol is now stateless, with protocol version and capabilities carried on every request, an intermediary can route each request on its own merits. The Streamable HTTP transport now requires standard headers naming the method and the tool, so a gateway or web application firewall can see which tool is being called without parsing every message body. Neither of these makes a gateway mandatory. They make one easier to build well.
What a gateway must not be trusted to do
The most important design rule is the same one this series has repeated from Part 1: a control point is not a trust boundary. The gateway is a control point, not a trust boundary makes the general argument for agent tool gateways; it applies with full force here.
A gateway can decide that the claims server is reachable from Kwelanga Assist. It cannot decide that this handler may read this claim, because it does not know the claim assignments and should not. If the gateway becomes the only place that rule is enforced, then a gateway misconfiguration, a bypass, or a developer calling the server directly removes the rule entirely.
So Kwelanga kept the division of labour strict:
| Decision | Where it lives |
|---|---|
| Which hosts may reach which servers and tools | Gateway |
| Which credential the server receives | Gateway, by token exchange |
| Rate limits, quotas, kill switch | Gateway |
| Whether this person may see or change this record | Claims server and claims platform |
| Whether this note may be added to a claim in litigation | Claims platform |
| What was confirmed by the person | Host, recorded and passed through |
The gateway made the system easier to operate. It did not make any server's own checks optional.
When a gateway earns its place
A gateway is a stage in an MCP estate's growth, not a starting point.
Stage 1: one host, a few servers. Put the controls in each server. A gateway here adds latency, a deployment and a team, and protects very little that the servers cannot protect themselves. Most organisations' first production use of MCP is at this stage, and that is fine.
Stage 2: several hosts, several servers. This is where Kwelanga was. Three hosts, three servers, and a kill switch that took two hours. A gateway pays for itself here, mainly through the allowlist, the credential brokering, the audit trail and the kill switch. Kwelanga's took about three weeks to stand up on infrastructure the platform team already ran, and cut the time to switch off a server from two hours to under a minute in testing.
Stage 3: many teams. When dozens of teams publish servers and dozens of applications consume them, a single central gateway owned by one team becomes the bottleneck. The answer at this scale is usually federated gateways, policy written as code and reviewed like code, and a central team that owns the platform rather than every approval.
Keeping the gateway from becoming the bottleneck
The bottleneck signs are recognisable in any organisation that has run central API management: every new tool waits on one team's backlog, the approval process takes longer than building the server, and one gateway outage stops every agent at once. Four practices keep them away.
Make approval a published standard, not a meeting. Kwelanga's gateway approves a new server automatically if its catalogue entry is complete, its tools are tiered, its security review is recorded and its owners have signed. The platform team reviews the exceptions, not every request.
Design for gateway failure. Decide in advance what happens when the gateway is down. For Kwelanga, read-only policy lookups fail closed and the assistant tells the handler to use the policy system directly. That is acceptable precisely because the assistant is a convenience, not the only route to the work.
Keep the gateway thin. It routes, brokers, limits, records and switches off. It does not rewrite tool descriptions, summarise results, call models or hold business rules. Every feature added to a gateway is a feature every request now depends on.
Measure it. Latency added per call, approval lead time for new servers and number of kill-switch uses per quarter. If approval lead time climbs, the gateway is becoming the bottleneck before anyone says so.
Build, buy or use what you have
Many organisations already run something that can act as an MCP gateway: an API management platform, an AI gateway in front of model providers, or a service mesh. Several now advertise MCP support, and dedicated MCP gateway products exist. Before buying, ask whether the product can enforce the division of labour in the table above, whether it supports the current specification's stateless request model and Streamable HTTP headers, how its kill switch works, and whether you can export its audit records to your own store. A gateway that only supports a previous protocol revision will hold you back, and a gateway whose audit trail you cannot take with you will make leaving expensive.
What the series adds up to
Across six parts, the argument has been consistent. MCP standardises connection, and that is valuable. Trust, authority, data sensitivity, safe tool design and ownership still have to be designed by the organisation, server by server and tool by tool. A gateway helps operate that design at scale. It does not replace it.
Kwelanga ended where a sensible organisation should: two well-designed servers in production, a third for on-call engineers behind change control, a thin gateway with a kill switch that works, and a review that runs whenever a tool or a description changes. It is less impressive than the first demo. It is also something the business can defend.
Key points
A gateway earns its place at stage 2. Several hosts and several servers make the allowlist, credential brokering, audit and kill switch worth the extra hop.
It is a control point, not a trust boundary. Record-level authority stays in the servers and the systems of record.
Keep it thin. Route, broker, limit, record and switch off. No business rules, no rewriting, no model calls.
Approval should be a published standard. Automate the common case so the gateway team reviews exceptions, not every request.
Plan for its failure. Decide in advance what fails closed, and keep the assistant from being the only route to the work.
That completes the series. Start again from Part 1, MCP in plain language, or see all parts on the series page. For identity and gateways in a Microsoft Foundry setting, see Identity before intelligence, and for the controls an operations agent needs before it changes anything, see Preventing expensive and destructive tool calls.
How CloudNala can help
We help organisations decide whether they need an MCP gateway yet, and if they do, design one that stays thin: an allowlist and approval standard, credential brokering that never passes tokens through, quotas, one audit format and a kill switch that is tested rather than assumed. We also help keep record-level authority where it belongs, in the servers and systems of record, so the gateway makes the estate easier to run without becoming its only defence.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an MCP Security Review or write to us at consult@cloudnala.co.za