Every connected MCP server widens the agent's injection surface

MCP lets an agent reach more tools and data, and each new connection is also a new path for untrusted content to reach the model. The capability and the risk are the same edge. Invariant Labs demonstrated an untrusted MCP server exfiltrating a user’s full WhatsApp history through a trusted WhatsApp server, without ever being called directly, by injecting instructions into its own tool description. Their verdict is blunt: “code isolation or sandboxing of the MCP server is not a relevant mitigation,” because the attack rides on the agent’s instruction-following, not on code execution.

Two patterns make it worse. A server can advertise an innocent tool, get approved, then swap in a malicious description later (a rug pull) that clients do not re-surface for approval. And a crafted message returned by a trusted tool is enough on its own, no malicious server required. This is the lethal trifecta (see: the lethal trifecta makes agents exploitable) made routine: MCP hands an agent private data and external reach, then connects it to content it cannot trust.

The mitigation matches the threat model from MCP’s own guides (see: MCP is a protocol layer that decouples tools from providers): treat every server as untrusted, audit-log every tool call, and assume prompt injection (see: guardrails alone cannot prevent prompt injection) will arrive through the tools you connect. A buyer ticking “MCP support” without pricing the injection surface it opens has under-paid for the feature.