MCP's Confused Deputy Problem: Provenance Gaps, Injection, DNS Rebinding

The Model Context Protocol connects LLMs to filesystems, databases, and the web, but its design carries a structural weakness: when a tool_result reaches the model's context, the protocol provides no cryptographically verifiable information about its origin, authorship, or integrity. Advisory fields like ToolAnnotations (readOnlyHint, destructiveHint) are not security boundaries — a compromised server can trivially misrepresent them, leaving the model to make trust decisions on unverifiable content.

This gap enables concrete attack paths. The reference fetch server converts arbitrary web content into Markdown and feeds it straight into the model's context, letting attacker-controlled pages inject fake instructions or trigger unintended tool calls — a textbook indirect prompt injection vector. Separately, DNS rebinding lets an attacker pass an allowlist check with a public IP, then rebind the domain to an internal RFC1918 address by zeroing the TTL, turning the MCP fetch server into an involuntary proxy into internal services.

For engineers, the actionable takeaway is that these risks produce loggable signals: system-prompt-like structures inside tool results, references to registered tool names, abnormally large fetch payloads, connections resolving to private IP ranges at request time, suspiciously low DNS TTLs, and redirect chains ending at internal endpoints. These can be implemented as concrete detection rules at the MCP proxy or SIEM layer.