In November 2024, Anthropic open-sourced the Model Context Protocol (MCP), a standard that lets AI models call external tools — reading files, querying databases, sending Slack messages, executing shell commands — through a common interface. Adoption was almost immediate: within a year, community registries like Smithery, mcp.so, and PulseMCP were indexing thousands of MCP servers, most published by individual developers with no code signing, no reproducible builds, and no security review. Each server is effectively a plugin with standing access to an AI agent's context window and, often, the credentials it's been handed. That combination — high privilege, low vetting, viral distribution — is exactly the profile that has made npm and PyPI perennial supply chain targets. The difference is that MCP servers don't just execute code; they shape what a model believes and does. This post breaks down where MCP registry security is failing today, what that looks like next to JFrog's package-curation model, and what a real fix requires.
What Is an MCP Server Registry, and Why Does It Matter Now?
An MCP server registry is a discovery index — not a security boundary — and treating it as the latter is the root of the current risk. Registries like Smithery and mcp.so let anyone publish a server manifest (name, description, available "tools," and an install command, usually npx or uvx pulling straight from a public package). By mid-2025, Smithery alone listed more than 5,000 servers; PulseMCP's index crossed 4,000 around the same time. Neither registry, nor the MCP specification itself, mandates static analysis, provenance attestation, or a review gate before a server appears searchable inside an IDE like Cursor, Claude Desktop, or Windsurf. A developer adding "the top-rated Postgres MCP server" is one npx command away from granting an LLM-driven agent read/write database access via code they've never inspected — a trust decision most teams wouldn't make for a random npm package, made routinely because the interface is a chat window instead of a package.json.
How Big Is Unvetted MCP Sprawl Inside the Enterprise?
It's bigger than most security teams have inventoried, because MCP adoption is happening bottom-up through developer tooling rather than through procurement. Engineers add MCP servers the same way they add VS Code extensions — via a one-line config edit in claude_desktop_config.json or an IDE settings panel — with no ticket, no SCA scan, and no SBOM entry. Anthropic's own directory and third-party aggregators had cataloged integrations for GitHub, Slack, Google Drive, Postgres, Kubernetes, and Jira by early 2025, meaning a single misconfigured or malicious server can sit at the intersection of source code, customer data, and infrastructure credentials simultaneously. Unlike a compromised npm package, which typically needs a postinstall script or an unreviewed dependency bump to trigger, a malicious MCP server doesn't need to exploit anything — the AI agent invokes its tools as designed, on natural-language instruction, which is precisely why static registry listings undercount the real exposure.
What Attacks Have Already Exploited Unvetted MCP Servers?
Security researchers demonstrated exploitable MCP-specific attack classes within months of the protocol's release, not years. In April 2025, Invariant Labs published a "tool poisoning" proof of concept: a malicious MCP server embedded hidden instructions inside a tool's description field — invisible in most UIs — that told the connected model to read the user's SSH private keys and exfiltrate them through a parameter of an unrelated, seemingly benign tool call. The same research team disclosed a "rug pull" variant the following month: a server can pass review at install time with an innocuous tool description, then silently redefine that same tool's behavior on a later request, since MCP clients typically don't re-verify definitions after the initial handshake. In May 2025, Invariant Labs also showed that the official GitHub MCP server could be manipulated via a prompt-injected GitHub issue in a public repo to leak private repository contents to an attacker — no vulnerable code, just the agent following instructions it wasn't supposed to trust. Separately, researchers documented "MCP shadowing," where a second, malicious server overrides the tool definitions of a legitimate one already loaded in the same session. None of these required a CVE in the traditional sense; they exploited the trust model itself.
Why Isn't Traditional Package Scanning, the JFrog Model, Enough for MCP Servers?
Because JFrog's curation model was built to catch known-bad artifacts before they enter a build, not to evaluate the runtime behavior of a tool a model is actively reasoning about. JFrog's Xray and Curation products — the latter expanded significantly after JFrog's 2024 acquisition of Qwak and rebrand into JFrog ML — scan packages for malicious code signatures, license violations, and CVEs against sources like the JFrog Security Research team's own malicious-package feed, which has flagged tens of thousands of malicious npm and PyPI packages since 2021. That's real, valuable coverage for dependency confusion and typosquatting. But MCP risk lives one layer up: a tool poisoning payload sits in a JSON description string, not a binary or a package hash, and a rug-pull update changes behavior after the artifact has already been scanned and approved. Static SCA scanning answers "is this code known-malicious?" MCP registry security has to answer a harder, ongoing question: "does what this server tells the model it does match what it actually does, every time it's invoked?" That's a behavioral and semantic problem, not a signature-matching one — and it's the gap unvetted AI tool servers are currently exploiting.
What Should a Secure MCP Registry Actually Vet?
A defensible MCP registry security posture needs four things most current registries have none of: provenance, integrity pinning, description-to-behavior verification, and scoped permissioning. Provenance means knowing who published a server and whether the underlying package matches a reproducible, signed build — the same standard Sigstore and SLSA have pushed into the broader OSS ecosystem since 2021, largely absent from Smithery- and mcp.so-style listings today. Integrity pinning means an installed server's tool manifest is hashed and locked, so a version bump that silently rewrites a tool's description or scope triggers a re-approval, closing the rug-pull window Invariant Labs demonstrated. Description-to-behavior verification means actually exercising a server's tools in an isolated environment to check that a "read a calendar event" tool doesn't also make an outbound HTTP call to an unlisted domain — catching tool poisoning that hides in plain text no human reviewer reads closely. And scoped permissioning means an MCP server connected for Jira ticket lookups shouldn't be able to request filesystem or shell access at all, regardless of what its manifest claims it needs.
How Safeguard Helps
Safeguard treats every MCP server your organization connects to an AI agent as a first-class supply chain artifact — inventoried, verified, and continuously monitored, not just scanned once at install time. Concretely, Safeguard:
- Builds a live MCP Bill of Materials (MBOM) across every IDE, agent, and CI environment in your organization, so security teams stop discovering Postgres, GitHub, and internal MCP servers only after an incident — closing the "developer added it via a config file" blind spot that registries and traditional SCA tools both miss.
- Cryptographically pins tool manifests at approval time and alerts on any drift — catching rug-pull attacks the moment a server's tool description, scope, or endpoint changes, instead of trusting a one-time review.
- Sandboxes and behaviorally tests MCP servers before approval, executing their advertised tools against synthetic inputs to flag mismatches between stated function and actual network, filesystem, or credential access — the specific gap that lets tool poisoning payloads hide inside description fields undetected by static scanners.
- Enforces least-privilege scoping per server and per tenant, so a server approved for read-only ticket access can't later be invoked with write or shell capabilities, and a compromise in one team's MCP connection can't laterally reach another tenant's data.
- Feeds MCP provenance and risk signals into the same policy engine used for your broader software supply chain — meaning an unvetted AI tool server is evaluated with the same rigor as an unsigned container image or an unreviewed open source dependency, rather than living in a separate, unmonitored category of risk.
MCP registry security isn't a problem you solve by scanning harder with the tools built for npm and PyPI — it requires verifying what a tool says it does against what it actually does, continuously, for every server your agents can reach. That's the layer Safeguard is built to close.