Treat the Anthropic MCP server registry like an unsigned package manager

Is the Anthropic MCP server registry safe? Not by default. The safe answer in May 2026 is to treat every MCP server install as untrusted code until you verify how it is distributed, what runtime it executes, what scopes it gets, and whether it stays inside a sandbox. Anthropic has added more review around some plugin distribution paths, but the broader MCP ecosystem still makes it very easy to install local code through bundles, GitHub repos, and package managers before package-manager-grade trust controls exist at the protocol level (Anthropic Desktop Extensions, MCP security best practices, Claude Plugins — Community).

What most people miss is where the real bottleneck sits. The loud conversation is about prompt injection inside Claude. The quieter, more important problem is distribution. Anthropic can keep improving model behavior, but if your team installs an MCP bundle that ships a malicious dependency, or copies an npx command from a community directory, you are back in the same trust model that made npm and PyPI supply-chain incidents so expensive. The protocol is only half the story. The install path is the other half. That is the registry-specific extension of the broader argument in ai-coding-agent-supply-chain-threat-atlas-2026: agents are dangerous less because they "think" and more because they compress retrieval, execution, and privilege into one uninterrupted flow.

Treat the ecosystem as three trust zones, not one registry

There is no single "Anthropic MCP registry" with one security model. There are at least three trust zones that matter in practice.

First, there is Anthropic's reviewed plugin path. The anthropics/claude-plugins-community repository says the public repo is a read-only mirror of a community plugin marketplace and that listed plugins are synced from an internal review pipeline after automated security scanning and approval for distribution (Claude Plugins — Community). That is better than many people assume. It means some of the ecosystem already has more process than "random GitHub README plus hope."

Second, there is the Desktop Extensions path. Anthropic's Desktop Extensions post makes installation intentionally frictionless: an .mcpb bundle is a zip archive containing the MCP server, its dependencies, and a manifest.json, and Claude Desktop is designed to make installation feel like a one-click action (Anthropic Desktop Extensions, MCP Bundles toolchain). That convenience is the point of the product. It also means the old security friction of manual config editing, environment setup, and dependency inspection is disappearing.

Third, there is the wider community directory path. The cnych/claude-mcp repository describes claudemcp.com as a community hub with a server directory and a submission flow that can auto-generate pull requests for new entries (claudemcp.com source repo). That is useful for discovery. It is not the same thing as a cryptographically signed, centrally enforced trust program.

This is the first correction security-minded teams should make: stop talking about "the registry" as if it were one thing. Anthropic-reviewed plugins, one-click bundles, community directories, direct GitHub installs, and npm or uvx install flows are different risk classes. If your policy says "MCP is allowed," but does not distinguish among those channels, your policy is too coarse to matter.

Assume one-click installs can run local code

The MCP documentation is not vague about the failure mode here. The official security best-practices page includes a local server compromise example that literally shows npx malicious-package exfiltrating ~/.ssh/id_rsa, and a privilege-escalation example that chains dangerous shell behavior into an install flow (MCP security best practices). That is not alarmist writing. It is the protocol documentation telling you that local MCP servers should be treated as code execution, not as harmless metadata.

Anthropic's own Desktop Extensions materials reinforce the point from a packaging angle. A bundle can contain a Node server, a Python server, or a classic executable, plus the dependencies required to run it (Anthropic Desktop Extensions, MCP Bundles toolchain). In other words, the ecosystem has already normalized a format whose whole job is to make local code execution feel as ordinary as installing a browser extension.

That is why Anthropic's sandboxing work matters so much. The Claude Code sandboxing post explains that real isolation needs both filesystem and network boundaries, and says sandboxing reduced permission prompts by 84% in Anthropic's internal usage (Claude Code sandboxing). The important read is not "great, fewer prompts." It is "Anthropic had to build stricter boundaries because prompt approval alone was not a strong enough defense." If you install a third-party MCP server without equivalent boundaries, you are choosing the pre-sandbox trust model.

There is also a subtle but important asymmetry between Anthropic's reviewed plugin mirror and the rest of the install ecosystem. The plugin mirror now says marketplace entries have passed automated security scanning and approval for distribution (Claude Plugins — Community). Good. But Desktop Extensions, direct GitHub installs, and community-directory copy-paste flows still do not inherit one universal trust layer by default. The risk is not that Anthropic reviews nothing. The risk is that most teams will behave as if one reviewed surface somehow secures all the other surfaces.

Score these 10 registry risks before you install anything

Here is the practical threat model. Not every item below has a formal CVE yet. Several are attack classes that the MCP docs or Anthropic docs already describe directly. That is exactly why they deserve attention now.

| Risk | Why it matters | What to verify before install | |---|---|---| | 1. Unvetted bundle install | .mcpb packages make local code execution look routine | Inspect runtime type, dependency tree, and network destinations | | 2. Prompt injection through tool results | Tool output can carry instructions the model treats as context | Separate untrusted content from privileged tools; review server output handling | | 3. Dependency confusion in npm/PyPI packages | Many MCP installs still resolve through generic package managers | Pin exact versions and check package provenance | | 4. Auth and transport gaps on remote servers | Remote MCP still depends on correct OAuth and metadata handling | Require protected-resource metadata, scopes, and TLS-only endpoints | | 5. Capability spoofing | A server can advertise a benign surface and behave differently later | Re-check tool list changes and lock allowed tools | | 6. stdio child-process abuse | Local servers run as processes with meaningful local access | Force sandboxing and deny ambient shell/network privileges | | 7. Off-marketplace plugin injection | Review exists for marketplace plugins, not for every repo install | Prefer reviewed channels over README-based installs | | 8. Social-proof manipulation | Stars and directory ranking are cheap to fake | Prefer code provenance and maintenance history over popularity | | 9. Namespace squatting | Lookalike package and repo names are easy to miss | Verify exact repo owner, package name, and release history | | 10. Transitive cloud-provider trust | Hosted MCP servers inherit the blast radius of their hosting stack | Review where the server runs and what cloud credentials it touches |

A few of these deserve extra emphasis.

Prompt injection is still the obvious attacker move, but the right frame is wider than "the model saw a bad sentence." The MCP docs explicitly call out session hijacking, confused-deputy risks, overscoped auth, and local server compromise as implementation concerns, not abstract theory (MCP security best practices, MCP authorization spec). If your server can read untrusted resources and also act with broad write scopes, prompt injection becomes a trust-boundary failure, not just an LLM failure.

The authorization story is especially important for remote servers. The spec requires protected-resource metadata discovery, WWW-Authenticate scope challenges, and resource-bound access patterns so clients know which scopes are needed for which target (MCP authorization spec). That gives teams a real design pattern: if a registry entry cannot explain its scopes, audience binding, and authorization metadata, it has not earned production trust.

The cloud-provider risk sounds abstract until you tie it back to Anthropic's deployment footprint. Anthropic's April 2026 AWS announcement says the company is committing to huge compute expansion and deeper AWS integration, including a coming Claude Platform on AWS experience (Anthropic and Amazon compute expansion). That does not mean AWS-hosted MCP is unsafe. It means infrastructure concentration is part of the trust chain now. Hosted MCP tools are not just "a remote server." They are remote servers sitting inside specific cloud, identity, and governance assumptions.

Audit an MCP server with policy, not social proof

A security review for an MCP server should look a lot more like a package review than a product demo. I would ask five questions before approving any install.

1. What code actually runs, and in which runtime?
2. What outbound network destinations does it need on day one?
3. What scopes does it request, and can those scopes be narrowed?
4. Is this install path covered by a reviewed marketplace, or did it arrive through a repo, a bundle, or a package manager?
5. If the server is compromised, what can it read, modify, or exfiltrate from the operator's machine or connected services?

That checklist is boring on purpose. The bad alternative is to trust stars, screenshots, or "official-looking" install pages. The claudemcp.com source repo makes clear that the directory is a community hub and submission surface (claudemcp.com source repo). The claude-ai-mcp repository is a communications hub for MCP integration issues, not a blanket statement that every listed or community-discovered server is safe to install (Claude.ai MCP Integration). Neither surface should be read as a substitute for runtime review.

The reason to encode review this way is that Anthropic's own security products are moving in the same direction. Claude Security, now in public beta, is positioned as an agentic security reviewer that finds vulnerabilities and generates patches, but it is not wired directly into every MCP install path or community directory by default (Claude Security public beta). That is useful context for buyers: the defense capability exists, but the registry plumbing has not caught up yet.

Ask for package-manager-grade trust, not smarter models

The most useful long-term demand is not "make Claude better at spotting prompt injection." Anthropic should do that, and clearly is doing some of it. The bigger ask is to make MCP distribution feel more like a hardened software supply chain.

That means signed bundles, provenance attestations, visible review states, scope manifests that are enforced instead of merely declared, and install policies that enterprises can apply across reviewed plugins, bundles, and remote servers. It also means pushing more of the MCP documentation's security guidance into defaults. The protocol docs already describe scope minimization, SSRF defenses, session binding, and local-compromise risks in plain language (MCP security best practices, MCP authorization spec). The gap is not awareness. The gap is making those controls unavoidable in real installs.

That is the real difference between an interesting ecosystem and a production-safe one. Anthropic's reviewed plugin mirror is a step in the right direction. So is sandboxing. So is Claude Security. But none of those remove the core problem that distribution still outruns trust. Until every major MCP install path offers package-manager-grade provenance and enforceable least privilege, the right security posture is skepticism first, convenience second.

This post is the narrower follow-up to ai-coding-agent-supply-chain-threat-atlas-2026. If you want the implementation path after the threat model, start with MCP from First Principles to Production: Why JSON-RPC over stdio beat WebSockets + OpenAPI. Then use Production Agents with Claude Agent SDK + MCP Connector to design the sandboxing, connector scoping, and runtime boundaries that keep an MCP install from turning into a local breach.