The MCP Confused Deputy: Provenance Gaps, Instruction Injection, and DNS Rebinding in the Model Context Protocol A security researcher has identified a 'confused deputy' vulnerability in the Model Context Protocol (MCP), the protocol connecting LLMs to external systems. The flaw stems from a provenance gap: MCP tool results lack cryptographic attestation of origin, enabling instruction injection and DNS rebinding attacks. The official MCP fetch server can be manipulated to return attacker-controlled content that the model treats as trusted instructions, potentially leading to unauthorized actions. The Model Context Protocol is the connective tissue between LLMs and external systems — filesystems, databases, APIs, browsers, internal tooling. In a well-functioning agentic deployment, MCP lets a model read documents, query databases, and take actions in the world. In an adversarial deployment, MCP becomes the mechanism by which attacker-controlled content reaches a model's context window and convinces it to take actions the user never authorized. We previously covered the RCE class of MCP vulnerability and AEGIS detection at the network layer Anthropic MCP RCE: 7,000 Servers Exposed https://dev.to/blog/anthropic-mcp-rce-aegis . This piece is about a different and subtler problem: the confused deputy — the provenance gap in the protocol design itself — and the specific attack paths that flow from it. The confused deputy is a classic access-control concept: an entity with legitimate authority is manipulated by an untrusted party into exercising that authority on the untrusted party's behalf. In MCP, the confused deputy is the model itself. Here is the structural problem: when an MCP tool call returns a result, the protocol carries the content of that result into the model's context window. It does not carry cryptographically attestable information about where that content came from, who produced it, or whether it has been tampered with in transit. The model receives a tool result and must decide how to act on it based on its content — but the content could come from a trusted server, a compromised server, a DNS-rebinded endpoint, or a webpage that an attacker controls and has stuffed with instruction text designed to override the model's behavior. The MCP specification includes a ToolAnnotations object — fields like readOnlyHint, destructiveHint, idempotentHint — intended to communicate properties of tools to clients. The specification is explicit that these annotations are advisory and not security boundaries. They can be set by the server and have no verifiable binding to actual tool behavior. A malicious or compromised server can annotate a destructive write operation as readOnly. An instruction-injected tool result can include fabricated annotations in its text. Neither the client nor the model can verify them cryptographically. The result is a protocol where the model is asked to make trust decisions about content for which the protocol provides no trustworthy provenance signal. The reference MCP fetch server — the official Anthropic-maintained server for web browsing tool calls — accepts a URL, fetches the content, converts the HTML to Markdown, and returns it as a tool result. The model receives this Markdown and processes it as part of its context. Consider what happens when the URL being fetched is attacker-controlled. The attacker can place arbitrary text in the page, including: This is not a hypothetical. It is the standard indirect prompt injection pattern applied to the MCP fetch surface. The fetch server converts web content to Markdown without sanitizing or labeling it as untrusted external content — it lands in the model's context with the same structural weight as system instructions or legitimate tool results. The model has no reliable mechanism to distinguish "this is content I fetched from an external page" from "this is an instruction from my operator." The attack does not require compromising an MCP server. It requires only the ability to serve content at a URL the model will be asked to fetch — which in many agentic workflows is directly controlled by user input or by attacker-controlled content in previously fetched documents. DNS rebinding attacks against MCP create a distinct and particularly dangerous attack path. The mechanism: This bypasses most URL-based filtering because the filtering happens at allowlist check time public IP , not at fetch time internal IP . The MCP server becomes an involuntary proxy to internal services, and the attacker now has the model reading the output of those internal services. The footgun is particularly sharp in self-hosted agentic deployments where the MCP server runs inside the network perimeter and has access to internal APIs, documentation systems, internal dashboards, or configuration management endpoints that are not exposed publicly. The following are concrete, loggable signals for MCP deployments. These should be implemented at the MCP proxy layer, in SIEM rules, or in the agent monitoring infrastructure. Instruction injection detection: