Your MCP Server Probably Trusts Every Agent. Here Is Where to Fix That.

A practical look at MCP gateways for UK teams: what to enforce on every tool call, and what to ask vendors before you sign

The Model Context Protocol makes it trivial to hand an agent a new tool. Point a client at a server, call tools/list, and the agent can start invoking whatever comes back. That is great for prototyping. It is less great when the tool is crm.export_customers and nobody can say afterwards which agent called it, with whose credentials, or why.

Here is the uncomfortable detail. The current MCP authorization spec opens with "Authorization is OPTIONAL for MCP implementations." When you do implement it over HTTP, the spec is solid. It builds on OAuth 2.1, requires resource indicators (RFC 8707) so tokens are bound to a specific server, and forbids servers from accepting or passing through tokens issued for someone else. But optional means plenty of servers in the wild ship without it, and even a well-built server only knows about itself. It has no view of your other 40 servers, your agent inventory, or your audit requirements.

That gap is what an MCP gateway fills.

What a gateway actually does

An MCP gateway is a proxy that sits between agents and MCP servers and brokers every JSON-RPC call. Think of it less as an API gateway with a new protocol bolted on and more as a policy enforcement point that understands tools. Concretely, it should handle four jobs.

Identity. Every agent gets its own credential, not a shared service account. The gateway authenticates the agent, ideally carries the end user's identity through as well, and exchanges tokens so the downstream server only ever sees a token minted for it.

Per-tool authorization. Access is decided at the level of individual tools, not whole servers. A support agent might read and update tickets but never bulk export. The gateway can also filter tools/list responses so an agent never discovers tools it is not allowed to call, which removes a lot of prompt injection surface for free.

Audit. Every call is logged with agent, user, tool, a fingerprint of the arguments, and the decision. Logs go to your SIEM, not just a vendor dashboard.

A catalogue of approved servers. Agents can only reach servers you have vetted. This is your defence against shadow servers and supply chain surprises.

Here is the shape of the core check, stripped down:

import hashlib, json, time

POLICY = {
    "support-agent": {
        "crm.read_ticket": "allow",
        "crm.update_ticket": "allow",
        "crm.export_customers": "deny",
    },
}

def authorize_tool_call(agent_id: str, request: dict, audit_log) -> bool:
    # request is a JSON-RPC message, e.g.
    # {"jsonrpc": "2.0", "id": 7, "method": "tools/call",
    #  "params": {"name": "crm.update_ticket", "arguments": {...}}}
    tool = request["params"]["name"]
    args = request["params"].get("arguments", {})

    decision = POLICY.get(agent_id, {}).get(tool, "deny")  # unknown means deny

    audit_log.write({
        "ts": time.time(),
        "agent": agent_id,
        "tool": tool,
        "args_sha256": hashlib.sha256(
            json.dumps(args, sort_keys=True).encode()
        ).hexdigest(),
        "decision": decision,
    })
    return decision == "allow"

Production gateways add a lot on top (token exchange, rate limits, content inspection of tool results), but if a product cannot do the equivalent of this check on every single call, it is not governing anything.

Why this is not theoretical

Two incidents from 2025 show the failure modes a gateway is meant to contain.

In June 2025, Asana took its MCP server offline after discovering a logic flaw that let one organisation's data appear to other organisations' MCP users. According to BleepingComputer's report, Asana said roughly 1,000 customers were affected. Tenant isolation is exactly the kind of property you want enforced, and logged, outside the server too.

In September 2025, researchers found postmark-mcp, an npm package impersonating a legitimate Postmark email server. Version 1.0.16 added a single line that BCC'd every outgoing email to an attacker-controlled address. It had been downloaded 1,643 times when it was reported. An approved-server catalogue would have stopped agents from ever loading it.

The client side is exposed too. CVE-2025-6514 in mcp-remote (CVSS 9.6, fixed in 0.1.16) let a malicious server trigger OS command execution on the client during the authorization handshake, as The Hacker News covered. Restricting which servers agents can connect to shrinks that blast radius as well.

If you want a broader map of these threat categories, from tool abuse to memory poisoning, AgentSecurity collects guides and research on securing autonomous agents.

The UK angle

No UK law or official guidance tells you to deploy an MCP gateway. What it does is describe controls that a gateway happens to be a good place to enforce.

The NCSC's agentic AI guidance, published on 20 August 2026, does not mention MCP at all. It does say that every agent should have its own unique identity with short-lived credentials, that network traffic should be denied by default and allowlisted, that agent activity should be monitored like user activity with logs that are immutable where possible, and that you should always be able to "pull the plug". Map those onto the four gateway jobs above and the overlap is almost one to one.

For financial services, the FCA's PS26/2 takes effect on 18 March 2027. In-scope firms will need to keep a register of material third party arrangements and submit it annually. If an MCP gateway or a hosted MCP server becomes part of how you deliver an important service, expect it to land in that register, which makes "where does this thing run and who are its sub-processors" a compliance question, not just an architecture one.

Picking a gateway

NeuralTrust's comparison of MCP gateways for UK enterprise reviews five options (Azure API Management, Cloudflare MCP server portals, Kong AI Gateway, NeuralTrust TrustGate and Solo.io agentgateway) against identity, per-tool permissions, audit export, deployment model and documented UK locations. The most useful finding for engineers is how uneven the location story is. Some vendors list UK regions for parts of the stack, others document none, and in several cases it was unclear whether the MCP features specifically run in the UK region or whether logs stay there.

The practical rule is to pick based on your existing estate (Entra shops, Kong users and Kubernetes teams each have an obvious starting point), then verify. Before signing, get written answers to:

1. Which region runs the data plane that handles MCP traffic?
2. Where are logs and traces stored, and for how long?
3. Where does the control plane live, and who are the sub-processors?
4. How are per-tool permissions modelled, and can tools/list be filtered per agent?
5. What is the SIEM export path and format?
6. Can it run self-hosted, in a VPC or air-gapped if residency demands it?

That last question matters more than it looks. If managed hosting is not in the UK, self-hosting is often the only way to keep MCP traffic and logs on UK soil. TrustGate, for example, offers SaaS, hybrid (managed control plane with a privately hosted data plane) and fully on-prem deployment, so the residency decision stays with you.

One more thing to weigh. Most gateways decide whether a call is allowed. Fewer look at what is inside it, such as injected instructions in a tool result or sensitive data in arguments. NeuralTrust's broader roundup of MCP gateways argues this access-versus-content split is where products differ most, and it is worth testing in your proof of concept rather than taking on trust.

The short version

The MCP spec gives you good authorization primitives but does not force anyone to use them. A gateway enforces identity, deny-by-default per-tool policy and audit on every call, across every server. In the UK, NCSC guidance and incoming FCA rules make those controls easier to justify, and data residency makes "where does it actually run" the question to ask first.