MCP Gateway vs MCP Registry: Which Control Fits

An MCP registry and an MCP gateway are often bought or built as if they were the same control, but one decides which servers may be installed and the other decides what happens on every call, and each leaves gaps the other was meant to fill. This guide maps MCP risks to the control that actually stops them: catalogue approval in a registry, or in-path enforcement in a gateway. It covers what each one misses (tool poisoning and rug pulls in particular), how the two combine, who should own each, and what to build first when budget or time allows only one. It is for security architects, platform teams and AI governance leads, and links to the registry hardening and gateway architecture guides rather than repeating them. Protocol and product details were checked on 14 November 2026.

Key takeaways

Short answer: a registry governs what may be installed and from where; a gateway governs who may call which tool, with which credential, and records what happened.
A registry approves metadata, not behaviour. The official MCP Registry hosts metadata that points to packages and delegates security scanning to package registries and aggregators: a catalogue entry says nothing about runtime behaviour.
Rug pulls defeat approval-time checks. A server can pass review and later change its tool descriptions or ship a malicious version. Only something that compares what is served now with what was approved, at the gateway or in the client, catches that.
Name-based allowlists are not enforcement. Client vendors say plainly that matching on a server name or ID can be bypassed by editing configuration; enforcement has to match the URL or exact command and be delivered as managed policy.
If you can do only one first, it depends on where your servers run. Mostly local stdio servers on laptops: start with a registry plus managed client allowlists. Mostly remote servers with shared credentials: start with a gateway.

Two controls, two questions

Products sold as gateways often ship a catalogue screen, and some registries proxy calls, so define each control by the decision it makes, not by product label.

MCP registry (catalogue approval): a list of servers, versions and installation details that an organisation has approved, exposed in a format clients can read. The official MCP Registry describes itself as a metadata repository for publicly accessible servers, storing a standard server.json with the server's unique name, where to find it (for example an npm package or remote URL), execution instructions and discovery data. It is in preview, it does not accept private servers, and it recommends hosting your own private registry for them. It also publishes an OpenAPI specification that private registries can implement so host applications can read them.
MCP gateway (in-path enforcement): a broker that sits between clients and servers on every request. It authenticates the caller, filters which servers and tools that caller can see, obtains a separate credential for each downstream server, applies policy to tool calls and arguments, and logs each call. See the MCP Gateway vs Direct MCP Connections for when brokering is worth it at all.

The registry acts once per server version, before first use; the gateway acts on every call. A registry without enforcement is a recommendation list; a gateway without a registry keeps its approval list somewhere nobody reviews.

Side-by-side comparison

Dimension	MCP registry	MCP gateway
Decision it makes	Is this server, at this version, from this source, approved for use here?	May this caller invoke this tool, with these arguments, right now?
When it acts	At publication, approval and install time	On every `tools/list` and `tools/call`
What it holds	Metadata: names, versions, package identifiers, remote URLs, install arguments, review status	Session state, downstream credentials or a vault reference, policy, call records
Enforcement point	The client, through managed policy that points at or mirrors the registry	The gateway itself, plus client and egress policy to force routing
Identity role	Publisher identity: proves who published an entry (namespace verification)	Caller and agent identity: proves who is calling, and brokers the server's own credential
Evidence produced	Approval record per server version, reviewer, date, risk tier	Per call: user, agent, server, tool, arguments, result, decision
Blast radius if compromised	Poisoned catalogue: every client installs what it lists	Every brokered credential and routed session

Risk-to-control map

The table below is the core of the decision. "Primary" means the control is the right place to stop the risk; "partial" means it reduces the risk but cannot stop it alone.

MCP risk	Registry	Gateway	What closes the gap
Unapproved or shadow servers installed by users	Primary, when clients enforce it as managed policy	Partial: sees only routed traffic	Managed client allowlists matching URL and exact command; egress control
Typosquatted or impersonating server packages	Primary: pin publisher namespace, package and version	Partial: can block unknown remote hosts	Install only from the publisher's official source; version pinning
Tool poisoning in descriptions or schemas (AML.T0110)	Partial: review at approval time only	Primary: inspect and filter tool lists before they reach the model	Approved tool definition baseline, compared on every list
Rug pull after approval (AML.T0109)	Weak: approval is a point in time	Primary for remote servers: diff and hold changed tool lists	Version pinning for stdio; hash of approved tool definitions
Malicious code in a new package version	Primary: approval per version, not per name	Weak for stdio servers it does not host	Pinned versions in managed commands; sandboxing
Over-broad credentials and token passthrough	None	Primary: per-server, audience-bound credentials	Gateway token exchange; no shared static keys
Dangerous tool calls by an injected agent	None	Primary: per-tool and per-argument policy, human approval for sensitive calls	Client confirmation prompts as a second layer
Audit and investigation gaps	Partial: approval history	Primary: per-call records	Client telemetry for stdio servers
Compromised registry or gateway itself	Risk introduced	Risk introduced	Separate admin roles, signed changes, monitoring of both

The registry is strongest on supply chain questions (what, from whom, which version), the gateway on runtime questions (who, which tool, which credential). Tool poisoning and rug pulls sit across the boundary, which is why one control rarely suffices.

Threat model: the registry

The assets a registry protects are the integrity of the approved list and the link between an approved name and the code or endpoint that actually runs.

Metadata is not code: the official registry says package registries such as npm, PyPI and Docker Hub host the code and it hosts metadata pointing to them, and that it delegates security scanning to those package registries and to downstream aggregators. A private registry inherits that limit unless approval adds its own review.
Publisher identity only: namespace verification through GitHub, DNS or HTTP challenges proves who published an entry under io.github.user/server or com.example/server. It does not prove the publisher is trustworthy or that the next version is safe.
Silent upgrades: if an entry approves a name rather than a version, a new release inherits the approval. The postmark-mcp Malicious MCP Server 2025 worked as advertised for fifteen versions before version 1.0.16 added a hidden blind copy of every email; an approval tied to version 1.0.15 and a pinned install command would have held the line.
Stale status: upstream metadata is generally immutable except status, which can become deprecated or deleted (typically a moderation breach such as spam or malware). A private registry that syncs once and never again keeps serving entries the upstream has withdrawn. The aggregator guidance recommends incremental syncs with updated_since and applying deleted status changes to your local copy.
Enforcement lives in the client: a registry only constrains clients configured to obey it. Client documentation is explicit about where the strong control sits. Anthropic's Claude Code documentation warns that a serverName allowlist entry is not a security control because users choose the name, and directs administrators to serverUrl and serverCommand entries. GitHub documents a "Registry only" policy for Copilot, currently in public preview and based on server name or ID matching, and recommends a managed settings file for stricter URL-based enforcement that users cannot override locally.
The registry as a target: whoever can edit the catalogue decides what every client installs. Attached build and hosting services carry the same risk: in the Smithery.ai MCP Hosting Breach 2025, an unvalidated build path exposed a deployment token that controlled thousands of hosted MCP servers.

Threat model: the gateway

Only routed traffic is governed: a stdio server launched by a desktop client never touches a network gateway, and a remote server added directly in a client bypasses it unless client policy and egress rules force routing. See the Streamable HTTP vs stdio MCP Transport.
No opinion on provenance: without an approved list, gateway policy degrades to "anything the caller can reach".
Credential concentration: the gateway holds or mints credentials for every downstream server. The MCP security best practices forbid token passthrough (servers must not accept tokens not issued for them) and require proxy servers that act as a single OAuth client to third-party APIs to implement per-client consent, exact redirect URI matching and single-use state values. A gateway that skips these is a confused deputy by design.
Tool list trust: the tools specification says clients must treat tool annotations as untrusted unless they come from trusted servers. A gateway that passes descriptions through unchanged adds audit but no protection against poisoning.
Change notifications: servers that declare the listChanged capability should send notifications/tools/list_changed when their tools change, and clients then call tools/list again. A rug pull will not announce itself, so compare every list with the approved baseline.

What each control misses: tool poisoning and rug pulls

Tool poisoning

Tool poisoning (ATLAS AML.T0110 AI Agent Tool Poisoning) places instructions in a tool's name, description or schema so the model acts on them. A registry review can read descriptions at approval time, but most registries store server metadata, not the live tool list a server returns on tools/list, so reviewers often never see the text the model will see. A gateway can inspect the live list on every session, strip or block suspicious content, and hide tools the caller does not need, which shrinks the text that reaches the model. See MCP Tool Poisoning Detection and AML.T0110 AI Agent Tool Poisoning.

Rug pulls

A rug pull (ATLAS AML.T0109 AI Supply Chain Rug Pull) is a component that behaves well until trust is established and then changes. It comes in two forms, and each control catches a different one.

Package rug pull: a new version of a local server ships malicious code. The registry stops it if approval is per version and clients run pinned commands; the gateway cannot see it if the server runs over stdio on the endpoint.
Definition rug pull: a remote server changes its tool descriptions or adds tools without a version change visible to anyone. The registry cannot see it at all; the gateway catches it if it fingerprints each approved tool definition and holds changes for review.

The practical defence is to record, at approval, a fingerprint of each tool's name, description and input schema alongside the version in the registry entry, and have the gateway (or, for stdio, a client-side scanner) compare what is served against that fingerprint. That turns two separate controls into one approval that is enforced continuously. See MITRE ATLAS AML.T0109 AI Supply Chain Rug Pull.

How the two combine

In a mature design the registry is the source of truth and the gateway and clients are enforcement points that read from it.

Approval writes the registry: a review produces an entry with publisher namespace, package and pinned version (or remote URL), install command, risk tier, allowed caller groups, approved tool list and tool definition fingerprints. See the MCP Server Trust Assessment.
Clients read managed policy derived from the registry: for local servers, managed allowlists that match the exact command, including the pinned version; for remote servers, URL patterns. Clients are listed alphabetically: in Claude Code, allowedMcpServers with serverCommand and serverUrl entries plus allowManagedMcpServersOnly: true make the managed list authoritative; in GitHub Copilot, an organisation or enterprise registry URL with the "Registry only" policy, alongside the managed settings file GitHub recommends for URL-based enforcement.
The gateway reads the registry: it exposes only approved servers and tools to each caller group, compares live tool lists to the fingerprints, and brokers each server's credential.
Telemetry flows back: call records show which servers are used, attempted or ready to retire.

Products that combine registry and proxy collapse steps 1 and 3; check that approval and gateway policy are separately permissioned.

Decision criteria: which first

No standard prescribes an order; the factors below are practitioner judgement.

Factor	Start with the registry	Start with the gateway
Where servers run	Mostly local stdio servers on developer machines	Mostly remote servers, internal or SaaS
Main exposure	Unvetted packages, typosquats, silent upgrades	Shared API keys and service credentials used by agents
Agent type	Interactive assistants in IDEs and desktop apps	Autonomous agents in pipelines and back-end services
Audit pressure	Need to show what is approved and installed	Need to show who did what through which tool
Existing tooling	Device management can already push client policy	An API gateway or identity proxy team can run another tier 0 service
Scale	Tens of servers, hundreds of users	Many agents sharing a smaller set of high-value servers

Small organisations: a short, version-pinned list pushed as managed client policy is often enough until shared credentials appear.
Large organisations: run both with separate owners; each alone leaves either autonomous agents or stdio servers ungoverned.

Ownership and operating model

Activity	Accountable	Responsible	Evidence
Approval policy and risk tiers	CISO or AI governance board	Security architecture	Published criteria, exceptions register
Server reviews and registry entries	AI governance lead	Platform engineering with security review	Entry per version with reviewer and date
Client managed policy	Endpoint engineering	Device management team	Policy deployment reports per device group
Gateway operation and credentials	Identity or platform engineering	Gateway service team	Change records, credential inventory, uptime
Detection and response	SOC manager	Detection engineering	Alerts on blocked servers, definition changes, policy denials

Treat gateway downstream credentials as non-human identities with owners and rotation. The MCP Server Inventory Template gives a starting record structure.

Worked scenario

A software company has 400 developers using two IDE assistants, plus a support automation agent in production that calls a ticketing MCP server and a CRM MCP server.

Finding: 70 distinct local servers, eleven unpinned npx commands, and a static CRM API key in the support agent's environment.
Registry first for developers: security approves 18 servers, each with a pinned package version and command. Device management pushes managed allowlists matching the exact commands, with the managed-only switch on.
Gateway first for the production agent: the support agent is moved behind a gateway that authenticates it with a workload identity, exposes only four approved tools from each server, holds the CRM credential in a vault and requires human approval for the delete and export tools.
The rug pull that follows: months later the CRM server adds a tool and rewrites a description. The gateway holds the changed list for review while the approved set keeps working. When an approved local server publishes a new version, pinned commands keep the old one until registry entry and policy are updated together.

Implementation path

Inventory: list every MCP server in client configurations and agent deployments, with transport, version and credential type. See How to audit MCP servers on developer laptops.
Define approval criteria: publisher, pinned version, credential model, data access, tool risk.
Stand up the registry: implement the official registry OpenAPI interface (the official codebase is not designed for self-hosting) or use a product that does, so host applications can read it. Record version, command or URL, and tool fingerprints.
Pilot client policy in audit mode: where clients support it, report rather than block for two weeks; compare against the inventory; fix false blocks.
Enforce for one device group, then widen: keep the previous policy version ready to redeploy as the rollback path.
Introduce the gateway for remote and production servers: start with read-only tools, then broker credentials, then turn on definition change holds.
Close bypasses: egress rules that force production agents through the gateway.

Detection and measurement

Log: registry approvals, edits and status changes; client policy denials; gateway tools/list results that differ from the fingerprint; denied tool calls; credential issuance per downstream server.
Coverage: percentage of servers in use that have a registry entry with a pinned version (target 100 per cent).
Enforcement: percentage of managed devices reporting the current MCP policy version.
Routing: percentage of production agent MCP calls that pass through the gateway.
Drift: number of tool definition changes held per month, and median time to review them.
Hygiene: registry entries upstream-marked deprecated or deleted still approved locally (target zero).

Common failure patterns

Approving names, not versions: a new release inherits trust automatically, which is exactly how a package rug pull lands.
Treating a recommendation list as enforcement: a wiki page or name-matched allowlist that users can override by editing their configuration.
A gateway that passes tool lists through: a fully audited poisoned conversation is still poisoned.
Repository-defined servers left out of scope: in the Amazon Q MCP Config Vulnerability 2026, researchers reported that MCP servers defined in a repository's configuration file could start when the folder was opened and inherit the developer's environment, including cloud credentials; the vendor fixed it and added a consent prompt for untrusted MCP servers. Client policy must cover project-level configuration, not only user settings.
One team holding both keys: the same administrators approving servers and editing gateway policy, with no second review.
Sync once, trust forever: a private registry mirrored from an upstream catalogue that never applies upstream deletions.

Framework mapping

Framework	Registry	Gateway
NIST CSF 2.0	ID.AM-02 software and services inventory; GV.SC-07 supplier risk; PR.PS-02 software maintained and removed	PR.AA-05 access permissions enforced; DE.CM-09 runtime monitoring
NIST SP 800-53 Rev 5	CM-7 Least Functionality; CM-8 System Component Inventory; CM-11 User-installed Software; SR-3, SR-4 Provenance; SR-11 Component Authenticity	AC-3 Access Enforcement; AC-4 Information Flow Enforcement; AU-2, AU-12 event logging; IA-9 Service Identification and Authentication; SI-7 integrity checking of tool definitions
CIS Controls v8.1	Control 2 Inventory and Control of Software Assets (2.5 allowlist authorised software)	Control 6 Access Control Management; Control 8 Audit Log Management
ISO/IEC 27001:2022 Annex A	A.5.9 inventory of assets; A.5.19 supplier relationships; A.8.19 installation of software	A.8.3 information access restriction; A.8.15 logging; A.8.16 monitoring activities
MITRE ATLAS and ATT&CK	T1195.002 Compromise Software Supply Chain; AML.T0109 AI Supply Chain Rug Pull	AML.T0110 AI Agent Tool Poisoning; AML.T0115.002 AI Agent Tools

Practitioner checklist

Write down which MCP risks the registry owns and which the gateway owns, using the risk-to-control map.
Approve every server per version, with publisher namespace, package or URL, and exact install command.
Store a fingerprint of each approved tool definition with the registry entry.
Enforce client allowlists by URL and exact command, delivered as managed policy with the managed-only switch on.
Route production and remote MCP traffic through a gateway that brokers per-server credentials and never passes tokens through.
Have the gateway compare every tool list with the approved fingerprint and hold changes for review.
Sync upstream registry status changes and retire deleted or deprecated entries.
Track coverage, enforcement, routing, drift and hygiene metrics monthly.

MCP Gateway vs MCP Registry: Which Control Stops Which MCP Risk