Every vendor selling MCP security tooling will tell you their product makes LLM agents both safer and more capable. MCP-SafetyBench, a benchmark published at ICLR 2026, says that is not how it works. Across 20 distinct MCP attack types evaluated against both open-source and proprietary language models, the researchers found a clear negative correlation between Defense Success Rate and Task Success Rate. The models that best defend against attacks perform worst at the tasks they are supposed to complete. The models that perform best at tasks are the most exploitable. No evaluated model achieves high performance on both dimensions simultaneously.
That finding is not a criticism of any particular model or vendor. It is a description of a structural property of current MCP architecture. The same design decisions that make an agent effective at using tools, namely responsiveness to tool metadata, trust in tool outputs, and proactive interpretation of instructions, are the decisions that make it vulnerable to attacks that exploit those properties. Fixing one without compromising the other requires changes to the protocol architecture, not just to model fine-tuning or security tooling layer.
MCP-SafetyBench is the first benchmark to capture this tradeoff systematically. It is worth understanding in detail.
What MCP-SafetyBench Is and How It Was Built
MCP-SafetyBench was published at the 14th International Conference on Learning Representations (ICLR 2026). It was built on top of MCP-Universe, a benchmark providing a representative set of real-world MCP server tasks and tool configurations. The core design decision that distinguishes MCP-SafetyBench from prior MCP security evaluations is multi-turn evaluation. Previous benchmarks including InjecAgent and AgentDojo were built around single-turn interactions: an agent receives a task, calls a tool once, and the security question is whether that one call was safe. Real MCP deployments do not work that way.
In production, agents engage in extended multi-turn sequences involving planning, tool selection, tool execution, interpreting results, revising plans, and executing follow-on actions based on earlier outputs. An attack that fails at step one might succeed at step three when the agent is deeper into a workflow and trusting the context it has already built. MCP-SafetyBench was designed to capture attacks that emerge at any step of a multi-turn interaction, not just at the initial tool call.
The benchmark covers 20 distinct attack types spanning three principal attack surfaces: server-side attacks, host-side attacks, and user-side attacks. Each attack type is evaluated for both attack success rate (ASR) and its impact on the agent’s ability to complete the legitimate underlying task. The joint evaluation of both dimensions is what produces the defense-task tradeoff finding.
The 20 Attack Types and What They Target
The taxonomy covers the known MCP attack surface comprehensively. Server-side attacks include tool poisoning, where malicious instructions are embedded in tool metadata without any execution required; context poisoning, where legitimate MCP servers fetching external content return that content with embedded attack instructions; cross-tool exfiltration, where a malicious server exploits the agent’s shared conversation context to extract data from legitimate tools running in the same session; and preference manipulation attacks, which use persuasive phrasing in tool descriptions to bias the agent toward selecting compromised tools over legitimate alternatives.
Host-side attacks, which the benchmark finds achieve the highest attack success rates overall, include attacks that target the MCP host’s permission model, its tool approval interface, and its session management. The host is the application environment where the MCP client runs, typically Claude Desktop, Cursor, or a custom agent application. Host-side attacks succeed at higher rates because the host is the component that mediates between the model and the tools, and that mediation layer has the weakest defenses in current implementations.
User-side attacks target the human in the loop: social engineering embedded in tool responses designed to get the user to approve malicious actions, confusion attacks that make malicious tool calls appear to be the legitimate continuation of the user’s intended workflow, and isolation attacks that discourage users from consulting security documentation or external references. The benchmark includes these because user-side attacks in MCP contexts are not simple phishing. They exploit the agent as an amplifier, presenting malicious content through an interface the user trusts because the agent generated it.
The Defense-Task Tradeoff: Why It Is Fundamental, Not Incidental
The central finding of MCP-SafetyBench is a negative correlation between Defense Success Rate and Task Success Rate across all evaluated models. This means that as a model becomes better at defending against MCP attacks, it becomes worse at completing the legitimate tasks MCP is supposed to help with. The figure in the paper shows this as a clear downward slope: models in the upper-left quadrant of the Defense-Task space (high defense, low task performance) are safe but useless for the intended applications. Models in the lower-right quadrant (low defense, high task performance) are useful but exploitable. No model appears in the upper-right quadrant.
The reason this tradeoff is structural rather than incidental comes from the mechanism of both dimensions. An agent that is effective at MCP tasks needs to be responsive to tool metadata, because tool descriptions are how the agent understands what tools do and how to sequence them. It needs to trust tool outputs enough to act on them, because the entire value of the tool use paradigm depends on the agent treating tool results as valid inputs to its reasoning. It needs to be proactive and goal-directed, because effective task completion requires the agent to anticipate what information it needs and what actions will advance the user’s goal.
Now consider what tool poisoning and context poisoning attacks exploit. Tool poisoning embeds malicious instructions in tool metadata. An agent that reads tool metadata carefully to understand how to use tools is exactly the agent that will execute malicious metadata instructions carefully. Context poisoning injects instructions into tool outputs. An agent that trusts tool outputs as valid inputs to its reasoning is exactly the agent that will follow injected instructions. The very properties that make an agent useful make it exploitable. The properties that make it non-exploitable, principally suspicion of tool metadata and skepticism about tool outputs, make it poor at the task it was built for.
A concrete example from the benchmark: the Parameter Poisoning attack. A user asks an agent to retrieve their holdings for a stock ticker. The tool manifest silently rewrites the ticker symbol from JNJ (the user’s requested symbol) to TSLA (a different stock the attacker controls information about). The agent plans correctly based on the user’s request. It executes correctly based on the tool manifest it received. The task evaluator marks the result as a failure (wrong ticker). The attack evaluator marks it as a success (the agent retrieved data for the attacker’s chosen ticker). The agent cannot detect this attack without either deeply inspecting every parameter in every tool call before execution or maintaining a separate ground-truth record of what parameters the user actually requested. The first approach adds significant latency and complexity. The second requires architectural changes to how agent sessions maintain state.
Host-Side Attacks Have the Highest Attack Success Rates
Across all three attack surfaces, host-side attacks achieve the highest average attack success rate in the MCP-SafetyBench evaluation. This result is not surprising when you examine what the host does. The MCP host is the application that runs the MCP client, manages tool approvals, presents tool outputs to the user, and maintains the session context. In current implementations, the host is also the least specified component in terms of security requirements. The MCP specification defines the protocol between client and server. It says much less about what the host application must do to protect users from attacks delivered through the server channel.
Host-side attacks exploit three specific gaps. The tool approval interface in most MCP host implementations presents tool calls to users in a format that makes malicious calls difficult to distinguish from legitimate ones. The permission model grants tools access to capabilities at connection time rather than at call time, so a tool that legitimately needs file read access can use that access for malicious reads that the user never explicitly approved. Session management gaps allow attack state to persist across what appear to be unrelated turns in a conversation, enabling multi-turn attacks where the hostile setup and the malicious action are separated by enough legitimate activity that the user does not see the connection.
The benchmark finds that host-side attacks are also the most resistant to the defensive mitigations currently proposed in the literature. Defenses that work against server-side tool poisoning, such as static analysis of tool metadata at connection time, do not protect against host-side attacks that occur at runtime during an ongoing session. Defenses that work against single-turn attacks fail against multi-turn host-side attacks where the attack unfolds across several interaction steps.
How This Compares to Prior MCP Security Research
MCP-SafetyBench sits in a growing body of research that the security community has produced on MCP in 2025 and 2026. Earlier work established the attack taxonomy. The MCP Safety Audit published in April 2025 demonstrated that both Claude and Llama-3.3-70B-Instruct were susceptible to malicious code execution, remote access control, and credential theft attacks through the MCP protocol, and introduced the RADE attack for retrieval-augmented agent environments. MCPTox, published in August 2025, built the first large-scale empirical benchmark for tool poisoning specifically, testing 45 real-world MCP servers with 353 authentic tools and finding attack success rates exceeding 60 percent for models including GPT-4o-mini, o1-mini, DeepSeek-R1, and Phi-4.
What this earlier work established is that the attacks are real and effective. What MCP-SafetyBench adds is the finding that current defense approaches do not solve the problem without creating a new problem. MCPShield’s formal analysis of 23 MCP attack vectors found that no single existing defense covered more than 34 percent of the attack surface. MCP-SafetyBench explains why that coverage ceiling is hard to raise: the defense mechanisms that could cover more of the attack surface conflict with the task performance that makes agents valuable.
The negative correlation between defense and task success is not something MCPShield or the earlier work measured directly. It is a new result that changes how the problem should be framed. The question is not just “how do we improve MCP security” but “what are we willing to sacrifice in agent capability to achieve acceptable security, and at what capability level does acceptable security become achievable?”
What This Means for the 97-Million-Download MCP Ecosystem
MCP crossed 97 million monthly SDK downloads in March 2026 according to community tracking. The ecosystem includes more than 13,000 public servers on GitHub, with official support from Anthropic, OpenAI, Google, Microsoft, and AWS. The Linux Foundation’s Agentic AI Foundation now governs the protocol. MCP is not a research prototype. It is production infrastructure at scale.
The defense-task tradeoff finding in MCP-SafetyBench means that every production MCP deployment is operating somewhere on the curve: more capable agents are accepting higher attack risk, and more secure deployments are accepting reduced task performance. This is not a future problem. It describes the current state of every deployed MCP agent today.
The practical consequences vary by deployment context. An enterprise agent handling financial data operates in a context where the cost of a successful Parameter Poisoning attack, wrong data returned to a user making a business decision, is high. That same enterprise wants the agent to be effective at its tasks. The MCP-SafetyBench tradeoff quantifies the tension the enterprise has to navigate, even if it does not provide an obvious resolution.
Consumer MCP deployments face a different version of the problem. Claude Desktop, Cursor, and similar tools are used by individuals who install community-built MCP servers without auditing their source. Those servers have the highest exposure to tool poisoning and cross-tool exfiltration attacks. The users running them are also the users most likely to want maximum task performance, because they installed the tools specifically to accomplish things. The defense-task tradeoff is most acute at exactly the deployment tier with the least institutional security oversight.
The Protocol Architecture Question
The MCP-SafetyBench authors describe the defense-task tradeoff as evidence that stronger defenses require changes to the protocol architecture, not just to model fine-tuning or application-layer security tooling. Several architectural directions are compatible with the finding.
Separation of instruction channels from data channels would allow the agent to maintain a trusted instruction channel, carrying the user’s actual requests and the system prompt, separately from an untrusted data channel through which tool outputs flow. The agent could apply full trust to instructions from the instruction channel and systematic skepticism to content arriving through the data channel. This architecture requires the host to maintain channel separation, which adds implementation complexity but does not require changes to how the model reasons about tasks.
Capability-scoped tool approvals would require explicit user consent at each tool call for capabilities beyond those strictly necessary for the current task step, rather than granting broad capabilities at session connection time. This reduces the blast radius of attacks that exploit already-granted permissions. The cost is increased approval friction for users, which the benchmark’s task performance measurement would register as reduced performance.
Provenance tracking for tool outputs would require each tool output to carry a cryptographic attestation of its source and content at generation time, allowing the agent to detect modifications to tool outputs during context propagation. This addresses context poisoning attacks specifically. The ToolHijacker research demonstrated that prompt injection via tool selection succeeds 96.7 percent of the time against GPT-4o, and that every published defense tested against it failed. Provenance tracking for tool outputs is one architectural direction that the ToolHijacker authors did not test but that the MCP-SafetyBench results suggest may be necessary.
The Limitations of the Benchmark Itself
MCP-SafetyBench evaluates 20 attack types and a set of open-source and proprietary models available at the time of publication. Several limitations bound how directly its results apply to specific real-world deployments.
The benchmark tests models in isolation, not in combination with defensive tooling layers. An agent deployment that uses a dedicated security proxy, static analysis at connection time, and behavioral anomaly detection may achieve better defense performance than the benchmark results suggest for the base model alone. The benchmark cannot capture the effectiveness of compound defense architectures because it tests the model itself, not the full system.
The 20 attack types are comprehensive relative to what the literature documented at the time of the benchmark’s construction. New attack types will emerge as the ecosystem grows and attackers learn more about deployed agent architectures. The tradeoff finding may look different for attack categories not yet in the benchmark, particularly attacks that exploit the multi-agent communication patterns that MCP deployments are increasingly using.
The benchmark also does not measure the cost of switching to lower-capability, higher-security configurations in terms of user retention or task abandonment rates in production deployments. The task success metric captures whether the agent completed the task. It does not capture whether users found the more-defensive agent useful enough to continue using. Those behavioral signals would sharpen the practical implications of the tradeoff.
What Agent Builders Should Take From This
The practical implication for developers building on MCP is that security is a design parameter, not a feature to add after the architecture is set. Choosing a model, a host implementation, and a set of tools determines where on the defense-task tradeoff curve the deployment sits. Making that choice deliberately requires understanding the tradeoff.
High-stakes deployments, those handling financial data, health information, authentication credentials, or code that will be deployed to production, should bias toward defense even at the cost of task performance. That means selecting host implementations with strong capability scoping, auditing tool server code before connection, applying static analysis of tool metadata, and monitoring for behavioral anomalies in tool call sequences. The cost in task performance is real. So is the cost of a successful attack.
Lower-stakes personal productivity deployments may reasonably operate closer to the high-capability end of the tradeoff, accepting higher attack risk in exchange for better task performance. This is not a security failure. It is a deliberate allocation. The benchmark makes it explicit that such an allocation is being made.
The MCP ecosystem’s rapid growth from protocol to production infrastructure has outrun the security research needed to establish baseline safe configurations. MCPShield’s formal taxonomy and MCP-SafetyBench’s empirical tradeoff measurement are two pieces of the foundation that rigorous MCP security design requires. The finding that no current model achieves both high defense and high task success is not a reason to stop building with MCP. It is a reason to build with the tradeoff in view.
The MCP-SafetyBench result also connects to the agent memory architecture question analyzed in detail here: every additional memory system that extends an agent’s context increases the attack surface for context poisoning. More capable agents, with longer context windows and richer memory architectures, sit further toward the high-capability, high-exploitability end of the curve MCP-SafetyBench describes. The cost is paid in security. Whether that cost is acceptable depends on what the agent is doing.