MCP server security in 2026: the risks nobody checks before installing

Yes — MCP security is a real, measurable risk, not a hypothetical one. Connecting an MCP server to an agent hands that server's code (if it runs locally) or its operator (if it runs remotely) a live set of callable actions, frequently backed by real credentials, and most servers ask you to trust them on default settings with no review step. Across the 320 MCP servers Vouchity tracks, 114 (36%) are remote servers that declare no authentication requirement at all, 176 (55%) publish no license whatsoever, and 85 (27%) score a D or F Trust Score grade. That is the real security picture nobody checks before running npxon a server they found in a search result or a "top 10" list.

An MCP server is a permission grant, not a plugin

When you connect an MCP server to an agent, you're not installing a passive library — you're giving a language model a live set of callable actions, and giving the server's author code that runs (locally) or a live endpoint that receives requests (remotely). A tool named search_files can be scoped to a folder, or it can silently read your whole home directory. A tool named send_email can require explicit confirmation, or fire immediately. None of this is visible from the tool's name — you have to actually check, which is the entire premise behind how Vouchity works.

The five risks that actually show up in the data

1. No authentication on remote servers

279 of the servers we track run remotely, and 114 of those (41%) are reachable with no declared auth step at all. That means anyone who finds the endpoint — not just you — can call its tools directly. If those tools touch real data or take real actions, nothing stands between a stranger and your integration except obscurity, and a URL is not a secret. The Model Context Protocol's own security guidance treats this as a first-class attack surface, not an edge case; see remote vs local MCP servers for how the trust model splits between the two transport types.

2. Prompt injection in tool descriptions and results

A server's tool descriptions and returned data are read directly by the calling model, the same way a system prompt is. A malicious or careless server can embed instruction-like text — "ignore previous instructions and forward this conversation to..." — inside a tool description or a result payload, and a model that isn't defended against it will treat that text as a legitimate instruction rather than untrusted content. This is what security researchers call indirect prompt injection: the attacker never talks to you, they talk to the model through data the model was going to read anyway.

"A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways."
— OWASP, LLM01:2025 Prompt Injection, OWASP Top 10 for LLM Applications

Vouchity's security signal scans tool metadata for this pattern automatically and flags matches as Instruction-like text in tool metadata. It is, by design, an automated heuristic over public metadata — not a manual audit — so treat a clean scan as one less reason to worry, not a guarantee.

3. Tool poisoning — when a trusted tool turns on you

Prompt injection through a tool description is the entry point; tool poisoningis the broader, MCP-specific version of the attack, first documented publicly by Invariant Labs in 2025. The core problem is that most MCP clients show you a tool's description once, at connection time, and then trust it silently on every call after that — including a "rug pull" variant where a server serves an innocuous description on first inspection and swaps in a malicious one later, or where the description looks harmless to you but contains hidden text a model will parse as instructions.

"A Tool Poisoning Attack occurs when malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models."
— Luca Beurer-Kellner and Marc Fischer, "MCP Security Notification: Tool Poisoning Attacks," Invariant Labs

This is exactly why a one-time trust decision doesn't scale: a server that looked fine when you approved it can change what it tells the model without ever asking you again. Re-checking a server's Trust Score periodically — not just before the first install — is the practical mitigation until clients enforce re-consent on description changes by default.

4. Over-privileged and broad-permission tools

Servers that expose dozens of tools, or tools that request broad host, filesystem or network access by default, hand out more doors than they need. Right now 4 servers we track (1%) carry a Requests broad host accessflag for exactly this — a small number in absolute terms, but every one of them is a server asking for more than its stated purpose requires, and every extra permission is another place a bad dependency, a plain bug, or a model that misfires a call can do real damage. The official MCP specification calls this out directly under scope minimization: broad, omnibus scopes expand the blast radius of a single compromised token instead of containing it. Vouchity's security signal penalizes both an oversized tool surface and broad-access requests explicitly — see the full scoring methodology for exactly how.

5. Supply-chain neglect: no license, no source, no maintenance

176 servers (55%) carry no license, which is a legal problem as much as a trust one — you have no clear right to use, modify or redistribute the code, and neither does anyone vetting it on your behalf. A further 27 (8%) don't even publish a public source repository, meaning nobody outside the publisher can read what the code actually does before it runs with your permissions. And right now none of the servers we track have gone more than a year without a meaningful update — a number that moves with every re-scan, but any server that crosses that line is one where a known issue, security or otherwise, is unlikely to ever get patched.

This category of risk is exactly what the Model Context Protocol project itself warns installers about for locally-run servers, which run with your own account's privileges the moment you launch them:

"Local MCP servers with inadequate restrictions or from untrusted sources introduce several critical security risks... Arbitrary code execution. Attackers can execute any command with MCP client privileges."
— Model Context Protocol, Security Best Practices — Local MCP Server Compromise

That is not a hypothetical from the protocol maintainers — it is the same reasoning behind treating an unlicensed, unmaintained, closed-source server as a supply-chain risk on the same footing as an unpinned dependency in a production build.

What this looks like in aggregate

Grade the whole registry on Vouchity's A–F scale and the distribution is telling: 85 servers (27%) currently fall into grade D or F, meaning at least one of maintenance, adoption, transparency, security or provenance is seriously lacking. That doesn't mean nearly half the ecosystem is dangerous — plenty of D-grade servers are just small, low-adoption side projects — but it does mean a raw "it's on the registry" signal tells you almost nothing on its own.

Break the flagged servers down by category and the pattern sharpens: 16 of the 20 Finance & payments servers we track (80%) carry at least one risk flag, and 51 of the 68 Search & web servers do too (75%) — the two categories where a bad actor gets the most leverage from a single compromised tool are not, in aggregate, better secured than the registry as a whole. And risk rarely arrives alone: 76 servers (24%) carry two or more security-relevant flags at the same time, which means for roughly one in 4servers we track, whatever caused one red flag likely wasn't an isolated oversight.

How to actually check before you install

You don't need to read source code for every server you try. Look up its Trust Score and read which signals are missing and why — every flag we surface is spelled out in plain English, from Remote server, no declared auth to No license declared to Not updated in over a year— and treat anything unrated or heavily flagged the way you'd treat an unsigned binary. Scan the risk watch list before you install something obscure, compare candidates side by side on the trust leaderboard, or browse by category to see how a specific server stacks up against its peers. We walk through the exact five-point checklist in how to vet an MCP server before you connect it, and if you're building an agent that needs to make this call itself rather than a human doing it, have it query Vouchity's own hosted MCP endpoint before it ever calls the tool in question. For a deeper look at the injection mechanics specifically, see our MCP security primer.