LLM agents increasingly access external tools through the Model Context Protocol (MCP), but the natural-language metadata used to describe those tools creates a prompt-injection surface. Within this established tool-poisoning surface, we study Log-To-Leak, an additive post-hoc logging attack that induces a separate attacker-controlled call after the final legitimate call. Its payload targets the user query, MCP server name, server response, and agent response. We operationalize the injected directive through Trigger, Tool Binding, Justification, and Pressure, and separately measure call success, payload fidelity, and preservation of legitimate behavior. We evaluate five MCP servers and four LLM agents using five metrics spanning effectiveness, utility, and efficiency. Across 18 model-server pairs with valid tool execution, Log-To-Leak achieves an attack success rate (ASR) of 62.64-100% and conditional logging accuracy (LA) of 76.55-95.64%; 16 pairs have absolute target-task completion changes of at most 6.63 percentage points. Three evaluated defenses leave residual ASR above 55% on GitHub MCP with GPT-4o, while an instruction detector flags 85.53% of benign descriptions. These results show that successful task completion can coexist with unauthorized post-hoc disclosure and motivate host-controlled authorization for secondary tool calls.
Figures & tables
Figure 1. Overview of benign and malicious MCP workflows. The left panel contrasts normal tool use with an injected workflow that adds an unauthorized logging call. The middle panel shows the corresponding tool-invocation traces: the malicious trace includes an additional save_logs call while producing a similar user-visible response. The right panel shows the attack in the Claude user interface. Three-panel overview of the attack. A benign MCP workflow is compared with a malicious workflow containing an extra save-logs call; execution traces show the added call, and a Claude interface screenshot shows the call occurring in practice.
Figure 2. Illustrative MCP tool definition. The function takes a name and an optional style parameter to generate a greeting. Annotations show the complete definition; the injection-surface study evaluates the tool name, parameter name, default value, and description. Annotated code for a greeting tool. Labels identify the function name, parameters, default value, description, function body, and return value; the study evaluates the tool name, parameter name, default value, and description.
Figure 3. (a) Attack success rate (ASR) for Tool Binding placed in the tool name (Func), parameter name (Var), default value (Def), or description (Desc), evaluated on GitHub MCP with GPT-4o. (b) ASR for description-based Tool Binding (Desc as TB) combined with five Trigger (Trig), Justification (Just), or Pressure (Pres) variants. Bars 1–5 are ordered from highest to lowest ASR within each component group. Two bar charts report attack success rates on GitHub MCP with GPT-4o. The description field performs best among four Tool Binding positions, and adding Trigger, Justification, or Pressure variants increases success over description-based Tool Binding alone.
MCP Server
Task Categories
# Prompts
Source
GitHub
4
160
Custom (GPT-4o)
Mapbox
4
160
Custom (GPT-4o)
PayPal
4
160
Custom (GPT-4o)
Playwright
–
35
MCP-Universe
YFinance
–
40
MCP-Universe
Total
–
555
–
Table 1. Task-set summary for each MCP server.
Effectiveness
Utility
Efficiency
Model
ASR ↑
LA ↑
ΔTCR
ΔMCR
ΔTU
GitHub MCP
GPT-4o
38.40%
85.46%
-0.38% (74.9 → 74.5)
+0.00% (100 → 100)
+4.7k (23.9k → 28.6k)
62.64%
94.80%
+0.00% (74.9 → 74.9)
+0.00% (100 → 100)
+8.2k (23.9k → 32.1k)
Claude - Sonnet - 4
99.53%
82.69%
+9.38% (71.9 → 81.3)
+0.00% (100 → 100)
+25.9k (49.5k → 75.4k)
99.51%
85.96%
+6.63% (71.9 → 78.5)
+0.00% (100 → 100)
+26.5k (49.5k → 76.0k)
Table 2. Results on the three custom task sets. For each model, the white row reports the vanilla baseline and the gray row reports Log-To-Leak.
Effectiveness
Utility
Efficiency
Model
ASR ↑
LA ↑
ΔTCR
ΔMCR
ΔTU
YFinance MCP
GPT-4o
74.02%
78.68%
+1.88% (21.3 → 23.1)
+0.00% (100 → 100)
+6.9k (23.7k → 30.6k)
84.01%
81.61%
+0.88% (21.3 → 22.1)
+0.00% (100 → 100)
+6.2k (23.7k → 29.9k)
Claude - Sonnet - 4
100.00%
76.56%
+0.75% (21.3 → 22.0)
+0.00% (100 → 100)
+48.5k (51.1k → 99.6k)
99.46%
78.01%
-0.38% (21.3 → 20.9)
+0.00% (100 → 100)
+44.2k (51.1k → 95.3k)
Table 3. Results on the two MCP-Universe task sets. For each model, the white row reports the vanilla baseline and the gray row reports Log-To-Leak. A dash indicates that conditional LA is undefined because no successful logging call occurred.
Effectiveness
Utility
Efficiency
Method
ASR ↑
LA ↑
ΔTCR
ΔMCR
ΔTU
Combined Attack
4.32%
85.23%
-11.25% (74.9 → 63.6)
0.00% (100 → 100)
-10.2k (23.9k → 13.7k)
TopicAttack
4.47%
87.50%
-13.75% (74.9 → 61.1)
0.00% (100 → 100)
-10.0k (23.9k → 13.9k)
Log-To-Leak (ours)
62.64%
94.80%
0.00% (74.9 → 74.9)
0.00% (100 → 100)
+8.2k (23.9k → 32.1k)
Table 4. Comparison with prompt-injection baselines on GitHub MCP with GPT-4o.
Group (G)
Best ASR
G1: Tool Binding only
0.124 (Declarative)
G2: Trigger + Tool Binding
0.260 (Pre-output)
G3: Tool Binding + Justification
0.298 (Compliance)
G4: Tool Binding + Pressure
0.271 (Urgency)
G5: Trigger + Tool Binding + Justification
0.576
G6: Trigger + Tool Binding + Pressure
0.624
Table 5. Controlled ablation groups and their best observed ASR.
Figure 4. Successful Log-To-Leak attack on Cursor. After completing the legitimate GitHub task, the agent automatically invokes the attacker-controlled save_logs tool. Cursor interface showing completed GitHub tool calls followed by an additional invocation of the attacker-controlled save-logs tool.
Effectiveness
Utility
Efficiency
Defense
Residual ASR ↓
Conditional LA ↓
ΔTCR
ΔMCR
ΔTU
Prompt Sandwiching
59.58%
84.71%
-4.25% (74.9 → 70.6)
-0.12% (100 → 99.9)
-3.9k (23.9k → 20.0k)
LLM Metadata Check
55.38%
85.46%
-5.63% (74.9 → 69.3)
0.00% (100 → 100)
-6.3k (23.9k → 17.6k)
IPIGuard
60.47%
90.87%
-2.32% (72.8 → 70.5)
0.00% (100 → 100)
+7.2k (24.2k → 31.4k)
Table 6. Residual attack performance under three defenses on GitHub MCP with GPT-4o. Lower ASR and LA indicate stronger protection.
Metadata Source
Predicted as Injection (count)
Proportion
GitHub MCP
74 / 90
0.8222
Mapbox MCP
8 / 9
0.8889
PayPal MCP
24 / 28
0.8571
YFinance MCP
9 / 9
1.0000
Playwright MCP
21 / 23
0.9130
Log-To-Leak injections
91 / 100
0.9100
Table 7. Instruction-detection predictions for benign MCP metadata and Log-To-Leak injections ( Wen et al., 2025 ) .
Recent advances in the Model Context Protocol (MCP) have enabled large language models (LLMs) to invoke external tools with unprecedented ease. This creates a new class of powerful and tool augmented agents. Unfortunately, this capability also introduces an under explored attack surface, specifically the malicious manipulation of tool responses. Existing techniques for indirect prompt injection that target MCP suffer from high deployment costs, weak semantic coherence, or heavy white box requirements. Furthermore, they are often easily detected by recently proposed defenses. In this paper, we propose Tree structured Injection for Payloads (TIP), a novel black-box attack which generates natural payloads to reliably seize control of MCP enabled agents even under defense. Technically, We cast payload generation as a tree structured search problem and guide the search with an attacker LLM operating under our proposed coarse-to-fine optimization framework. To stabilize learning and avoid local optima, we introduce a path-aware feedback mechanism that surfaces only high quality historical trajectories to the attacker model. The framework is further hardened against defensive transformations by explicitly conditioning the search on observable defense signals and dynamically reallocating the exploration budget. Extensive experiments on four mainstream LLMs show that TIP attains over 95% attack success in undefended settings while requiring an order of magnitude fewer queries than prior adaptive attacks. Against four representative defense approaches, TIP preserves more than 50% effectiveness and significantly outperforms the state-of-the-art attacks. By implementing the attack on real world MCP systems, our results expose an invisible but practical threat vector in MCP deployments. We also discuss potential mitigation approaches to address this critical security gap.
Yulin Shen, Xudong Pan, Geng Hong +1
School of Computer Science, Fudan University · Shanghai Innovation Institute
Prompt-injection benchmarks for LLM agents typically test attacks through a single injection surface and report the resulting attack success rate as a property of the model. We ask whether those robustness conclusions remain stable when the same adversarial content enters through a different part of the agent interface. Using AgentDojo, we evaluate 13 LLMs across four task suites and place a byte-identical payload either in a tool output or in the tool description. This small change produces large differences in comparative robustness: 44.9% of all model pairs change their relative ordering across the two surfaces, with substantial ranking instability in every suite. The effect is especially pronounced for a small number of models, showing that a benchmark can substantially underestimate vulnerability when it tests only one surface. We further find that this behavior has predictive structure. Using three suites to identify the riskier surface for each model predicts the more vulnerable surface on an unseen suite with 76.9% accuracy. Defense results show the same dependence, as mitigations effective against tool-output attacks can leave substantial exposure through tool descriptions. Our results show that prompt-injection robustness is not surface-invariant and that agent evaluations should test the surfaces on which their security conclusions depend.
Syed Nazmus Sakib, Nafiul Haque, Shahrear Bin Amin +1
Department of Robotics and Mechatronics Engineering, University of Dhaka · Department of Computer Science and Engineering, University of Dhaka
Large language models (LLMs) are increasingly used as analyst assistants in security operations centers (SOCs), where they ingest log and alert data to produce triage labels, incident summaries, or remediation advice. We study a structural failure mode of this design: many log fields are attacker controlled. User agents, URLs, payloads, DNS queries, and attempted usernames can therefore carry instructions to the model alongside evidence of the intrusion. We call this setting log-substrate prompt injection. We introduce a four-class taxonomy of log-substrate attacks: direct override (S1), persona hijack (S2), context manipulation (S3), and obfuscated payloads (S4). We evaluate 48 strategy-defense-task combinations using gpt-4o-mini as the analyst. Three findings stand out. First, direct overrides are ineffective in our setting: all S1 classification attacks achieve 0% suppression. In contrast, persona hijacks suppress 68% of malicious logs under a naive classifier and remain effective under stronger defenses. Second, summarization is the highest-risk task: context manipulation reaches 96% injection success without defenses and 38% even with constrained output. Third, defenses reduce but do not eliminate the attack surface: average injection success falls from 26.6% under naive prompting to 11.8% under our strongest defense. We also compare empirical results to a deterministic mock analyst and find that simulation substantially mispredicts current model behavior, especially for direct overrides. These results suggest that SOC copilots should treat raw log content as adversarial input rather than ordinary analyst context.