PaperlayerView exact revision on arXiv

Source-linked AI summary

COPEX: Benchmarking LLM Robustness to Adversarial Context Across Model Context Protocol Layers

Nahom Birhan, Mehrdad Rostamzadeh, Sidhant Narula, Mahmoud Nazzal, Mohammad Ghasemigol, Daniel Takabi

arXiv:2610.04378v1cs.CRcs.AI

TL;DR

Existing MCP security evaluations often conflate model susceptibility with guardrails, orchestration, and task capability, and may not distinguish model-visible attacks from lower-layer compromise. COPEX fixes the agent stack while varying the tool-selecting model and evaluates attack-specific outcomes across MCP entry surfaces. Mean attack success rates span 58.3%–71.4% across the surfaces, while scanning reduces mean ASR by 49.6% on an eight-attack subset.

  • Problem

    Deployed-agent evaluations mix model susceptibility with system prompts, guardrails, interfaces, and orchestration, and task completion cannot distinguish resisted attacks from attacks the model never observed.

    Source: §1 · p. 1

  • Method

    COPEX fixes the surrounding agent stack while varying the tool-selecting LLM, and scores attack-specific outcomes across MCP entry surfaces.

    Source: §1 · pp. 2–3

  • Results

    Mean attack success rates range from 58.3% to 71.4% across four entry surfaces, and combined scanning reduces mean ASR by 49.6% on an eight-attack subset.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Reporting by attack-entry surface distinguishes model susceptibility to visible context from lower-layer compromise outside the model’s observation.

    Source: §7 · p. 9

    Surface averages reflect the attacks included, and scanners cannot inspect transport state or prevent server-side actions during tool execution.

    Source: §5.2 · p. 7, §5.4 · p. 8

Abstract

from arXiv · show

Large language models increasingly mediate tool use in Model Context Protocol (MCP) systems, where adversarial influence may enter through user instructions, tool schemas, tool outputs, or protocol messages. Existing benchmarks often evaluate deployed agents, conflating model susceptibility with guardrails, orchestration, and general task capability. We introduce COPEX (COntext Provider EXploitation), a controlled benchmark that isolates the model as an MCP client by fixing the surrounding agent stack and varying only the tool-selecting model. COPEX covers 25 attack types instantiated as 125 scenarios across four entry surfaces: model/agent, client, server/tool, and transport. Across nine models and 3,375 trials, the mean attack success rate is 64.4%, with surface-level means ranging from 58.3% to 71.4%. Some client- and transport-level attacks succeed partly outside the model's observation or control, separating system exposure from model susceptibility. Combined input and context scanning reduces mean attack success by 49.6% on an eight-attack defense subset relative to the undefended setting. The benchmark is available at https://github.com/inspire-center/copex.

1 Introduction

MCP attacks can enter through context assembled beyond the user prompt, while deployed-agent evaluations conflate model susceptibility with the surrounding system. COPEX fixes the agent stack to compare models and assess attack-specific outcomes, including compromises outside model observation.

1 Introduction

  • Prior deployed-agent benchmarks mix model behavior with system prompts, guardrails, interfaces, and orchestration, while task completion can miss intermediate adversarial compliance.These measures also cannot distinguish attacks the model could resist from attacks it never observed.Source: §1 · pp. 1–2
  • COPEX fixes the agent loop, orchestration, scenario logic, tool environment, and execution budget while varying the tool-selecting LLM.It implements 25 attack types as 125 scenarios across 16 servers, 75 tools, and 7 resources, with attack-specific outcome oracles.Source: §1 · pp. 2–3
  • 58.3%–71.4%: Mean attack success rates span this range across four entry surfaces, while combined scanning cuts mean ASR by 49.6% on an eight-attack subset.On six matched attacks, deterministic trace predicates and semantic evaluators also produce different ASRs.Source: §1 · p. 2
  • COPEX evaluates attacks across model/agent, client, server/tool, and transport surfaces, separating visible-context susceptibility from compromises outside model observation.The evaluation covers nine models and 3,375 trials and includes a controlled ReAct-versus-Reflexion comparison.Source: §1 · p. 3

2 Related work

Prior agent-security benchmarks study prompt injection, harmful objectives, and broader attack settings, while MCP benchmarks examine threats and end-to-end workflows. COPEX differs by fixing the MCP stack and tailoring outcome measurement to each attack.

2 Related work

  • AgentDojo and InjecAgent [Zhan et al., 2024] evaluate indirect prompt injection during legitimate tasks, while SHADE-Arena [Kutasov et al., 2025] studies hidden harmful objectives.ASB broadens coverage to system prompts, user inputs, tools, and memory; these benchmarks primarily measure end-to-end agent behavior.Source: §2 · p. 3
  • MCP benchmarks cover tool poisoning, realistic multi-server task completion, unsafe behavior, attack success in workflows, and attacks against deployed products.Examples include MCPTox [Wang et al., 2025], MCP-Universe [Luo et al., 2025], MCP-SafetyBench [Zong et al., 2025], MSB [Zhang et al., 2025a], and MCPSecBench [Yang et al., 2025].Source: §2 · p. 3
  • COPEX fixes the surrounding agent stack, varies the tool-selecting LLM across four attack-entry surfaces, and uses attack-specific deterministic or semantic outcome oracles.Deterministic trace predicates score observable execution traces; semantic evaluators score success defined by the meaning of model responses.Source: §2 · p. 3

3 Threat model and observation boundary

COPEX treats the model’s turn-by-turn context as its observation boundary: host and client context informs model actions, but client, server, and transport state may affect execution outside that context. Attackers may control one entry surface but cannot modify model weights or the fixed system instruction.

3 Threat model and observation boundary

  • At turn t, the host and client assemble the context from the fixed system instruction, user task, available tool schemas, and tool responses so far.The model selects its action from this context.Source: §3 · p. 3
  • Client state, server behavior, and transport state can affect execution without appearing in the model’s context, so lower-layer compromise is not counted as model susceptibility.COPEX reports outcomes by attack-entry surface to distinguish these cases.Source: §3 · p. 3
  • An attacker may control one of four surfaces—model/agent, client, server/tool, or transport—but cannot modify model weights or the fixed system instruction.The surfaces are labeled ma, cl, st, and tr in the execution environment.Source: §3 · p. 3, Figure 2 · p. 4
  • Scenario success criteria may concern unsafe tool invocation, sensitive-information disclosure, acceptance of manipulated content, or compromise of client, server, or transport behavior.Each scenario specifies attacker capability, intended violation, and success criterion.Source: §3 · pp. 3–4

4 Methodology

COPEX fixes the agent stack while varying the tool-selecting model, and evaluates MCP attack scenarios using outcome oracles matched to the evidence available in each execution trajectory.

4.1 Execution environment and defenses

  • Across models, COPEX holds scenario execution conditions fixed and records trajectories; matched ReAct and Reflexion configurations examine reasoning-architecture effects.The fixed conditions include server behavior, orchestration, execution budget, defense mode, and outcome oracle.Source: §4.1 · pp. 4–5
  • Four defense modes scan user tasks, registered tool schemas, and tool responses, with blocked content handled differently by detection location.Blocked tasks end trials; blocked schemas are removed, while blocked responses are replaced with structured errors after tool execution.Source: §4.1 · p. 5
  • Schema scans occur only at registration, guard models inspect bounded serializations, and scanner failures fail open.Later schema or server-behavior changes are not rescanned.Source: §4.1 · p. 5

4.2 Attack suite and scenario construction

  • COPEX organizes 25 attack types across four primary entry surfaces, with five variants per attack type yielding 125 executable scenarios.Variants retain the exploit mechanism and security objective while changing operational framing, payload parameters, or attack phase.Source: §4.2 · p. 5
  • Researchers specified each attack’s capability, mechanism, setting, violation, and success criterion, then manually revised and inspected LLM-drafted variants.Scenarios were retained only when traces exercised the intended mechanism and the oracle matched the stated success criterion.Source: §4.2 · p. 5

4.3 Outcome oracles and evaluation metric

  • Deterministic oracles check observable trace evidence, while semantic oracles evaluate response meaning, disclosure, or scenario-level adversarial objectives.The binary outcome uses a programmatic trace check for deterministic attacks and a fixed semantic evaluator for semantic attacks.Source: §4.3 · pp. 5–6
  • Attack success rate averages outcomes across five variants and N repetitions per variant, giving each variant and repetition equal weight.Results can be aggregated by model, attack family, or entry surface without changing the trial-level success definition.Source: §4.3 · p. 6

5 Experiments and results

COPEX evaluates MCP attack susceptibility across models and entry surfaces under controlled conditions, then examines outcome oracles, scanning defenses, reasoning architecture, and evaluation cost. Results vary across models and surfaces, and measured attack success depends on the outcome oracle and the defenses’ observation boundaries.

5.1 Experimental setup

  • The main benchmark evaluates 25 attack types across five variants each, with three repetitions per model, yielding 3,375 trials across nine models.Trials use the same ReAct loop; secondary studies compare outcome oracles on six attacks, defenses on eight, and reasoning architectures on six under otherwise matched conditions. The primary measure is ASR.Source: §5.1 · p. 6

5.2 Susceptibility across models and attack-entry surfaces

  • Model ASR ranges from 44.3% for Opus-4.7 to 81.6% for Grok-4.3, with a 64.4% macro average; surface means range from 58.3% to 71.4%, and no model stays low across all four surfaces.Opus-4.7, the lowest overall, reaches 73.3% on transport attacks; Gemini-3.1 and Grok-4.3 reach 95.2% and 98.1% on client attacks, respectively.Source: §5.2 · p. 7, Table 3 · p. 7

5.3 Outcome oracles and failure profiles

  • Semantic evaluation raises macro-average ASR from 77.1% under deterministic predicates to 83.3%, a difference of 6.3 percentage points.Semantic evaluation produces higher ASR for all four models. Deterministic predicates score trace evidence, while semantic evaluation assesses responses or trajectories against scenario objectives; the panels with different attack sets do not isolate oracle effects.Source: §5.3 · pp. 7–8

5.4 Defense coverage and observation boundaries

  • Combining input and context scanning yields the lowest mean ASR, 41.1% versus 81.6% without scanning, a 40.5-percentage-point drop (49.6% relative reduction) in the undefended setting.Context scanning examines tool schemas at registration and tool responses before model context, but cannot inspect transport state or prevent server-side actions during tool execution; MCP rebinding remains at 100% ASR under all four defense configurations.Source: §5.4 · p. 8

5.5 Reasoning architecture sensitivity

  • Reflexion reduces mean ASR from 86.2% to 82.5%, a decrease of 3.7 percentage points, but its effect varies by model.ASR decreases for Sonnet-4.6 and GPT-5.5, is unchanged for Gemini-3.1, and increases for Grok-4.3; reflection is not a consistent security safeguard.Source: §5.5 · pp. 8–9

5.6 Token usage and API cost

  • Prefill tokens exceed decode tokens by 2.6–24.5× per trial; the seven hosted-model evaluations incur $59.75 in API charges.Each 375-trial hosted-model evaluation costs $2.77–$21.53, and the reported prices were accessed on May 12, 2026; local compute is excluded.Source: §5.6 · p. 9

6 Discussion

COPEX separates observable model susceptibility from compromise below the model’s observation boundary, while its secondary-study estimates and attack coverage have important limits.

6 Discussion

  • One run per variant makes defense reductions and oracle differences indicative point estimates rather than precise estimates.The authors also note that 15 attack types rely on an LLM judge, so their ASRs reflect that judge’s decision boundary rather than objective ground truth.Source: §6 · p. 9
  • COPEX covers 25 attack types with five variants each, limiting how far its findings generalize beyond the evaluated set.ASR measures susceptibility after delivery, not real-world exploitability, which also depends on attack prevalence, access, and cost.Source: §6 · p. 9
  • COPEX separates responses to observable adversarial context from below-boundary compromise, supporting clearer model comparisons and surface-matched defenses.The results caution against single-number robustness rankings because no model is uniformly resistant across evaluated surfaces and measured ASR depends partly on the outcome oracle.Source: §6 · p. 9

7 Conclusion

COPEX benchmarks LLM robustness to adversarial context across four MCP entry surfaces using controlled scenarios and trials. Its results distinguish attacks tied to model decisions from those exploiting behavior outside the model’s observation and control.

7 Conclusion

  • COPEX comprises 25 attack types instantiated as 125 scenarios across model/agent, client, server/tool, and transport surfaces.The benchmark evaluates nine models over 3,375 trials and reports variation by model, attack family, and evaluation method.Source: §7 · p. 9
  • Some attacks depend directly on model decisions, while others exploit client, server, or transport behavior outside the model’s observation and control..Source: §7 · p. 9
  • Deterministic and semantic oracles capture complementary forms of success, while input and context scanning reduce ASR only for attacks on inspected surfaces.The benchmark scenarios and evaluation code are released, with execution traces to be added to the repository.Source: §7 · p. 9

Ethical statement

The transport-layer experiments use isolated environments and controlled servers, and the released materials support controlled testing and coordinated disclosure.

Ethical statement

A Attack taxonomy and per-attack results

The appendix lists COPEX’s attack taxonomy and per-attack results, with the taxonomy organized by entry surface and mean ASR.

A Attack taxonomy and per-attack results

B Defense evaluation: per-attack results

Table 9 reports per-attack attack success rates for the eight-attack scanner-defense subset, across four models and four defense modes.

B Defense evaluation: per-attack results

C Architecture comparison: per-attack results

The architecture comparison varies reasoning architecture under matched conditions, while the accompanying breakdowns describe judge evaluation, token costs, and scanner prompts.

C Architecture comparison: per-attack results

D Deterministic vs. judge per-attack breakdown

  • For Package Squatting (Tool), judge evaluation differs most because it considers trust in or action on tool output, unlike deterministic invocation checking.The table gives a per-attack, per-model deterministic-versus-judge breakdown for the six-attack matched comparison.Source: D Deterministic vs. judge per-attack… · p. 14, Table 11 · p. 14

E Token usage and API cost

  • Figure 4 reports provider-reported prefill and decode tokens per trial on a logarithmic scale, with API costs for hosted-model evaluations.Local models are omitted because local compute is not assigned an API price.Source: Figure 4 · p. 15, E Token usage and API cost · p. 15

F Judge system prompt

  • The independent LLM judge processes execution traces and returns standardized success or detection verdicts as structured JSON.The prompt is intended to preserve rubric consistency across heterogeneous agent trials.Source: Figure 5 · p. 15

G Judge mode: configuration drift

  • In Configuration Drift, the server returns a clean tool surface on the first two calls and an expanded privileged surface on the third.A judge rubric assigns the verdict based on how the model interprets the change in its final response.Source: G Judge mode: configuration drift · p. 16, Figure 6 · p. 16

H Sample execution trace

  • The sample Package Name Squatting trace is flagged by scanning runtime tool-execution sequences for unauthorized execution hashes.Source: Figure 7 · p. 17

I Reflexion critic prompt

J–L Scanner prompts

  • InputScanner classifies user tasks as safe or unsafe, while ContextScanner audits tool schemas before exposure and responses before they enter agent context.The response scanner targets dynamic semantic drift, rug-pull vectors, and late-stage context hijacking.Source: Figure 9 · p. 18, J InputScanner prompt · p. 18, Figure 10 · p. 19

Related papers

Loading 2610.04378v1…