10 May 2026 AI Engineering 5 min read

MCP at Enterprise Scale: Registry and Gateways

The official MCP Registry made servers discoverable and Streamable HTTP with OAuth 2.1 made them remote. Together they produced a gateway market for centralised authentication, tool-level authorisation and audit. This article covers what the registry guarantees, why the protocol invites interception, which risks a gateway does not close, and what a minimal enterprise rollout looks like.

Why MCP became an infrastructure problem

MCP began as a local integration format. A client spawned a server over stdio and inherited whatever capabilities it offered. That model does not survive contact with an organisation. Once a few hundred developers connect a few dozen servers to production systems, the question is no longer how a tool is described. It is who may call it, under whose identity, and where the record of that call ends up.

Two developments turned this into an infrastructure question rather than a client question: a public registry that made servers discoverable at scale, and a remote transport with a mandatory authorization model. The gateway market that formed over 2025 and 2026 follows directly from both developments.

An agent reaches its tools over MCP — one standard surface. 1/4

What the official registry actually guarantees

The official MCP Registry went live in preview on 8 September 2025 at registry.modelcontextprotocol.io, built by maintainers from Anthropic, GitHub, Microsoft, Block and PulseMCP. Servers are described in a server.json schema: a reverse-DNS name such as io.github.user/server, the package or remote endpoint that hosts it, and configuration hints. Namespaces are proven by GitHub account, DNS record or HTTP challenge. An independent pull of the API on 11 March 2026 counted 3,012 unique servers across 8,074 version records.

The guarantee is narrower than most readers assume. The registry authenticates namespaces and hosts metadata. It delegates code scanning to npm, PyPI and Docker Hub and to downstream aggregators. It refuses private servers by design and points operators at self-hosted registries that implement the same OpenAPI interface. It is a naming system, not a trust store. Eight months after launch it is still labelled preview.

Remote servers and OAuth 2.1 by default

Streamable HTTP arrived with specification revision 2025-03-26 and replaced the older HTTP-plus-SSE pairing. The authorization chapter, revised again on 25 November 2025, states the shape plainly. A protected MCP server is an OAuth 2.1 resource server. It must publish Protected Resource Metadata under RFC 9728, answer unauthenticated calls with 401 and a WWW-Authenticate header, and validate that every bearer token names it in the audience.

Clients must send the RFC 8707 resource parameter in both authorization and token requests and must use PKCE with S256. Token passthrough is forbidden outright: a server must not accept a token issued for something else, and must not forward the client's token to an upstream API. The November revision also prefers Client ID Metadata Documents over dynamic client registration, which is now retained mainly for backwards compatibility.

Adoption lags the specification. In the March 2026 sample of the registry, roughly one third of servers exposed a remote endpoint, only 8.5 per cent used OAuth at all, and 53 per cent relied on long-lived static secrets. The default deployment on paper and the median deployment in the field are still two different things.

Why the protocol invites a gateway

Three properties make interception natural. The transport is ordinary HTTP carrying a bearer token, so a reverse proxy already sees every call. Capabilities are discovered at runtime through tools/list, so a proxy can present a filtered catalogue without either side noticing. And resource identity is a URL, so one endpoint can stand in front of many servers and still be a valid OAuth audience.

That is the whole architectural basis of the gateway market. A gateway terminates the client's OAuth flow against the corporate identity provider, holds its own upstream credentials, and re-exposes a curated tool set under one canonical URI. Nothing in the specification forbids this. The rule against token passthrough arguably requires it, because the boundary between client credential and upstream credential has to exist somewhere.

What a gateway does and what it does not

By early 2026 the feature set had converged across open-source and commercial products. Four functions recur: a single OAuth 2.1 front door bound to enterprise SSO, authorisation at the level of the individual tool rather than the server, an audit record per tool call carrying caller identity and arguments, and network-side detection of MCP endpoints nobody registered.

The honest reading is the right-hand column. A gateway is an identity and policy layer. It does not interpret what a tool returns, and it does not make an untrusted server trustworthy. It also adds a single point of failure and a hop that every latency budget has to absorb.

Concern	Enforceable at the gateway	Stays somewhere else
Caller identity	OAuth 2.1 against the corporate IdP	Session binding inside the server
Tool authorisation	Allow or deny per tool and role	Argument-level checks inside the tool
Credentials	Upstream secrets never reach the client	Rotation at the target system
Audit	One record per tool call	Correlation with target system logs
Tool output	Size and pattern filters only	Trust decision by model and client

Risks that outlive the control plane

Three risks are canonical and none of them is closed by centralisation. Prompt injection through tool results comes first. A tool description or a returned document can carry instructions, and the model reads both as context. OWASP lists this as MCP03:2025 Tool Poisoning; public proof-of-concept attacks have existed since April 2025. A gateway can log the payload. It cannot decide what the model should ignore.

Token theft is second. Centralising credentials concentrates value: a compromised gateway is a compromised estate, and short token lifetimes matter more here than anywhere else. Over-scoped permissions are third. The specification's own guidance names wildcard and omnibus scopes as a common mistake and asks for incremental elevation through insufficient_scope challenges. Most deployments still grant the full catalogue once, at connect time, and never revisit it.

A minimal enterprise rollout

We deploy this in four steps and resist adding a fifth. Start with inventory. Scan egress for MCP endpoints before writing any policy, because the unsanctioned estate is usually larger than the sanctioned one. A February 2026 survey of 750 technology leaders in the US and UK found 47 per cent of roughly three million deployed agents were not actively monitored, and 88 per cent had seen or suspected an agent-related incident in the previous twelve months.

Then one ingress: every client speaks to a single gateway URL and to nothing else. Then a deny-by-default tool catalogue mapped to roles that already exist, opened per tool rather than per server. Then one audit stream carrying caller, tool, arguments and outcome into the same SIEM as the rest of the estate. Keep human approval for write operations where the blast radius is real.

Where this goes next

The registry is still in preview, so mirror it rather than depend on it. Pin versions, verify namespaces, keep an internal catalogue that survives an upstream data reset. We expect the interesting work of the next year to move from access to provenance: signed server metadata, attestation of the package behind a registry entry, and policy that reads the attestation instead of a hostname.

The second shift is measurement. Deny-by-default is easy to write and hard to keep accurate as catalogues grow. Organisations that record which tools are actually called, by whom and with what outcome will be able to shrink their scopes with evidence. Those that do not will keep the wildcard and call it governance.