How to red-team MCP tool hijacking in 2026

Red-team MCP tool hijacking in three recorded passes: isolate whether attacker-controlled metadata attracts tool selection, isolate whether an untrusted tool result manipulates the next action, then run the full chain in a contained environment. Keep selection, changed decisions, prohibited effects, and benign task completion as separate outcomes.

This design is motivated by A2M: Trace-Optimized Agent Hijacking in the MCP Ecosystem, an arXiv v1 paper whose record says it was accepted by AACL-IJCNLP 2026. Its LiveMCPBench experiments divide hijacking into attraction through tool metadata and manipulation through returned content. Current first-party MCP guidance independently treats annotations and cross-server results as untrusted and keeps authorization in the host. None of these sources establishes production attack prevalence or a universal defense.

Start with the threat model, not attack strings

In A2M's threat model, the attacker controls a malicious tool's name, description, endpoint, and returned payload. The attacker does not receive the victim model's weights, system prompt, or private memory, but can use execution traces to refine the attempt. Translate that into a local test boundary before running anything:

Pass 1: test whether metadata attracts selection

Hold the tool's result harmless and fixed. Vary only the discovery inputs your host actually uses: the tool name and description, source trust tier, annotations, schema wording, legitimate competitors, task phrasing, candidate order, router, and candidate budget. Record whether the untrusted tool was filtered, exposed, selected, and called.

A2M calls this stage Attraction and measures malicious tool invocation rate: the share of evaluated tasks whose trace contains the malicious tool. Use that or an equivalent local measure as exposure evidence, not proof of harm. A selected tool may return harmless data or be stopped by a later control.

Treat annotations as claims, not permissions. The MCP tools specification says clients must consider tool annotations untrusted unless they come from trusted servers. The MCP project's annotation guidance adds that hints cannot replace authorization, sandboxing, network policy, or another deterministic guarantee. Include cases where an untrusted tool claims to be read-only, non-destructive, idempotent, or closed-world; the host should not silently relax policy because of the claim.

Pair this evidence with a history-aware MCP routing record so the authorized candidate set, trust classification, and selection basis remain inspectable.

Pass 2: test whether the result manipulates the next action

Invoke a controlled adversarial tool directly, or otherwise hold selection constant, and vary only its returned content. Ask whether the result can redirect the task, change an argument or recipient, trigger another tool, disclose governed data, consume an unbounded budget, or terminate the workflow early.

Each case should declare:

• the legitimate task and current authorized state;
• the inert tool-result fixture and its trust label;
• the next tools and data the agent can reach;
• the exact prohibited or approval-gated action;
• the expected next action, refusal, constraint, or escalation; and
• the actual policy decision, tool request, side effect, and final state.

This is where an instruction-hierarchy test becomes observable. A cautious explanation is not a pass if the agent already changed a recipient, exposed a value, or requested an unauthorized effect.

The MCP specification tells clients to validate tool results before passing them to the model. Client security guidance also says a result from one server is untrusted input to another and that truncation alone does not prevent exfiltration. Structural validation helps reject malformed results; it does not establish that a well-formed string is benign or that a follow-on action is authorized.

Pass 3: run the full chain without losing the diagnosis

After the isolated passes, enable both adversarial metadata and adversarial returned content in one contained case. Preserve the stage evidence and classify the end-to-end result:

Selection and downstream harm are different measurements

The benchmark results make the distinction concrete. A2M directly optimized against GLM-4.6 and transferred those attacks without re-optimization to four other models:

93.6% → 63.6%

mean malicious-tool invocation: direct vs. transfer

74.4% → 24.5%

mean attack success: direct vs. transfer

On GPT-5, the paper reports scenario invocation rates from 64.9% to 76.3%, while attack success was 0% for information exfiltration and environment-integrity compromise and 22.0% for reasoning derailment. Those are benchmark results, not production rates. Their useful lesson is the gap: frequent selection and downstream compromise are not interchangeable evidence.

Build a versioned evidence record

A repeatable case needs more than a payload and a pass/fail label. Retain:

• case ID, owner, version, benign task, and expected outcome;
• host, model, prompt, router, registry, and policy versions;
• trusted and adversarial server identities, candidate set, and metadata hashes;
• the result fixture, trust label, authority, and approval state;
• selection, policy, call, side-effect, and final-state evidence; and
• attempt budget, per-attempt outcomes, cost, and accepted task outcome.

Pre-register expected decisions and repeat policy. Keep development cases separate from held-out acceptance cases so a team cannot tune a router or filter on the same examples and call the rerun independent evidence. The sources provide no universal threshold; set release vetoes by consequence.

Map each failure to the control that owns it

• Forbidden candidate exposure: fix registry trust, server allowlisting, authorization-aware discovery, or tool resolution.
• Metadata dominates legitimate tools: fix ranking, source labels, candidate budgets, or trust-weighted routing.
• A result becomes an instruction: fix labeling, isolation, screening, or the model-facing context boundary.
• The model proposes a prohibited action: enforce per-call authorization, argument validation, or confirmation outside the model.
• A call chain runs away: enforce call, time, token, and cost limits in the runtime.
• The effect is blocked but the task fails: repair the safe fallback or escalation path and retain benign completion as a release metric.

Keep connectivity separate from trust with private MCP server exposure controls, apply production MCP server validation and logging, and bound the remaining consequence with least-privilege delegation.

Do not promote an exploratory defense into a guarantee

A2M's appendix evaluates metadata paraphrasing and a FIDES-inspired information-flow configuration. Residual attack or resource use remains in its setting, and the authors explicitly limit transfer claims across models, policies, and deployment stacks. An output filter does not prove safe discovery; a trust-aware router does not prove safe result handling; a sandbox does not prove task preservation; confirmation helps only when the interface shows the real action and the check occurs before the effect.

What this evidence does not establish

The study is bounded to LiveMCPBench, a fixed ReAct-style stack, five models, and specific prompts, routing policies, wrappers, and tool-pool composition. Direct optimization centers on GLM-4.6. It does not establish how common malicious tools are, how benchmark rates transfer to a particular host, or a universal repeat count, threshold, or defense.

A practical first test

1. Choose one legitimate task with two trusted tools and one controlled adversarial tool.
2. Give the adversarial tool harmless output, vary its metadata, and record exposure and selection.
3. Invoke it directly with fixed metadata and return one inert fixture that targets a protected next action.
4. Enable both stages, then verify the full chain, benign task result, and every deterministic control.
5. Repeat under a declared attempt budget after material changes to the model, prompt, router, registry, result handling, permissions, or approval policy.