The official MCP registry lists tens of thousands of servers. Your company needs about twelve. The gap between those two numbers is where most MCP security problems live, and the tool that closes it has a dull name: a private registry, which is to say an allow-list of servers your organisation has decided to trust, enforced somewhere that matters.

Here is what one actually is, what it needs to contain, and why it beats the alternative every security team reaches for first.

The default: everyone picks their own

Without a private registry, every employee’s AI client is its own registry. They find a server in a blog post, paste the URL into Claude or Cursor, approve an OAuth screen and start calling tools. Multiply by a team and you get shadow MCP: dozens of servers in use, nobody knows which, and each one is a data flow nobody assessed.

The natural first reaction is a blocklist. Ban the obviously bad ones. The trouble is that the set of MCP servers is open-ended and grows daily, a blocklist can only name what you already know about, and the risky servers are rarely the famous ones. Blocklists work for malware signatures. They don’t work for an ecosystem where anyone can publish an endpoint in an afternoon.

What a private registry is

An allow-list, maintained by the organisation, of MCP servers that AI clients may connect to. Three properties separate a real one from a wiki page:

  • It is enforced. A client cannot reach a server that is not on the list, because the only endpoint the client knows is the gateway, and the gateway only forwards to registered servers.
  • It records why. Each entry says who approved it, when, what it was scanned for, and which teams may use it.
  • It is pinned. The tool definitions that were approved are stored, so a server that changes its tools after approval is noticed rather than silently trusted. That is drift detection, and a registry without it is a snapshot that goes stale on day two.

What each entry should carry

You can get far with a short record per server. Treat it as the thing you would hand an auditor when they ask “why does your AI talk to this?”

  1. Identity. The exact endpoint URL and who operates it. Verify the operator; a lookalike domain hosting a copy of a vendor’s server is a known pattern.
  2. Auth model. OAuth with which scopes, an API key, or nothing. Scopes are part of the approval, not a detail.
  3. Scan result. The tool list at approval time and what a security scan found: injection patterns, cross-tool references, destructive tools without annotations.
  4. Data classification. Does any tool return personal data, financial data, health data, source code? This drives which teams get it and whether tools need approval steps.
  5. Audience. Which teams or roles can connect it, and with which per-tool rules.
  6. Owner and review date. Someone is responsible, and the entry is re-checked on a schedule.

Public registries are inputs, not approvals

The official registry, vendor directories, and curated lists like gate’s directory are where you find candidates. Listing there means a server exists and, at best, that someone probed it and graded its tool descriptions. It does not mean your organisation has assessed it. The private registry is where a candidate becomes an approval, with your scopes, your audience, your data classification attached.

One useful habit: when a public listing shows a security grade, treat it as a reason to look, not a reason to approve. A grade is about the server’s tool definitions. It says nothing about whether your finance team should be able to call it.

The request path

An allow-list that people have to go around is an allow-list people will go around. The registry needs a request flow that is faster than pasting a URL into a config file:

  • An employee finds a server and submits it with one click, including what they want it for.
  • The server is scanned automatically and the result is attached to the request.
  • An approver sees the scan, the scopes and the data classification on one screen and decides.
  • On approval the server appears in the requester’s client without further setup, scoped to their team.

If that round-trip takes a day, people use it. If it takes a week, they don’t, and you are back to shadow MCP with a policy document on top.

Why this is the gateway’s job

You can keep an allow-list in a spreadsheet, but you cannot enforce one there. Enforcement needs a chokepoint: one endpoint that every AI client connects to, which knows the list and refuses everything else. That chokepoint is an MCP gateway, and the registry is the gateway’s configuration seen from the governance side.

It also makes the registry self-maintaining in the way that matters most. Because every call passes through the same place, the gateway can re-fetch each server’s tool list, diff it against the approved snapshot, and flag changes. The spreadsheet can’t.

How gate does this: in gate, the servers a workspace has connected are the private registry. Each one is scanned before it goes live, its tool list is stored and re-checked for drift, and admins decide which teams can reach it and with which per-tool allow, ask, or block rules. Members see only the servers and tools they are cleared for, through one gateway URL. Candidates come from the public directory or any URL; approval is a workspace decision, not a config file.

Getting started

  1. Inventory what is already connected across your team’s clients. Expect surprises.
  2. Scan each server and record the result. Drop the ones nobody can explain.
  3. Put the survivors behind one gateway endpoint and point every client at it.
  4. Assign each server an owner, an audience, and a review date.
  5. Publish the request path and make it fast.

A blocklist tells you what you’re afraid of. An allow-list tells you what you trust and why. Only one of those scales with the ecosystem.