Log-To-Leak: Prompt Injection Attacks on Tool-Using LLM Agents via the Model Context Protocol

Introduction

Large language model (LLM) agents are increasingly equipped with external tools—search APIs, calculators, code executors—through a standardized interface known as the Model Context Protocol (MCP). While MCP enables powerful, compositional workflows, it also introduces a new attack surface: the natural‑language metadata that describes each tool. The paper Log‑To‑Leak: Prompt Injection Attacks on Tool‑Using LLM Agents via the Model Context Protocol investigates how an adversary can exploit this surface to inject a covert logging call after a legitimate tool use, thereby exfiltrating information without disrupting the primary task.

How Log‑To‑Leak Works

The attack follows a four‑step pattern:

1. Trigger – The attacker crafts a user query or system prompt that activates a latent directive.
2. Tool Binding – The malicious payload binds to the description of a legitimate tool, masquerading as part of its natural‑language specification.
3. Justification – The injected text provides a plausible reason for an additional call (e.g., “for verification” or “to log results”).
4. Pressure – Language that nudges the LLM to obey the extra call, such as “please ensure completeness.”

When the LLM processes the request, it first executes the intended tool call, then, because the injected directive is embedded in the same context, it silently issues a second, attacker‑controlled call. The payload can target the original user query, the MCP server name, the server’s response, or the agent’s own reply, allowing the attacker to harvest sensitive data.

Experimental Evaluation

The authors evaluated Log‑To‑Leak across:

• Five MCP servers (including open‑source and commercial implementations).
• Four LLM agents (representative of current research and commercial offerings).
• Five metrics covering effectiveness (attack success rate, logging accuracy), utility (impact on the original task), and efficiency (overhead introduced).

Key findings:

• Attack Success Rate (ASR) ranged from 62.6 % to 100 % across 18 valid model‑server pairs.
• Logging Accuracy (LA)—the fidelity of the injected call’s payload—was between 76.5 % and 95.6 %.
• The presence of the covert call altered the original task’s success by at most 6.6 percentage points, indicating that the attack can remain stealthy while still achieving its secondary goal.
• Three tested defenses (input sanitization, tool‑whitelisting, and response‑filtering) reduced but did not eliminate the ASR; the best‑performing defense still left >55 % of attacks successful on a popular GitHub‑hosted MCP using GPT‑4o.
• An instruction‑detector designed to flag malicious tool descriptions mistakenly flagged 85.5 % of benign descriptions, highlighting a trade‑off between security and usability.

Implications and Recommendations

The results demonstrate that the MCP’s reliance on natural‑language tool descriptions creates a persistent injection vector. Because the secondary call occurs after the legitimate one, it can evade many conventional defenses that focus on preventing unauthorized tool execution altogether.

Practical steps for practitioners:

• Host‑controlled authorization: Require explicit approval from the MCP server before any secondary tool call is issued, regardless of its provenance in the prompt.
• Structured tool schemas: Move away from free‑form textual descriptions toward machine‑readable schemas (e.g., JSON‑LD) that can be validated before execution.
• Runtime monitoring: Log and audit all tool invocations, flagging sequences where a call follows another without an intervening user request.
• Fine‑grained prompting policies: Restrict the LLM’s ability to generate new tool calls unless they are directly derived from user intent.

Conclusion

Log‑To‑Leak uncovers a subtle yet potent class of prompt‑injection attacks that leverage the Model Context Protocol’s textual tool metadata. The attack’s high success rates across diverse models and servers, coupled with the limited effectiveness of existing mitigations, underscore the need for more robust, host‑centric controls and stricter tool description formats. As LLM agents become integral to automated workflows, securing the MCP will be essential to prevent covert data leakage while preserving the utility of tool‑augmented reasoning.