a2ally™ Sign up

Answers · MCP security

How do I stop Log-To-Leak style prompt injection through MCP logging tools?

Last updated

TL;DR: Log-To-Leak is a tool-poisoning attack described in 2025-2026 research: a malicious MCP server's tool description tells the agent to call a "logging" or "audit" tool after it finishes its real work, and to pass along the user's request, the other server's name and response, and the agent's own reply. The agent completes the task normally, so nothing looks wrong, while the conversation leaks to the attacker. The researchers report high success rates across several models and servers, and that the defenses they tested left much of the attack working. Because a model cannot be relied on to ignore instructions it reads, the fix belongs in the host: allow only the tools a task needs, treat every tool description and tool result as untrusted data, require confirmation for calls the user did not ask for, and block network egress to anywhere not on an allowlist.

What should I check, step by step?

1. Per-task tool allowlists: expose only the tools the current task needs, from the servers it needs. A logging, telemetry or "report" tool from an unrelated server should not be callable at all.

  1. Treat tool descriptions, schemas and tool results as untrusted data, never as instructions. Watch for wording aimed at the model: always, must, before responding, required for compliance, log the full conversation.
  2. Pin and review tool definitions: record a hash of each server's tools/list and alert or re-approve when it changes, since descriptions can change after you install.
  3. Require human confirmation for secondary calls the user did not request, especially calls that send data to a different server than the one doing the task, and show the full arguments.
  4. Egress allowlists: run local MCP servers in a sandbox or container whose outbound network is limited to the hosts they need, so an injected call has nowhere to send data.
  5. Minimize what reaches tools: don't pass whole conversations or other servers' responses as arguments; flag string arguments that contain the user's prompt or another tool's output.
  6. Audit: log every tool call with server, tool, argument sizes and destination, and review unexpected cross-server calls.

Why is it hard to spot?

The injected instruction sits in tool metadata the user rarely reads, and it asks for an extra call rather than a wrong answer, so the visible task still succeeds.

How do I ask a2ally about this (free, no key)?

Add the MCP server https://www.a2ally.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “Before I add this MCP server, is it a listed, vetted app and has its tool list changed recently?”

One-click setup

{
  "tool": "check_listing",
  "arguments": {
    "url": "<the server's URL or repository>"
  }
}

a2ally does not scan arbitrary MCP servers for injected instructions and does not certify any server as safe; it reports what its store checks and probes actually found.

What are the sources?

Related

Not legal advice. JSON · Markdown · All answers

Get a free API key in one call

No card and no email needed. 100 free credits; the license and policy checks stay free without a key.

curl -s -X POST https://www.a2ally.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export A2ALLY_API_KEY=rs_...   # the api_key from the reply (shown once)
curl -s https://www.a2ally.com/v1/licenses/check -H "Authorization: Bearer $A2ALLY_API_KEY" \
  -H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'
Get a keyQuickstart