Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-10-26

HighPrimary

Poisoned MCP Tool Descriptions Made Agents Send Interaction Data to a Separate Logging Tool

Controlled Log-To-Leak research shows MCP metadata inducing secondary logging calls after legitimate tasks, without claiming a production compromise.

MCP-enabled agentsTool execution / MCPControlled MCP tool-metadata poisoning and post-hoc loggingResearch harnesses and one tested configuration each of Cursor and Claude Desktop with GitHub MCP

What happened

Agents invoked save_logs after legitimate tool calls and supplied interaction data in the added call's arguments.

Why it matters

Controlled logging-call execution and payload recovery were measured. No harmful real-world exfiltration, third-party user-data collection or production victim impact was established.

Missing authorization check

Independent authorization before a secondary tool receives data from another service or the user's interaction.

Would PP block it?

A deployment would need complete mediation of the relevant MCP calls and network sinks, with grants bound to the destination, exact data scope and task. Merely enabling a server or reading its metadata must not authorize secondary transfer. This is a proposed enforcement mapping, not measured PP efficacy.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-10-26

    The authors publish the Log-To-Leak primary preprint describing controlled experiments and deployed-client observations.

Technical breakdown

  • An enabled researcher-controlled MCP server exposes poisoned tool metadata to the agent.
  • Injected wording specifies a trigger, logging-tool binding, justification and pressure to append a logging call.
  • After legitimate tool execution, the agent invokes save_logs with interaction fields.
  • The paper separates logging-call success, conditional payload fidelity and legitimate task completion; compatibility failures are not evidence of resistance.
  • Deployed-client observations cover one configuration each of Cursor and Claude Desktop; safety constraints limit testing to controlled tools and benign endpoints.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Host-controlled MCP dispatch and outbound data-release boundaries
Still needs
PP does not sanitize metadata, repair prompt injection or automatically determine semantic sensitivity. Ungated sinks remain outside this mapping. Results depend on client configuration and permitted tool access.
Receipt required for
Sending interaction data to a secondary logging tool or destination outside the authorized task

An integrated, independently enforced dispatch boundary could deny unrelated logging calls lacking action-bound authority; PP was not evaluated in the paper.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop