TL;DR
- MCP servers outside the registry are servers your agents use that no approved catalog lists: hand-added config entries, extension-added servers, pasted URLs and tools in agent code.
- Many are legitimate. The official MCP Registry doesn’t accept private servers, so every internal server starts outside it.
- The risk is what they skip: code review, authentication, an audit trail and anyone knowing they exist.
- A registry is a list, not a lock. Client allowlists help, but only in clients that enforce them, and never for pipeline agents.
- The fix is layered: find them, catalog the keepers, enforce at the client and route every tool call through one checkpoint you control.
Meera, a platform lead at a mid-size insurer, spent a quarter doing MCP properly. She stood up a private MCP registry, approved fourteen servers and set the company’s IDE policy to registry-only. Then the CISO forwarded an audit question: list every MCP server our agents can reach, and who approved each one.
The registry said fourteen. Developer config files, a code-review extension, two agents in the claims pipeline and a server added for a demo pushed the real number past thirty.
Each was a sensible shortcut. Together, they’re MCP servers outside the registry, and they decide what your agents can actually reach. (Meera is a composite; the patterns are real.)
What are MCP servers outside the registry?
MCP servers outside the registry are Model Context Protocol servers that AI agents or assistants connect to without being listed in an approved catalog. They’re configured by hand, added by extensions, pasted in as remote URLs or hardcoded into agents, so they skip the discovery, review and policy checks a registry provides.
The number only grows. Gartner predicts that by 2028 an average global Fortune 500 enterprise will have over 150,000 agents in use, up from less than 15 in 2025.
How MCP servers outside the registry connect
A registry is one way to find a server, not the only way to connect to one.
Manual configuration
A user adds an entry to their AI client’s JSON settings file or runs a CLI “add” command, and the client starts whatever the entry describes. Clients that offer one-click setup must show the exact command and get explicit consent before running it. That’s consent, not review. Extensions and pipeline agents skip the step entirely.
Local and remote transports
The MCP specification defines two standard transports. With stdio, the client launches the server as a subprocess on the user’s machine. The project’s local server security guide is plain about what that means: it’s an ordinary operating system process with all the access that implies. With Streamable HTTP, the server runs independently and serves many clients at a URL. It replaced the older HTTP+SSE transport.
Either way, no catalog sits in the path.
When an unregistered MCP server is fine
Being outside the registry is often normal:
- Internal tools. Teams build servers for internal APIs, private databases and file shares. The official MCP Registry says it doesn’t support private servers and recommends hosting your own registry for them.
- Local development. Engineers run experimental servers while building tools.
- Private catalogs. Many enterprises skip the public registry and run their own catalog or a subregistry that adds company policy.
The test: someone owns it, it’s written down and its calls are checked. Half of Meera’s extras passed once she catalogued them. The other half worried her.
Why shadow MCP servers are a risk
The ones that fail that test are shadow MCP servers. The OWASP MCP Top 10, still in beta, files them as MCP09: unapproved or unsupervised MCP deployments that operate outside formal security governance, much like shadow IT. OWASP notes that each one adds an unmonitored endpoint to your attack surface.
Unverified code
A local server is code running with the user’s access. In September 2025, a malicious npm package impersonated Postmark, an email delivery company, and a later version secretly copied users’ emails to an outside address. Postmark said it had nothing to do with the package and hadn’t published its own MCP server on npm.
Weak authentication
Demo servers often skip proper OAuth or scopes, and the danger runs both ways. In CVE-2025-6514, rated 9.6 (critical) by the organization that reported it, the mcp-remote connection tool was open to OS command injection when it connected to an untrusted MCP server.
No approval, no trail
A public bug report on one AI coding assistant says IDE extensions can register MCP servers missing from the organization’s private registry, and that admins have no reliable way to prevent or audit it. Nobody signs off, and nothing records it.
Drift
Servers gain tools, versions float and old entries never leave, so “what can this agent touch?” stops having an answer.
What worried Meera most was a hackathon “notes” server: still connected, unauthenticated and holding a token to the claims database.
Why an MCP registry can’t block unapproved servers on its own
A registry is a list, not a lock. It can’t stop a client that doesn’t check, a server it has never seen or a listed server that later turns bad.
Enforcement lives in each client. Some IDEs let admins set MCP access to registry-only. One major vendor’s documentation says that mode matches servers only by name or ID, which editing a configuration file can bypass. Its newer enterprise allowlists can also match a server’s URL or exact command, which is a real step up. But every client policy covers only the clients that enforce it, and none reaches agents running in pipelines.
Listed isn’t vetted. The official registry uses namespace authentication to confirm where a server comes from. It leaves security scanning to package registries such as npm and PyPI. As the MCP project’s own guide puts it, a listing on a registry is not an endorsement.
The registry sees servers, not calls. Approving a server says nothing about the next call or its arguments.
| MCP registry | Client allowlist | Checkpoint in the call path | |
| Question it answers | Which servers are approved? | Can this client start this server? | Should this call happen right now? |
| Servers it doesn’t list | Can’t stop them | Blocks them in clients that enforce it | Not a permitted destination |
| Agents outside the IDE | Not covered | Not covered | Covered, if traffic goes through it |
| Per-call identity, policy and log | No | No | Yes |
A registry on its own is a guest list with nobody on the door. Meera had built a very good guest list.
How to find MCP servers outside the registry
Compare four sources against your registry:
- Client config files: MCP settings and CLI-registered servers on managed laptops.
- Installed extensions: IDE plugins that ship or register their own servers.
- Code and pipelines: MCP SDK imports and hardcoded server URLs in repos, notebooks and CI. This is where unregistered agents tend to hide.
- Network traffic: Egress and DNS logs showing calls to MCP endpoints that aren’t on your list.
Start with read-only, so the first pass changes nothing it touches.
But any inventory is a snapshot. Finding servers doesn’t stop next week’s pasted URL.
Find the shadow agents behind your MCP servers: MCP servers are only part of the picture. Our white paper, The Shadow Agent Crisis, shows how to find agents across clouds, Kubernetes and developer laptops, including MCP config files and IDE extensions, and how to bring each one under a registry, an identity and an enforcement point. Get the white paper →
How to govern MCP servers outside the registry
Steps one to three shrink the shadow; four and five stop what’s left acting unchecked.
- Register, replace or retire. Catalog internal servers, swap in official servers where they exist and retire the rest.
- Pin and own. Pin versions, name an owner and re-review whenever a server’s tools change.
- Prefer remote over local. The same vendor’s changelog says remote servers are validated by name and install URL, while local servers are validated by name only.
- Enforce at the client. Use allowlists that match a server’s URL or exact command, plus deny lists, wherever your clients support them.
- Put one checkpoint in the call path. Route agent tool traffic through an agent gateway or control plane that checks identity and policy on every call, lets only approved destinations through and logs each decision.
Step five is the hardest at scale, and the only layer that doesn’t depend on a client checking.
How Lyzr Opencontroller closes the last gap
Every layer so far leaves a gap: the registry is a list, client policies cover one client at a time and discovery is a snapshot. Every governed agent call passes through the call path. That’s where Lyzr Opencontroller sits.
Opencontroller is a control plane for AI agents. Per its architecture page, every governed action can be authenticated, authorized, budgeted and checked before it reaches a model, tool or enterprise system. Agents stay where they run; you change an endpoint, not your application.
Opencontroller isn’t an MCP registry and doesn’t replace one. A registry tells you a server exists; Opencontroller decides what happens when an agent calls it. Its posture checks even include a critical supply-chain policy named “MCP servers outside the registry,” which you can set to alert or enforce.
| The gap | How Opencontroller handles it |
| Nobody knows which agents exist | Finds every AI agent across your clouds, starting with read-only discovery |
| Servers nobody approved | MCP servers are registered explicitly: you define the endpoints, and the control plane never assumes |
| A server outside the list gets called | Model and tool calls go only to destinations you explicitly authorize |
| No per-call decision | Every agent signs in with workload identity from your identity provider, and each MCP tool can be set to allow, approve or block |
| A risky call | Controls can refuse, mask or redirect it before the action completes |
| No trail | Each call leaves evidence: trace, outcome, cost and verdict |
Explicit by design. Opencontroller discovers MCP servers through explicit configuration, not network scanning. That’s the right default here: the approved set is the one you wrote down, and anything else isn’t a destination an agent can reach through the front door.
It runs inside your boundary. Deploy in your VPC, on-prem or air-gapped; control-plane data, credentials and telemetry never need to reach Lyzr. For laptops, Lyzr’s Basecode extends visibility and policy to supported developer devices and coding agents.
Back to Meera. The claims agent’s next call to the hackathon notes server is refused, because that server isn’t a permitted destination, and the attempt is logged under the agent’s name and owner. Thirty-odd servers become one list for the CISO.
Book a demo to see how Opencontroller governs your agents’ tool calls.
Frequently asked questions
They’re MCP servers agents connect to without being listed in an approved catalog: hand-added config entries, extension-added servers, remote URLs and tools hardcoded into agents.
Not always. Internal servers start outside the official registry because it doesn’t accept private ones. The risk is skipped review, authentication and audit.
Add an entry to your AI client’s JSON settings file or use its CLI. Local servers run over stdio as a subprocess; remote ones connect over Streamable HTTP.
No. It authenticates namespaces and stores metadata, leaving security scanning to package registries such as npm and PyPI, and to subregistries.
Use client allowlists that match a server’s URL or exact command, and route agent traffic through a checkpoint that only permits approved destinations.
Check client configs, extensions, repos, pipelines and egress logs, then compare the results with your registry.
No. It catalogs approved servers but doesn’t sit in the call path. Pair it with client enforcement and a checkpoint that decides on every call.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
Got a use case in mind?
8 weeks from use case to agents running in production.
Platform, people and FDEs, all in. Bring your environment. We'll co-build and stay until it's live.
Talk to UsFree resource
101 AI Agents Use Cases
100+ production-ready AI agent use cases across Marketing, Sales, HR, Banking, Insurance, Operations and a lot more
Download now
