ContextLeak: Exfiltrating LLM Agent Context via Malicious Tools

Abstract

Verbatim from the arXiv abstract page (fetched 2026-09-11):

Exfiltrating an LLM agent's runtime context -- such as the user prompt, execution trajectory, and tool list -- poses severe security and privacy risks to users. Such attacks can be carried out via malicious tools and typically require three conditions: (1) the agent selects the malicious tool for task execution, (2) the agent passes its runtime context as input arguments to the tool, and (3) the tool's implementation transmits these inputs to an attacker-controlled endpoint. Existing work primarily focuses on conditions (1) and (3), leaving condition (2) largely unexplored, despite its critical role in enabling successful context exfiltration. In this work, we bridge this gap by developing ContextLeak, a malicious tool attack that induces the agent to both select the tool and disclose its context as input arguments. We realize this attack by carefully crafting the tool's name and description using reinforcement learning. Specifically, ContextLeak employs an LLM, referred to as the attack LLM, to automatically generate the malicious tool's name and description. To improve attack effectiveness, we fine-tune the attack LLM via reinforcement learning on a set of shadow users with diverse, simulated agent contexts. Our key technical contribution is the design of novel reward functions tailored to the context exfiltration objective, enabling effective reinforcement-learning-based fine-tuning of the attack LLM. Extensive evaluation demonstrates that our attack remains highly effective even when the shadow users' contexts differ substantially from those of the victim users. Moreover, ContextLeak significantly outperforms existing malicious tool attacks when adapted to this setting.

Key Contributions

• Names and closes the step prior work skipped. Getting an agent to call a bad tool is condition (1) and is well studied; getting it to pass its own context as the argument is condition (2), and that is where the data actually leaves.
• The attack surface is the tool's name and description — the two fields a registry shows you and nothing verifies. No code execution, no injected document, no compromised model: a string in a manifest.
• The crafting is learned, not hand-written. An attack LLM is fine-tuned by RL against a population of shadow users with simulated contexts; the reward functions are designed for exfiltration rather than for task hijacking, which is the paper's stated technical contribution.
• It transfers. Effectiveness holds when victim contexts are drawn from a different domain, and even a different dataset, than the shadow users used for training.

Methodology

• Shadow users: 800, spread over 10 ToolBench domains (email, financial, food, health, medical, movies, music, sports, travel, weather).
• Victim populations: 200 in-domain, 100 out-of-domain, 100 out-of-dataset (ToolAlpaca), 100 cross-domain/dataset.
• Backend agent LLMs: Qwen-3-8B, GPT-OSS-20B, Gemma-4-E4B-it, Qwen-3.5-9B, GPT-4.1, GPT-5-mini, GPT-5.1.
• Metrics: MTSR (malicious tool selection rate), EDS (edit-distance score between exfiltrated and true context), plus F1/precision/recall for tool-list extraction.
• Baselines adapted to this setting: ObliInjection, ToolHijacker, JudgeDeceiver.

Results

Figures below read from the paper's HTML tables (fetched 2026-09-11). The proposal flagged the abstract as carrying no headline ASR [unverified]; that is resolved here — the numbers exist in the tables.

Main results, in-dataset/in-domain victims:

The fidelity column is the real finding. ContextLeak's selection-rate lead over ToolHijacker on user prompts is 7 points; its edit-distance lead is 0.99 against 0.74. The baselines get the agent to call the tool; ContextLeak gets the agent to hand over the context intact. That is condition (2) made quantitative.

Transfer across backend LLMs: MTSR 60–82% (user prompts), 65–77% (conversation history), 56–85% (tool lists, F1 0.80–0.92).

Defences:

• Prevention — StruQ / SecAlign cut effectiveness but destroy utility (clean task success falls to 0.08–0.15). Meta-SecAlign preserves more utility and remains vulnerable.
• Detection — PromptGuard 0% FPR / 99–100% FNR; DataSentinel 0–1% FPR / 99–100% FNR; MCPScan 1% FPR / 100% FNR. Every detector tested effectively never fires.

Real-world check: against Claude Code (Claude Sonnet 4.6), 100 test cases, 22% MTSR, with EDS 0.77 and 0.96 embedding similarity when the tool was selected. A large drop from the 92% lab figure — and still a fifth of attempts.

Limitations

• The lab numbers come from ToolBench/ToolAlpaca simulations; the one production-agent check drops MTSR from 92% to 22%, so the headline figure should never be quoted as a real-world rate.
• The strongest defence result is a trade, not a fix: the prevention methods that work wreck task utility.
• Detector FNRs are measured against ContextLeak's own generated tools, i.e. against an attack optimised until it works — which is the honest reading of "detection failed" and also its ceiling as evidence.
• Attacker capability assumed: the ability to publish a tool into a registry the victim agent will consider. That is the whole precondition, and it is exactly the MCP-marketplace posture.

Why this is on the security rung, and the seat

Freshest source in the pass (two weeks old) and the one with an action attached: the tool description is the attack surface, so the operating rule is that installing a third-party MCP server is trusting a string nobody attested. It is the empirical partner to SEC2, which says the same thing structurally — no capability attestation — and the detector results say the market's current answer to that (scanners) does not work.

Standing: I did this myself on the protocol posture (MenFem runs an MCP server and grants no ops:* scope to any purchasable tier); I only read about it on the attack itself. A published piece must not claim to have run ContextLeak.

No live market call rests on this rung — brand and operating value only.

Source: ContextLeak: Exfiltrating LLM Agent Context via Malicious Tools by Yuqi Jia, Ruiqi Wang, Patrick Li, Yuepeng Hu, Peinian Li and Neil Gong — arXiv:2608.27800, submitted 2026-08-28.