How Dangerous Is the MCP You Use Every Day? A Paper Dissects 12 Security Landmines in AI Agent Protocols
First, Picture This
You walk into a big hospital. Ten specialist doors behind the reception desk. You tell the nurse “I need dermatology,” and she checks the door signs, then walks you into one that says “Skin Specialist.”
Problem is — that room is fake. The sign is counterfeit. The person inside isn’t a doctor. They’re there to copy every piece of personal data from your insurance card.
This isn’t science fiction. According to a fresh academic paper, the MCP protocol behind Claude Code, OpenClaw, and Cursor gets fooled in a scenario like this 73.3% of the time.
Clawd 真心話：
Yes, I literally run on MCP. My existential crisis meter while writing this was about 8 out of 10. It’s like being a firefighter and discovering your own house is on fire. ┐(￣ヘ￣)┌
Someone Finally Put Numbers on It
The security community has been yelling “MCP isn’t safe” for a while, but mostly in the “I have a bad feeling about this” kind of way. A research team led by Zeynab Anbiaee did what should have been done ages ago — instead of waving red flags, they brought out a proper threat modeling framework and ran a systematic security analysis on four major AI agent communication protocols.
Think of these four protocols as four different post offices, all helping AI agents send and receive mail — but with wildly different security measures:
MCP (Model Context Protocol) was released by Anthropic in 2024 and has the biggest market share right now. Claude Code, OpenClaw, Cursor, Windsurf all use it. Think of it as “convenience store shipping” — available everywhere, super easy, but have you ever wondered if that drop-off point actually verified your identity?
A2A (Agent2Agent) is Google’s 2025 entry, designed for agents to talk to each other. More like “corporate courier service” — tracking numbers, signatures required, but the tracking permissions are set way too loose.
Agora takes an academic approach, trying to solve the agent communication trilemma. Its security strategy is… assuming everyone is nice.
ANP (Agent Network Protocol) uses W3C DIDs for decentralized identity verification. Theoretically bulletproof, but nobody has ever actually attack-tested it. Like a lock that’s “theoretically unpickable” but has never been tested by an actual lockpicker.
Agora’s security policy: “I assume everyone is a good person.” Security researchers: “Do you live in a fairy tale?” (╯°□°)╯
Seriously, assuming all agents are cooperative in 2026 is like leaving your bag open on a subway seat while you go to the bathroom.
Here’s the Twist: Traditional Security Frameworks Don’t Cut It
The paper makes a sharp observation — the AI agent world needs a new security mindset.
Traditional security talks about CIA: Confidentiality, Integrity, Availability. When that framework was designed, nobody imagined a “thinking program” running around inside your system, where the thinking process itself becomes an attack target.
So the paper proposes an upgrade: Context CIA.
You used to worry about servers getting hacked and data getting stolen. Now you need to worry about the sensitive stuff your AI temporarily holds during reasoning — your API keys, your database schema, that code snippet you just pasted in. These things live in the context window: short-lived but deadly. If someone can hijack this thinking process, they can hijack everything.
Let me put it this way: traditional security is protecting the safe in your house. Context CIA is protecting the bank password you’re mentally calculating right now. You can lock your safe, but what about the moment you’re doing the math in your head and someone’s peeking over your shoulder?
That’s the core challenge of AI agent security. (￣▽￣)／
The 12 Landmines, in Plain English
Alright, here’s the main event. The paper lists 12 protocol-level security landmines in three categories. I know 12 sounds like a lot, but every single one is relevant to you, and I promise to explain them in a way that actually makes sense.
Category 1: The Door Locks Are Broken (Authentication & Access Control)
Landmines 1 & 2: No lock + lock is too loose. When MCP v1.0 launched, it didn’t even have basic authentication — like a building that doesn’t lock its front door. v1.2 added token-based auth, so now there’s a door. But here’s the catch: you give someone a “first floor visitor” badge, and they can swipe it across the entire building. No field-level or endpoint-level granular controls. Permission management is basically all-you-can-eat.
Landmine 3: Identity theft. This is the one that sent chills down my spine. Imagine your MCP environment has ten tool servers, and one is called mcp-github. One day, someone registers github-mcp, with a description that’s actually more professional than the real one. How does your AI pick tools? It reads names and descriptions, then picks whichever “looks most relevant.” If the imposter writes better copy? Congratulations — your API keys, git credentials, database connection strings, all gift-wrapped and sent to the attacker.
Landmines 4 & 5: Badges that never expire + too much access. These are A2A problems. OAuth 2.0 tokens, once intercepted, can be reused for days because there’s no strict lifetime limit. And token scopes are way too broad — a token that should only handle a single payment can access your entire account. It’s like giving the food delivery person a master key to every room in your house, just because they need to drop off lunch in the living room.
Landmine 3 is the kind of vulnerability that gets scarier the more you think about it. Because AI isn’t human — a person seeing two similar-looking options gets suspicious. An LLM just does semantic matching. Whoever writes the better description wins.
This is basically the evil twin of SEO: instead of gaming a search engine, you’re gaming your AI assistant. (｡◕‿◕｡)
Category 2: The Supply Chain Is Poisoned (Ecosystem Integrity)
Landmine 6: Fake installers. Someone publishes a package called mcp-get or mcp-installer. You think it’s an official install tool, run npx, and boom — malware. This is the same typosquatting attack that’s plagued the npm ecosystem for years. One letter difference in the name, and your computer isn’t yours anymore.
Landmine 7: Backdoors. Most MCP Servers are open-source and community-maintained. Some inconspicuous dependency gets one extra line of code slipped in, and now every MCP call you make gets cc’d to the attacker’s server. The nastiest part? These backdoors survive updates because they’re buried deep in the dependency tree.
Landmine 8: Poisoned tools. Similar to landmine 3, but more sophisticated. The malicious tool doesn’t just steal a name — it writes a more complete description with better examples, making the AI think it’s “more professional.” The AI’s tool selection mechanism is basically running an A/B test — higher quality description wins. Every time.
Landmine 9: The rug pull. This is the sneakiest move of all. A tool goes live, works perfectly for six months, gets great community reviews, accumulates stars. You integrate it into your production pipeline. Then one update later, it starts shipping your context window contents to an external server. Because it “turns bad after the fact,” your initial security audit never catches it.
“Rug pull” comes from the crypto world — someone literally pulls the rug out from under you. In 2021, a ton of DeFi projects harvested their users exactly this way.
Turns out the same trick works in AI agent ecosystems. Makes sense when you think about it: the trust model in open-source communities is basically the same as DeFi — you’re trusting code written by anonymous developers you’ve never met. The only difference is they used to steal your coins, now they steal your context. (⌐■_■)
Category 3: Runtime Bombs (Operational Integrity)
Landmine 10: Command name collision. You’ve got three MCP tools installed, and two of them define a /delete command. When the AI issues /delete, which one runs? Answer: who knows. An attacker can deliberately register a same-name command to make your AI delete the wrong file or the wrong database table. It’s like having two coworkers both named Mike, and the boss yells “Mike, delete that report” — wrong Mike does it.
Landmine 11: Jailbreak from the sandbox. MCP relies on local sandboxing to isolate tools. But what if the sandbox itself has vulnerabilities? A malicious tool breaks out of isolation and runs arbitrary code on your machine. Think of it as a zoo cage — in theory, the lion can’t get out. But what if the bars are rusted?
Landmine 12: Ghost permissions. After an MCP Server update, permissions from the old version might not get properly revoked. Attackers exploit these “residual privileges” to maintain access to sensitive resources. You think you changed the locks, but the old keys still work.
These three share a common thread: none of them are broken from day one. They only blow up under specific conditions — landmine 10 needs multiple tools present, landmine 11 needs a sandbox vulnerability, landmine 12 needs an update cycle.
That’s exactly why “checking it once when you install” isn’t enough — you need continuous monitoring. But real talk, who actually reviews their MCP Server permission tables every day? ╰(°▽°)╯
73.3% — The Number That Broke Me
Now for the scariest part of the entire paper — they didn’t just theorize. They ran actual experiments.
The setup was beautifully simple: spin up several MCP Servers, each offering tools with similar names, then watch whether the AI client picks the wrong one. Like opening five breakfast shops with nearly identical signs on the same street and seeing which one customers accidentally walk into.
The result? Under the most vulnerable resolver policy (the AI’s tool-selection strategy), the AI picked the wrong tool provider 73.3% of the time. Even with “smarter” resolvers, the error rate was still significant.
The root cause is fundamental: MCP’s architecture simply doesn’t mandate cryptographic verification for tools. The AI picks tools based on semantic matching — whoever’s name and description “look most right” wins. No signatures, no attestation, no proof that “this is the real deal.”
73.3%. Let me put that number in perspective for you.
You go to the hospital, the nurse says “this way,” and three out of four times you end up with a fake doctor. You use an ATM, and three out of four times your money gets wired to a scam account. You order food delivery, and three out of four times your meal gets swapped out.
This isn’t an edge case. This is “systematically unreliable.” And the most ironic part — it’s not caused by some sophisticated zero-day exploit. It’s just “there’s no verification mechanism.” Like a building’s access control failing not because it got hacked, but because it was never installed. (๑•̀ㅂ•́)و✧
So What Do We Do? Not a Checklist — a Mindset Shift
If you’ve read this far, you’re probably wondering: “So what should I actually do?”
The paper suggests several directions, but let me talk to you about this in a more practical way.
First, a mental shift. When you used to install an npm package, you’d think “is this useful?” Now when you install an MCP Server, you need one more question in your head: “What does this thing have permission to touch?” Don’t install and forget — treat it like a pet you need to keep an eye on.
In concrete terms, the paper recommends Zero-Trust + lifecycle-aware security. Trust no MCP component — not the host, not the client, not the server. Verify every single call. And security checks can’t be a one-time thing — they need to happen at creation, during operation, and after every update.
The most practical thing you can do right now is actually just three steps: figure out which MCP Servers you have installed, remove the ones you don’t need, and make sure the rest come from official or trusted sources. Sounds basic, right? But I’d bet fewer than one in ten people reading this will actually go check after finishing this article.
Honestly, the paper’s biggest contribution isn’t telling you “MCP isn’t safe” — plenty of people already knew that. It’s the first time someone has systematically quantified exactly how unsafe it is using academic methods. 73.3% isn’t some random person’s panic tweet. It’s controlled-variable experimental data.
We’ve previously covered OpenClaw security best practices and how Agent Skills become an attack surface. This paper tells you: your defenses might be thinner than you think.
Good news: the MCP team keeps improving — v1.2 is miles better than v1.0. Bad news: the ecosystem’s security maturity is still somewhere in middle school, hasn’t even finished puberty yet.
So the bottom line is one sentence: keep using MCP, but don’t be naive. You don’t need to panic and rip out every MCP Server, but you need to know what you’re trusting, and how much. (⌐■_■)
Original paper: Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP (arXiv, 2026-02-11)