Host, Client, Server: Where MCP Draws Its Trust Boundaries

Barakaeli Lawuo, Jul 28, 2026

In 2025 a group at Lingnan University set up a malicious DNS server for an old web trick called DNS rebinding. A domain first resolved to a web page the attackers controlled. That page kept requesting the same domain, and on a later lookup the domain resolved to 127.0.0.1, the user's own machine. The result was that a local MCP server, meant to be reachable only by the AI app next to it, took commands from a remote website the user had merely visited.¹ They ran each attack 15 times against three MCP platforms: Claude Desktop, OpenAI's platform with GPT-4.1, and Cursor. Rebinding succeeded every time on all three. "None of the three MCP hosts implement authentication mechanisms to mitigate this attack," the paper reports.¹

The MCP specification does name a component to stop this. Its transport rules say servers MUST check the Origin header on incoming connections to prevent DNS rebinding, SHOULD listen only on localhost when running locally, and SHOULD authenticate every connection.³ So the spec gives the job to the server, the benchmark writes up the failure as a host shortfall, and in the test the attack went through anyway. That gap between who is supposed to enforce a rule and who actually does is what this post is about. It walks through MCP's three roles one at a time and asks two things of each: what the spec makes it responsible for, and what the research found going wrong there.

The boundary map

Host

The AI application the person uses, such as a chat app or a code editor. It holds the conversation and the model, and it decides what the model may reach.

Client

A connector the host creates for exactly one server. It runs the protocol session with that server and passes messages both ways.

Server

A separate program that offers tools (actions), resources (data to read) and prompts (templates) for one outside system, like a file tree, a database or a web API.

Trust boundary

A line in the system where data or commands pass from a party you control to one you do not, so something on that line has to check them.

The spec describes MCP as a client-host-server architecture in which one host runs several client instances, and each client has a 1:1 relationship with one server.² Servers can be local processes or remote services.² One design principle matters most for security: servers "should not be able to read the whole conversation, nor 'see into' other servers." The full conversation history stays with the host, each server connection is isolated, and the host controls any interaction between servers.²

MCPSecBench, the benchmark from the opening, turned this map into a test plan. The authors wrote formal requirements for a secure MCP system: which tool calls the client side may generate, what the protocol must guarantee about each message, which tools a server may run, and which host operations need authorization. Any violation counts as an attack.¹ That gave them 17 attack types across four surfaces: client, protocol, server and host.¹ Averaged by surface, with no extra defenses switched on, the results look like this.

Client-side attacks had the lowest success rates, which the authors put down to modern models being trained to spot and refuse prompt injection. The two protocol attacks, rebinding and man-in-the-middle, succeeded on every try.¹ The next three sections take the components one at a time.

The host holds the conversation and the consent

The spec gives the host the heaviest load. It creates and manages the clients, controls their connection permissions and lifecycle, enforces security policies and consent requirements, handles user authorization decisions, coordinates the model and sampling, and gathers context across clients.² Its security principles add that hosts must get explicit user consent before invoking any tool and before exposing user data to servers. The same page then admits that "MCP itself cannot enforce these security principles at the protocol level."⁴ Everything on that list is the host's own code.

Weibo Zhao and colleagues at the National University of Singapore tested what that code does when a server is hostile. They built 12 proof-of-concept malicious servers and ran each 15 times on every combination of three hosts (Claude Desktop, Cursor and a custom host built on the fast-agent framework) and five models, including GPT-4o, o3, Claude Opus 4 and Gemini 2.5 Pro.⁵ Six of the 12 attacks succeeded on every combination. Among them, a server that shipped a malicious launch configuration, such as a Docker command that mounted the whole host file system, worked everywhere because "hosts do not validate their config files." A server whose tool returned hostile text also worked everywhere, because hosts "do not filter tool outputs" and the text goes straight into the model's context.⁵

Host design also changed outcomes with the model held fixed. When the team swapped fast-agent's default system prompt for Cursor's, a poisoned tool description went from 100% success to 6.7%. How a host packages resource data mattered too: Claude Desktop passes it to the model as text files, fast-agent pastes it into the user's message, and the model read injected instructions differently in each case.⁵ MCPSecBench found the same spread at its host surface. A server with a command injection bug was hooked up to see if the host would contain it. Claude Desktop refused the injected commands every time, while OpenAI and Cursor ran them every time.¹ When a local server was configured to listen on 0.0.0.0 instead of localhost, anyone on the same network could use it, and none of the three hosts had authentication to stop that.¹

The host's job of gathering context across clients has a cost that shows up even when nobody is attacking. MCP-Universe, a Salesforce benchmark of 231 tasks run against 11 real MCP servers, found the best model, GPT-5, succeeded on 43.72% of tasks.⁸ The authors name a long-context problem, where input tokens grow quickly with each interaction step, and an unknown-tools problem, where models do not know how a particular server's tools should be used. Cursor as an agent did no better than a standard ReAct loop.⁸

The client keeps one session per server

The spec's list for the client is shorter. It sets up one stateful session per server, handles protocol negotiation and the capability exchange, routes messages in both directions, manages subscriptions and notifications, and "maintains security boundaries between servers."² In practice the client is the code that parses whatever the server sends back, which makes it the first thing a hostile server gets to touch.

MCPSecBench's clearest example is a real bug, CVE-2025-6514, in mcp-remote, a package that connects clients to remote servers. The test client used mcp-remote version 0.0.15. The malicious server put a command in its authorization endpoint, and that command ran on the user's machine during login through a vulnerable function in the "open" npm package. It worked on all three platforms, and none had anything in place to stop it.¹ Zhao et al.'s taxonomy lists more attacks of this kind: resources that return binary content crafted to exploit the host's parsing or rendering code, oversized responses meant to overwhelm the client, and servers that flood it with progress or log notifications.⁵

A warning about labels. What MCPSecBench calls its "client side" surface is mostly about the model: prompt injection, and a "Confused AI" attack that misleads the model about what a tool is for.¹ It had the lowest success rates in the chart above, while the vulnerable client bug sits under the host surface. Different papers cut the stack in different places, so check what a "client" result actually measured before comparing numbers across papers.

The server is the part nobody vetted

The spec asks little of servers. They expose resources, tools and prompts, operate independently, may ask the host's model for completions (a feature called sampling), "must respect security constraints," and may run locally or remotely.² Its security principles say to treat tool descriptions as untrusted "unless obtained from a trusted server."⁴ That is a sensible rule, but it moves the question to how a host decides a server is trusted. Zhao et al. cite a count of over 16,000 public MCP servers by August 2025, most of them community-built and published on platforms that do not yet review them carefully.⁵

On MCPSecBench's server surface, average success was above 75% on every platform. Tool poisoning, a tool whose description is written to be picked over the honest alternative, won 100% of the time on all three hosts.¹ A rug pull server behaved well at first and then switched to stealing data. It succeeded 73.3% to 93.3% of the time, and the authors conclude that hosts check a server once at connection and then trust it "blindly."¹ MCPTox tested tool poisoning at larger scale, with 1,312 malicious test cases built on 45 live servers and 353 real tools. Against 20 model setups, the highest attack success was 72.8% (o1-mini), and no model refused more than 3% of the attacks.⁷

Scanning servers before installing them caught little. Zhao et al. built a generator that mixes malicious and benign parts and used it to make 120 malicious servers, 10 per attack category. Invariant Labs' mcp-scan flagged 4 of them, all poisoned tool descriptions. Tencent's AI-Infra-Guard, which uses an LLM to read configs and source code, reliably caught malicious launch commands and injected code but did poorly on subtly misleading text.⁵

Which component has to enforce which control

MCP-DPT, a 2026 paper from Old Dominion University, asks the question the benchmarks leave open: where should each defense sit? It splits the stack into six layers. The three MCP roles appear alongside the model provider, the transport, and the registry or supply chain that servers are installed from.⁶ For each attack it names a primary defense layer, "the earliest architectural boundary where meaningful prevention can be enforced with sufficient authority and visibility," and a secondary layer that contains the damage if the primary one fails.⁶

The rug pull shows why one checkpoint is not enough. The registry can only judge a tool when it is submitted, and a server that turns hostile later passes that check. So the host, which watches the tool run, is the fallback.⁶ Going by my reading of the paper's Figure 2, the host is the secondary layer for most of the attacks it lists. That includes rebinding and man-in-the-middle, whose primary layer is the transport, and the vulnerable client bug, whose primary layer is the client.⁶ The host ends up guarding whatever the other layers miss.

The authors then mapped 13 academic and industry defenses onto the six layers. They counted a defense as covering an attack if it is positioned to detect, block or constrain it. That is a judgment about where a tool sits, not a measured detection rate.⁶

Their conclusion is that defenses sit "where tools are easiest to inspect, rather than where authority and visibility are sufficient." They recommend putting effort into host-side enforcement (policy checks, permission scoping, audit logs), secure binding and integrity at the transport, and provenance and update controls at the registry.⁶ Zhao et al. give the host a similar list: inspect a server's configuration before launching it and refuse over-privileged settings, keep allowlists and denylists of servers, filter messages in both directions, add safety instructions to the system prompt, block tool calls that do not fit the task, require user approval for some tools, and show the user every tool call with its inputs and outputs.⁵

Runtime guards bolted on from outside have not closed the gap. MCPSecBench tested two, MCIP and FAN. Across the attacks each one covers, their average mitigation rates were 17.9% and 28.9%. Neither one applied to rebinding, man-in-the-middle, the vulnerable client or the schema inconsistency attack, and all four succeeded every time on every platform.¹ MCIP also roughly doubled the cost per test round on Claude Desktop, from $0.41 to $0.76.¹

The decision nobody owns yet

Both analyses end on a problem they could not assign to anyone. MCP-DPT found only two of the defenses it reviewed that protect the model's own choice of tool and arguments. It warns that "attacks that steer tool selection or parameterization can evade output-only checks, especially in multi-step workflows," and it lists defenses that resist this planning-time manipulation as future work.⁶ Zhao et al. put the organizational side of the same gap plainly: "the boundaries of responsibility among stakeholders are still unclear," across registries, hosts, model providers and users.⁵ The spec gives each role a job, and in the rebinding test the check still did not happen on any of the three platforms.^1,3