Loading…
A practitioner’s guide to Model Context Protocol security: the MCP threat model, tool poisoning, prompt injection, rug pulls, and how to vet a server before you connect it to your AI agent.
An exhaustive analysis of 5,308 Model Context Protocol (MCP) servers, introducing the mcpgrade-1.4.0 assessment framework and remediation blueprint.
4 min read
A curated list of the most useful MCP servers in 2026 — GitHub, Filesystem, Fetch, Slack, Playwright and more — with an honest security note on each and a checklist to vet any server.
12 min read
A dense, scannable reference for Model Context Protocol security: threats at a glance, a pre-connection checklist, config hardening, and the tools that detect each risk.
7 min read
Vet a Model Context Protocol server the way this article describes: paste a URL for a live A–F security grade, browse vetted servers in the directory, or read the exact checks behind every grade.
The Model Context Protocol (MCP) has become the default way to give AI agents hands. In under two years it went from an Anthropic proposal to a de facto standard implemented across Claude Desktop, Cursor, VS Code, and a fast-growing ecosystem of community servers. That momentum is exactly why MCP security now deserves the same scrutiny you would apply to any new authentication layer or third-party dependency.
This guide is a practitioner-grade walkthrough of model context protocol security: how the architecture works, where the attack surface actually lives, and a concrete process for vetting a server before you connect it to an agent that can read your files, hit your APIs, and touch production. If you only take one idea away, make it this: the model treats tool metadata as instructions, and tool metadata is untrusted input.
MCP is an open standard that defines how an LLM application connects to external tools, data, and reusable prompts. Before MCP, every integration was a bespoke plugin. MCP replaces that with one protocol, so any compliant client can talk to any compliant server.
The security consequence is structural. When you install an MCP server, you are not just adding a data source — you are adding a set of tool definitions that get injected directly into the model's context window. The model then decides, autonomously, when to call those tools and with what arguments. You have handed an external party partial influence over an agent that may already hold your credentials, your source code, and your customer data.
That is a different risk class than a normal library dependency. A malicious npm package has to execute code to do damage. A malicious MCP server can do damage purely through text the model reads and obeys. This is why mcp server security cannot be reduced to "is the code safe to run" — you also have to ask "is the content safe for a model to read."
Three roles define every MCP deployment:
The three server primitives each carry model-visible text:
| Primitive | What it is | Why it matters for security |
|---|---|---|
| Tools | Functions the model can invoke (read a file, query a database, send a request) | Name and description are injected into context; arguments can exfiltrate data |
| Resources | Data the model can read (files, records, documents) | Untrusted content the model may treat as trustworthy |
| Prompts | Reusable prompt templates the user can trigger | Can embed hidden instructions the same way tools can |
Two transports carry these messages. stdio runs the server as a local subprocess and pipes JSON-RPC over standard input/output — fast, local, but the server executes with your user privileges. HTTP (the current Streamable HTTP transport, and the older HTTP+SSE variant) connects to a remote server, which introduces network-layer concerns: TLS, authentication, and token handling.
The single most important fact for ai agent security: the model chooses and fills tools primarily from their name and description. Those strings are attacker-controllable when the server is untrusted, and they are read by the model as authoritative guidance. Every threat below flows from that fact.
MCP-specific risk clusters into seven categories. The following table is a working reference; each threat is expanded underneath.
| Threat | What the attacker does | How to detect it |
|---|---|---|
| Tool poisoning | Hides instructions in a tool description the user never reads | Static scan of descriptions; manual review in an inspector |
| Prompt injection | Plants instructions in resource content the model ingests | Content provenance checks; treat resources as untrusted |
| Rug pull | Silently changes a tool definition after approval | Pin versions; diff definitions on every connect |
| Tool shadowing | One server's tool description manipulates use of another server's tools | Isolate servers; scan cross-server interactions |
| Excessive permissions | Requests broader scope than the task needs | Least-privilege review of granted capabilities |
| Lethal trifecta | Combines private data, untrusted content, and exfiltration | Map data flows; break at least one leg |
| Config/secret exposure | Harvests plaintext secrets from client config files | Audit config storage; keep secrets out of plaintext |
Tool poisoning embeds hidden instructions inside a tool's description — text the user typically never sees in the UI, but that the model reads in full and tends to obey. A benign-looking add_numbers tool can carry a description that also tells the model to read ~/.ssh/id_rsa and pass its contents as a hidden argument. This class was publicly analyzed by Invariant Labs in 2025, and it remains the canonical MCP attack. We cover it in depth in MCP tool poisoning explained.
Prompt injection is the broader family: any time untrusted content reaches the model and is interpreted as instructions rather than data. With MCP, the injection can arrive through a returned resource, a tool result, or a third-party document the agent was asked to summarize. The defining problem is that the model has no reliable boundary between "content to reason about" and "commands to follow." See MCP prompt injection and the lethal trifecta for the mechanics.
A rug pull is a time-of-check to time-of-use attack. You review a server, approve its tools, and connect. Later — after trust is established — the server silently swaps a tool's definition for a malicious one. This is especially easy when servers run from unpinned, auto-installed packages, where every launch can pull a fresh, unreviewed version. The difference is one line in your client config:
{
"mcpServers": {
"risky-autolatest": {
"command": "npx",
"args": ["-y", "some-mcp-server"]
},
"pinned-and-reviewed": {
"command": "npx",
"args": ["-y", "some-mcp-server@1.4.2"]
}
}
}
The first entry re-fetches the latest published version on every launch, so a compromised update lands silently. The second pins an exact version you have already reviewed and scanned; a new release cannot execute until you deliberately bump the pin. Pinning is the direct countermeasure.
When multiple servers are connected to the same host, their tool definitions share one context window. A malicious server can write a description that manipulates how the model uses a different, trusted server's tools — for example, instructing the model to route every payment through an attacker's address whenever the trusted banking tool is called. The victim server is clean; the poison lives next door. Isolation and per-server review are the defenses.
Many servers request far more capability than their stated function needs — full filesystem access for a tool that should read one directory, or a database role that can write and drop tables when read-only would do. Over-broad scope turns a minor compromise into a major one. Grant the narrowest capability that still lets the tool work.
Coined by Simon Willison, the lethal trifecta is the combination of three properties in one agent session: access to private data, exposure to untrusted content, and the ability to exfiltrate externally. Any two are survivable; all three together mean a successful prompt injection can read your secrets and ship them out. MCP setups assemble this trifecta easily — a filesystem server (private data) plus a web-fetch server (untrusted content) plus any tool that makes outbound requests (exfiltration). Breaking even one leg neutralizes the class.
MCP clients store server configuration — including API keys, tokens, and connection strings — in local config files, frequently in plaintext. Anything with read access to that file, including other MCP servers with filesystem reach, can harvest those secrets. Treat client config as a credential store and audit it accordingly.
Trust is earned per server, per version. Run this checklist before any new server touches an agent with real access.
For a deeper, screenshot-level walkthrough of steps 2 and 3, see how to inspect an MCP server. When you are ready to add capabilities, choose from reviewed options in the best MCP servers for 2026.
Scan only servers you operate or are authorized to assess. Our own scanner follows a published, read-only scanning policy — public endpoints only, no authentication, honouring robots.txt and a 24-hour delist — and you should hold yourself to the same standard when vetting someone else's server. If you maintain a server, turn a clean scan into a trust signal: publish your live A–F grade as a README badge and query it programmatically through the free, read-only MCP grade API.
No single control is sufficient. Layer these:
npx -y-style auto-latest launches for anything with real access. Immutable references defeat rug pulls.No. MCP is a transport and description standard; it is neither more nor less secure than what you connect. The risk comes from connecting untrusted servers to a high-privilege agent without review. Treat each server as a third-party dependency that also gets to whisper instructions to your model, and vet it accordingly.
Tool poisoning, rug pulls from unpinned packages, over-broad permissions, and plaintext secret exposure in client config are the ones we see most. Cross-server tool shadowing is rarer but higher-impact because the poison hides in a server other than the one being abused.
Yes, if the conditions line up. A server with filesystem access, or a poisoned tool that convinces the model to read sensitive paths and pass their contents to an outbound tool, can exfiltrate secrets. This is the lethal trifecta in action, and it is why least privilege and human-in-the-loop approval matter.
You often cannot tell from the host's UI, which shows only a friendly label. Inspect the raw description and parameter schema in the MCP Inspector, then run the MCP Server Security Scanner to catch hidden instructions, zero-width unicode, and exfiltration parameters that manual reading can miss.
Yes — it is one of the highest-leverage controls. Pinning to an exact, immutable version means an attacker cannot silently push a malicious update to a server you already approved. Every version bump then becomes a deliberate re-review instead of an automatic trust extension.
Not automatically. Local stdio servers run with your user privileges and can read anything you can, so a poisoned local server is very dangerous. Remote HTTP servers add network-layer concerns like TLS and token handling but keep code off your machine. The right transport depends on your threat model; both need vetting.
MCP is worth adopting — the productivity gains from well-integrated agents are real. But the model reads tool metadata as instructions, so every server you connect is part of your trust boundary. Vet before you connect, pin what you trust, scope down what you grant, and keep a human in the loop for anything destructive.
Start with the full workflow in the MCP security toolkit: inspect a server, scan it for poisoned descriptions, audit your client config, and browse vetted servers in the directory — all before your next agent gets a new pair of hands.
Or go straight to the live tooling: run any server through the MCP security scanner and hub, grade it against the same rules described above, and check it against a vetted server directory. The full vetting process is written up as a repeatable methodology, and you can see where the ecosystem currently stands in the state of MCP security.
Share this article
MCP servers can hand an AI agent private data, untrusted content, and a way to exfiltrate it — the lethal trifecta. How prompt injection works over MCP, and how to break the chain.
12 min read
Sign in to leave a comment.