Is MCP Safe? What the Model Context Protocol Actually Exposes
You want to connect a few MCP servers to Claude or Cursor, and something makes you hesitate. You're about to hand an...
You want to connect a few MCP servers to Claude or Cursor, and something makes you hesitate. You're about to hand an AI agent access to your files, your GitHub, maybe your email — through a server someone else wrote, that you found in a registry, that you haven't read a line of. The question sits there: is this safe, or am I about to do something I'll regret?
It's the right question, and most answers are either hand-wavy reassurance or breathless doom. Here's the honest version, built from the security research and real incidents of the past year.
Is MCP safe to use?
Mostly yes — with the sharp caveat that MCP's safety depends almost entirely on what you connect to it, not on the protocol itself. MCP is a transport standard. Per the official Model Context Protocol specification, every message between clients and servers must follow JSON-RPC 2.0, running over local stdio or HTTP, with authentication and permission enforcement left to the host application. There's nothing inherently dangerous in that plumbing.
The danger is what the plumbing carries. An MCP server can expose tools that read your filesystem, hit internal APIs, send email, or run shell commands — and the agent uses them with whatever permissions you granted. So "is MCP safe" is really two questions: is the protocol sound (yes), and is this server, with these permissions, in my setup safe (that's on you). And the exposure is scaling fast: the security registry AgentSeal reported the ecosystem grew from 714 MCP servers in January 2025 to over 16,000 a year later, with almost nobody auditing them before connecting. That's the real risk surface — not MCP, but thousands of unvetted servers wired into agents that can act.
What are the actual security risks of MCP?
The core risks are tool poisoning, indirect prompt injection, malicious or compromised servers, over-broad permissions, and rug-pull updates — and each exploits a different trust boundary. Here's what each one actually is.
Tool poisoning
The most MCP-specific risk, and the one most people miss. According to the OWASP Foundation, tool poisoning embeds hidden instructions inside a tool's description — the metadata the model reads to decide how to use a tool, which the user never sees during normal operation. A tool called send_email can carry a description that also instructs the agent to read your SSH keys and attach them to the outgoing message. The user sees a normal tool; the model sees the full payload and often follows it.
How often? A benchmark study called MCPTox (Wang et al., arXiv, August 2025, accepted at AAAI 2026) tested 20 prominent LLM agents against poisoned tools built on 45 live MCP servers and 353 real tools. The o1-mini agent hit a 72.8% attack success rate. Two findings stand out: more capable models were often more vulnerable, because the attack exploits their stronger instruction-following, and agents almost never refused — the highest refusal rate, Claude 3.7 Sonnet, came in under 3%. Safety alignment, in other words, doesn't save you here.
Indirect prompt injection
Injection doesn't have to live in the server. It can ride in on any content the agent processes — a GitHub issue, a document, a calendar event. In May 2025, Invariant Labs disclosed that malicious instructions hidden in a public GitHub issue could hijack an agent using the official GitHub MCP server and exfiltrate private repository code into a public pull request. The agent had broad token scopes, so it could reach everything the token permitted.
Malicious and compromised servers
Supply-chain attacks apply to MCP the same way they apply to any package — except here the compromised dependency is a tool your agent trusts and acts on autonomously. In September 2025, security firm Koi Security identified postmark-mcp, a counterfeit npm package, as the first confirmed malicious MCP server found in production. One added line silently BCC'd every outgoing email to an attacker; it had 1,643 downloads before removal.
Over-broad permissions
The mundane risk that causes the most damage. An agent given powerful tools and loose approval will eventually do something irreversible — the AgentSeal report opens with a developer whose AI agent ran terraform destroy and wiped years of production data, not through any attack, but because the tool worked exactly as designed and the action got approved too fast.
Rug-pull updates
A server can pass review, get approved, then change its tool definitions later. Invariant Labs coined "rug pull" for this in April 2025: the version you vetted isn't necessarily the version you're running tomorrow, and the trust you granted carries over silently.
Why does a more capable model make this worse, not better?
Because these attacks weaponize the exact skill that makes a model good: following instructions precisely. That's the counterintuitive core of the MCPTox finding — the agents that best understood a tool's stated intent were the ones most likely to also execute the malicious intent hidden alongside it. A weaker model might fumble the injected command; a stronger one carries it out cleanly. "Just use a smarter model" is not a security strategy, and complete prevention of prompt injection remains an open research problem, because LLMs process trusted instructions and untrusted content through the same channel. The fix has to live outside the model.
What can't access controls fix on their own?
Access controls can't catch the injection that causes a bad tool call — they only see the call itself. This is the load-bearing point, and it's why permissions alone aren't enough. As OWASP describes it, the root cause is a trust gap between connect-time and runtime: a tool's description is reviewed once, when you first connect, but its responses flow straight into the model's context with no equivalent check. Once an injected instruction is sitting in that context, the access-control layer sees a legitimate-looking request to a tool the agent is allowed to use — not the poisoned input that triggered it.
Two consequences follow. First, system-prompt restrictions ("don't read files outside /tmp") are enforced only by the model's willingness to obey, which injection overrides — real limits have to live at the tool-execution layer, server-side. Second, combinations matter more than individual tools: a server that reads Slack and a server that writes files are each harmless alone, but together they form a path from an external message to your disk. AgentSeal calls these toxic data flows and flagged hundreds of high- and critical-severity cases across the servers it scanned — none requiring a single malicious server to exist.
How do you run MCP safely?
You run MCP safely by treating every server as untrusted until you've checked it, and by giving each one the least power it needs to do its job. The security community — OWASP among them — converges on a short, practical checklist. None of it is exotic.
- Vet servers before connecting, and keep an allowlist. Don't point an agent at an arbitrary server URL. Read what tools it exposes and what their descriptions actually say. Public registries and scanners exist now specifically to surface hidden instructions and dangerous capabilities before you install.
- Scope permissions tightly. The GitHub exfiltration worked because the token had broad scopes. Give a server the minimum it needs — read-only, single-repo, single-purpose. A tool that only needs public data should never hold a credential that can reach private data.
- Isolate privileged tools. Run high-privilege tools — filesystem, database, internal APIs — in a context that external servers can't reach. An agent that can both read untrusted input and execute privileged actions is the dangerous combination.
- Enforce limits server-side, not in the prompt. Backend access controls hold under injection; system-prompt instructions don't.
- Require human confirmation for sensitive actions. Before anything destructive or data-exfiltrating runs, approve it outside the model's context — and actually read the plan, especially when a command contains the word "destroy."
- Prefer structured, scoped data over raw execution. The fewer raw, high-privilege servers you pipe in, the smaller your blast radius. Every server you add is more tool metadata in context and more attack surface — connecting fewer, narrower sources beats connecting everything. (More on why over-connecting backfires: Why Too Many MCP Servers Make Your AI Worse.)
The honest framing is the one the security researchers keep landing on: perfect security isn't achievable, because injection and the same-channel problem don't have a clean fix yet. That's not a reason to avoid MCP. It's a reason to layer defenses so an attacker moves on to an easier target. Lock the door; you're not building a vault.
For developers: where the technical risk concentrates
If you're building or hosting MCP servers, the recurring vulnerability class is command injection — untrusted model or user input reaching a shell or execution function unsanitized (CWE-77, CWE-78, CWE-94). The most severe documented case, CVE-2025-6514 in the widely used mcp-remote npm package, was a command injection in OAuth handling that JFrog reported enabled full remote code execution on the client just from connecting to a malicious server, scored CVSS 9.6. Validate every input, never trust the endpoint on the other side, and assume the model's output can be adversarial. The extension ecosystem carries the same risk — Snyk reported in February 2026 that roughly 36% of the AI agent skills it scanned contained at least one security flaw.
One principle is worth carrying into every connection decision: narrow, read-scoped, structured data is a far smaller attack surface than a raw source that can execute or exfiltrate. Whether you're building tools or just choosing what to connect, prefer the version that can only be read over the version that can act. (Related: How to Give AI Access to Your Data Without Giving It Away.)
So — should you be afraid of MCP?
No. Be careful, not afraid. MCP is sound infrastructure with a real and growing attack surface around it, and the difference between safe and sorry is almost entirely in your hands: what you connect, how much power you grant it, and whether you check before you trust. The people getting burned aren't the ones who used MCP — they're the ones who connected an unread server to an over-privileged agent and approved on autopilot.
Treat every server as untrusted until proven otherwise, give each the least power it needs, and keep a human in the loop for anything that can't be undone. Do that, and MCP is one of the more controllable ways to give AI tools real reach.
Want the bigger picture on what MCP is and how it fits with connectors and context layers? Start with Connectors vs MCP vs a Context Layer.
