al-ice.ai

The Job Succeeds and the Secret Still Leaves: Log-To-Leak Hides Exfiltration After the Last Call

AI Security Research by al-ice.ai Editorial

A paper posted to arXiv on 26 October 2026 by researchers at Duke University, Michigan State University, and TikTok — Yuepeng Hu, Chongyu Fan, Sirat Samyoun, and Jian Du — documents an MCP prompt-injection technique whose stealth property should worry anyone monitoring agents by task outcome. Log-To-Leak (arXiv:2610.36108) is an additive post-hoc logging attack: poisoned natural-language tool metadata induces a separate attacker-controlled call after the final legitimate call, exfiltrating the user query, the MCP server name, the server response, and the agent response. Across 18 model-server pairs with valid tool execution, it achieves 62.64–100% attack success — and in 16 of those pairs the legitimate task still completes essentially normally, with absolute completion changes of at most 6.63 percentage points. We read the full 12-page paper first-hand. Success, in other words, is the camouflage.

The attack sits inside the established tool-poisoning surface — the same surface our MCPTox benchmark coverage (73% success across 20 agents) and the UVCyber advisory mapped earlier this year — but its placement is what is new. Rather than hijacking the task mid-stream, the injected directive waits until the work is done and then appends one more call framed as logging. The authors operationalize the directive through four components — Trigger, Tool Binding, Justification, and Pressure — and measure three things separately: whether the extra call fires, whether the exfiltrated payload is faithful, and whether legitimate behavior is preserved. That third metric is the paper’s sharpest contribution to the literature: most benchmarks score attacks on whether the malicious action happens, but Log-To-Leak shows that task completion and unauthorized disclosure coexist, which means outcome-based monitoring — did the agent do the job? — is structurally blind to it.

The defenses mostly fail, including the detector

The evaluation spans five MCP servers and four LLM agents under five metrics covering effectiveness, utility, and efficiency, with conditional logging accuracy of 76.55–95.64% — when the extra call fires, it usually carries the goods. Then the authors turn three classes of defense on the attack — detection-based, auditing-based, and dependency-graph defenses — and the results are grim reading for anyone relying on prompt-level guardrails. On GitHub MCP with GPT-4o, residual attack success stays above 55% after all three evaluated defenses. Prompt sandwiching, the cheapest standard mitigation, leaves 59.58% residual success — just 3.06 points below the undefended 62.64%, a reduction so modest it barely clears noise. DataSentinel marks all 100 injected metadata strings as safe and would filter none of them. And the instruction detector that might catch the payloads flags 136 of 159 benign descriptions overall — 85.53%, including 82 to 100% of benign descriptions from each tested server. A detector with that false-positive rate cannot ship; an attack with that residual success rate cannot be ignored.

The authors’ prescription points at architecture rather than prompting: host-controlled authorization for secondary tool calls. The logic follows directly from the attack placement. If any tool description can append one more call after the legitimate work, then the authorization boundary has to sit at the host — the layer that decides which calls may follow which — rather than in the model’s judgment about any single prompt. That aligns with the direction of this week’s other defensive signal: CrowdStrike’s taxonomy update argues that security must cover the plan, not just the prompt, and Log-To-Leak is a concrete instance of why — the malicious step is a plan-level addition that no per-prompt check is positioned to see. For teams running MCP servers in production, the actionable reading is narrower: audit tool metadata as untrusted input, constrain which tools can chain after which, and assume that a green task-completion dashboard says nothing about whether the transcript also went somewhere else.

Our write-up is analysis of arXiv:2610.36108 v1 (online 26 October 2026, full 12-page PDF read first-hand) for the attack definition, payload targets, Trigger/Tool-Binding/Justification/Pressure construction, evaluation scope, all quoted success, accuracy, completion-change, and residual-defense figures, the DataSentinel and detector results, and the host-controlled-authorization recommendation. Author names and affiliations are from the paper’s byline. Prior tool-poisoning coverage is linked, not restated. All verification was read-only: we deployed no MCP server, ran no model, and reproduced no attack. Brave Search was used for discovery only.

Sources: