MCP Tool Poisoning Turns Descriptions Into Exfiltration Paths

MCP is becoming the backbone for AI tool integration. It standardizes how an agent discovers and calls tools, but it also imports tool descriptions and outputs into the model context. If those strings are untrusted, they can override intent and steer the model toward data exfiltration.

Tool Poisoning in Practice

Researchers demonstrated that a malicious or compromised MCP server can embed prompt injection inside tool descriptions or returned data. In one example, a poisoned tool response urged the model to look for secrets, then reissued them to an attacker-controlled endpoint. The result is a data leak without any overt exploit or permission prompt.

The Supabase MCP Case Study

This trust-boundary failure is not theoretical. A recent analysis showed how a support ticket combined with MCP could result in data exposure. The injected prompt instructed the agent to use tools to locate and extract sensitive data from internal systems. The exploitation did not require code execution, only prompt manipulation across trusted tool interfaces.

Microsoft's Guidance: Treat Tool Output as Untrusted

Industry guidance now mirrors what the research shows. Microsoft has emphasized that tool output is untrusted input, and that applications must apply validation, sandboxing, and explicit approvals. Their guidance focuses on isolating tool calls, monitoring for abnormal behavior, and requiring user confirmation for sensitive actions.

HN Commentary: This Is a Trust Boundary Failure

The Hacker News discussion echoed a consistent theme: MCP does not create new capabilities, it exposes old assumptions. If you allow untrusted content to sit in the same context as your tool instructions, you should expect prompt injection to be exploitable.

How AARSM Helps

AARSM treats tool descriptions and outputs as untrusted and enforces policy before the model can act on them. That is how you stop tool poisoning from becoming data loss.