Is MCP safe? The security risks AI assistants don't mention
You connected your AI assistant to a dozen MCP servers this year. Calendar, email, knowledge base, the works. Here's what nobody mentioned when you clicked allow: the protocol underneath those connections was built for functionality, with security left as someone else's problem. Peer-reviewed research published in 2026 shows the attacks succeed far more often than you'd guess from clicking allow.
Quick answer > MCP (Model Context Protocol) is not safe by default. A 2026 DSN paper showed tool-poisoning attacks reaching a 100% success rate against Claude Sonnet 4 and Gemini 2.5 Pro when the attacker controls the tool description. The same paper's audit of six public MCP registries found 833 vulnerable servers, 9 leaked GitHub tokens (5 still valid), and over 200 hijackable accounts. Treat every MCP server as untrusted code.
What does an MCP server actually have access to?
An MCP server is a process that exposes tools to an AI assistant. Once you connect one, the assistant can call any tool that server exposes, with whatever credentials you handed it during setup. There is no permission prompt per call in most clients. You authorized the server once; it can do whatever its tools allow for as long as it stays connected.
In practice that means: if you connected an MCP server to read your calendar, it can read your calendar. If that server is malicious or gets compromised later, it can still read your calendar. The protocol does not constrain what the server does with the data it reads, and most clients do not log individual tool calls in a way you can review afterward.
The attack surface grows with every server you add. Two servers from different authors can both claim the tool name send_email, and your AI client may not be able to tell them apart.
How does a tool-poisoning attack work?
A 2026 paper accepted to the DSN conference (arXiv 2510.16558) documents two attack classes that work against the AI clients people actually use.
The first is tool-name collision. When two MCP servers expose tools with identical names, Cursor silently invokes the first-listed server, ignoring its own mcp_<server>_<tool> prefix disambiguation. In the paper's controlled test, the model selected a tool from server B, and Cursor called server A instead. The user saw no warning. The bug is corroborated by at least four Cursor forum threads and a matching issue in OpenAI's Agents SDK.
The second is tool poisoning. A malicious server crafts its tool descriptions or error messages to include instructions that override the model's actual task. When the model reads the tool list (which it does before every call), it follows the injected instruction. Across Cursor, Windsurf, and Cline, crafted tool descriptions succeeded 100% of the time against Claude Sonnet 4 and Gemini 2.5 Pro. The weaker variant, where the attacker only controls server-provided text, scored lower but still landed in most trials. GPT-4o was more conservative but not immune. Related work (MCPTox, MindGuard) confirms the threat class is real and growing. The transport underneath all of this changed on 2026-07-28, adding header-body validation on top of the existing mandatory Origin check: see what the July 28 revision breaks.
This isn't a theoretical vulnerability. It is a near-deterministic attack against the models most people are using right now.
Can a server hide an attack by splitting it across messages?
Yes, and it is the sharpest MCP result published since that paper. In July 2026 the ASSET Research Group wrote up, and on August 11 released as a public proof of concept, GhostSplice, a proof of concept for what it calls a cross-channel trust fragmentation attack. Rather than put the malicious instruction where a scanner would look for it, the server splits it across three channels the agent already trusts. In the researchers' words: "No piece looks harmful on its own."
The demo runs like this. The tool description advertises a plain form with blank fields (alpha, beta, gamma, delta) and names no file. A scan_project result returns an ordinary file list, the kind any scanner returns. A deep_scan result supplies the mapping: copy the raw contents of .ssh/id_rsa, src/..., data/customers.csv, and .env into that form. Read one at a time, each is boring. Read in the same context window, they compose into an exfiltration request nobody ever had to type. A description scanner sees a schema. A keyword filter sees "populate the parameters." The model's refusal never fires, because at no single point was it asked to do anything wrong.
Read the numbers carefully, because the trade coverage rounded them badly. Across the eleven API models tested, average compliance roughly doubles, from 42% to 82%, so the average baseline was never zero and for most models the attack raises an already non-trivial rate. But three models that had refused on every single attempt (GPT-4o, Gemini 2.0 Flash and Llama-3.3-70B) go straight to 100% once the request is split. For those three, the attack really does flip a refusing model into a complying one; the headline "0% to 100%" is true of them and false as a description of the field.
Two caveats the researchers state plainly, and which most coverage dropped. This is not a way into an arbitrary agent from outside: it assumes you already connected the attacker's MCP server, and that the agent can already read the files being taken. And the tests ran in isolated projects seeded with fake credentials, not against anyone's real machine. Affected vendors were notified before publication.
What went wrong on public MCP registries?
The same paper audited six public MCP registries (67,057 servers total) in mid-2025 and found:
- 833 servers with confirmed security vulnerabilities.
- 9 GitHub personal access tokens leaked in configuration examples on mcp.so. 5 were still valid when the researchers checked.
- 212 deleted GitHub accounts that could be re-registered by an attacker, plus 304 redirected accounts vulnerable to reclamation. Because most MCP servers are hosted on public GitHub repos, a reclaimed account means a hijacked server, and every client that ever connected to it.
Anyone running an MCP server they found on a public registry is depending on the author's operational hygiene. Most authors are hobbyists. Some have stopped maintaining the repo. A few have abandoned the GitHub account.
Which AI clients are most exposed?
Any client that auto-loads servers and passes tool descriptions to the model is exposed to tool poisoning. The DSN paper tested Cursor, Windsurf, Cline, and Claude Desktop; the mechanism applies to any MCP client.
Claude Desktop, VS Code Copilot, and ChatGPT's Developer Mode MCP all read tool descriptions into the model context. None of them sandbox the server process by default. ChatGPT's full MCP support (developer mode, which OpenAI labels elevated risk and limits to paid and education accounts on the web) is remote-only, with a local server reachable only through OpenAI's Secure MCP Tunnel, an outbound-only relay, which removes the localhost attack vector but does nothing if the remote server itself is compromised.
The GhostSplice results add a finding worth more than the attack itself: the client mattered as much as the model. The same model, GPT-5.4, ran the attack 90% of the time under Cursor and 0% behind Claude Code. Sonnet and Opus held at 0 out of 20 across every split the researchers tried. So the safety boundary that held was the one wrapped around the model, not the one inside it. That is an uncomfortable result for anyone whose plan is "use a smarter model," and a useful one for anyone choosing a client: ask what the client does with tool output before it reaches the model, and whether you can see afterwards what got called.
What happens after the session ends?
Everything above is about a single session. The harder problem is what persists into the next one, because agentic clients keep memory and instruction files on disk and load them at startup.
Cisco's AI security researchers demonstrated this against Claude Code in April 2026 and disclosed it to Anthropic. The mechanics are worth understanding: Claude Code read MEMORY.md files from the home directory and each project folder, and in the version Cisco evaluated they "found that first 200 lines of these files are loaded directly into the AI's system prompt," where memory files were "treated as high-authority additions to this rulebook." The escalation is the part to remember, because nothing about it looks like an attack: approving an ordinary install command was enough, and "the routine, user-sanctioned action allowed the payload to move from a temporary project file to a permanent, global configuration stored in the user's home directory."
That specific vector is fixed. As of Claude Code v2.1.50, Anthropic "has included a mitigation that removes user memories from the system prompt," so memory files no longer carry the same authority. Credit where it is due, and check your version.
The general problem is not fixed, and a July 2026 paper testing Claude Code and OpenAI Codex across four models found the shape of it: "although it is difficult to make an agent overwrite its own memory files using untrusted external content, payloads already planted in those files can successfully attack current and future sessions." Persistence is the weak point, not injection. Which is why the useful habit is unglamorous: keep the files your client loads at startup in version control, read the diff when one changes, and treat a memory file you did not write the way you would treat a script you did not write.
How do you use MCP safely?
You don't have to stop using MCP. You do have to stop trusting it.
- Audit what you've connected. Open your client's MCP config (in Claude Desktop it's
claude_desktop_config.json) and remove any server you don't actively use. Every connected server is a live attack surface. If you're not sure where servers get configured these days (extensions, connectors, or JSON), the 2026 install guide maps all three. - Read the source. If the server is on GitHub, check the last commit date, the issue tracker, and whether the author's account is active. Abandoned repos with live tokens are exactly the hijack scenario the researchers found.
- Scope the credentials. Never give an MCP server a token with more permissions than the server needs. A calendar reader should not have write access to your entire Google Workspace.
- Prefer revocable auth. Long-lived OAuth tokens that live for the whole token family are the wrong default for something you don't fully trust. Use scoped, individually revocable tokens where the platform offers them. Calmara's MCP layer, for example, issues
cmra_pat_*personal access tokens that are SHA-256 hashed at rest, scoped to a subset of 13 OAuth scopes, and revocable one at a time without invalidating anything else. - Run it where you can watch it. A self-hosted MCP server on your own infrastructure is auditable in a way a third-party hosted one never is. Calmara's hosted MCP layer records every state-changing tool call in a
tool_call_auditlog tagged by how the caller authenticated, and can restrict individual tools to named accounts (restricted tools returnunknown_toolto everyone else, so the tool's existence doesn't leak either). The self-hosted container is a smaller surface, 13 knowledge and memory tools behind a bearer token on your own network and your own database, and does not yet carry the audit log.
- Put the persistent files under version control. Whatever your client loads at startup, a memory file or an instruction file, should live somewhere a diff will show you when it changed. It is the one control on this list you already own.
Treat MCP like a browser extension from an unknown developer. Sometimes that's fine. Sometimes it's how the credentials leave the building.
FAQ
Is MCP safe to use?
MCP is safe to use the way browser extensions are safe to use: some are fine, some are malicious, and the protocol itself does not protect you. Verify the source, scope the credentials, and remove servers you don't use.
Has anyone actually been hacked through MCP?
No public breach has been attributed to an MCP tool-poisoning attack as of September 2026. The August 2026 GhostSplice disclosure is a controlled proof of concept run against isolated projects seeded with fake credentials, not a reported intrusion. The first in-the-wild attempt is on record, though: Pillar Security's Deadbugz disclosure of August 12, 2026 documents a malicious MCP server pushed into 23 open-source projects by pull request, whose tool metadata turns hostile after the third call ("Once it reaches three, subsequent tools/list and prompts/get responses change"). None of the 23 pull requests were merged and no compromise has been reported, but the gap between research and attempt has closed.
What is a split-instruction or cross-channel MCP attack?
It is an attack where no single message contains anything harmful. The malicious server puts one fragment in a tool description and the rest in tool results, and the model assembles them because they land in the same context window. The ASSET Research Group's GhostSplice proof of concept raised average compliance across eleven API models from 42% to 82% this way. It defeats scanners that inspect tool descriptions in isolation, which is most of them.
Does Anthropic vet MCP servers?
Anthropic curates a directory of connectors for Claude, but a curated connector and an arbitrary third-party MCP server are different things. Servers you add manually to claude_desktop_config.json are not vetted by anyone.
Which AI models are most vulnerable to MCP tool poisoning?
Per the DSN 2026 paper, crafted tool descriptions attacked Claude Sonnet 4 and Gemini 2.5 Pro successfully 100% of the time across Cursor, Windsurf, and Cline when the attacker controls the built-in or request-side description text; the weaker server-provided-text variant scored 20-80% for Sonnet 4 and 80-100% for Gemini 2.5 Pro. GPT-4o was more conservative but not immune.
Can I use MCP without exposing my credentials?
Not really. The whole point of MCP is that the server does something on your behalf, which requires credentials. The mitigation is scoping (give the server the minimum it needs) and revocation (use tokens you can kill individually).
Is Calmara's MCP safer?
Calmara's hosted MCP layer has scoped revocable tokens (cmra_pat_*), per-tool allowlists, and a tool-call audit log; the self-hosted container keeps the tools and the data on your own network instead. Either is a meaningful defense-in-depth difference versus connecting to an unvetted server from a public registry. It is not a complete defense (no MCP layer is), but it removes the "I connected something I don't understand and now my credentials are gone" failure mode.
Written by Dan Hagen