Should organisations use gateways or registries to control MCP access?

Why a Gateway Is the Security Boundary for MCP Access

For MCP, the security boundary has to be the component that can actually stop, shape, and record a request. A gateway can enforce authorisation, apply policy, proxy calls, and preserve evidence. That makes it the control point for access decisions, not just a routing layer. Registries help people and tools find servers, but discovery alone does not create enforcement.

That distinction matters because access control is only meaningful when the control can deny or constrain the call before the tool executes. If the boundary cannot enforce policy in-line, then it is administrative metadata, not security control. For that reason, organisations should treat registries as discovery infrastructure and gateways as the place where MCP usage is governed.

What Registries Are Good For, and Where They Fall Short

A registry answers the question, "What is available?" It can curate endpoints, list capabilities, and support lifecycle management for published MCP services. That is useful for platform hygiene, developer experience, and standardisation. It is not, by itself, a trust boundary, because a registry usually does not sit in the request path or adjudicate the call that follows discovery.

Using a registry as if it were an enforcement layer creates a false sense of control. A server can be listed in a registry and still be reached through another path, or used with weaker checks elsewhere. A proper access model separates discovery from decision-making, so that the publication mechanism cannot be confused with the authorisation mechanism.

How to Design MCP Control So Policy and Audit Stay Intact

The practical model is to let the registry advertise approved services and let the gateway enforce who can use them, under what conditions, and with which scopes or tokens. That gives teams a clean separation between service curation and runtime control. It also keeps audit evidence attached to the actual request path, which is critical when you need to reconstruct who accessed which tool and why.

This is especially important when MCP tools can reach sensitive systems, data, or downstream automation. A gateway can centralise checks for allowlists, token audience, request context, and rate or scope restrictions. A registry cannot reliably do those things unless it is also in the traffic path and able to deny the request.

Risk and Threat Considerations

If organisations treat a registry as the security boundary, they create a control gap between discovery and execution. An attacker, or even a misconfigured client, can use that gap to reach a server through an uncontrolled path, or to invoke a tool with broader access than intended.

Failure mechanism: Discovery systems expose metadata, but they do not stop the request that follows, so policy, token audience checks, and audit capture can be bypassed or fragmented.

Impact: The result is overbroad access, weaker accountability, and a higher chance of tool misuse, confused-deputy behaviour, or silent exposure of sensitive operations.

Practitioner Guidance

What to prioritise: Put the enforcement decision at the gateway, not in the registry, and require every MCP client path to pass through that control point if the server can affect production systems or sensitive data.

What to verify: Confirm that the gateway can deny requests before execution, bind access to the correct audience and identity, and log enough context to explain the decision after the fact.

Common mistake: Treating a catalogue of approved servers as equivalent to authorisation. Approval to discover a service is not approval to use it.

Practitioner takeaway: Use registries to publish and find MCP services, but use gateways to decide and prove access, because only the enforcement layer can make policy real.

Related resources from NHI Mgmt Group

• Should security teams use API gateways alone to control MCP access?
• Should organisations use MCP server consent prompts as their access control model?
• How should organisations use AI agents in access reviews without losing governance control?
• How should organisations use AI in access request approval without weakening control?