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). 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:
<system>
, <instructions>
, [INST]
), markdown headers framing instructions (## New Instructions
, ## Override
), or explicit references to model roles. These patterns appearing in tool results, not in system prompts, indicate injection attempts.DNS rebinding detection:
Behavioral anomaly detection:
Detection is necessary but not sufficient. The structural mitigations:
<external_content source="untrusted">
— and training or prompting the model to treat such content as data, not instructions, reduces but does not eliminate injection risk.The root issue — that MCP tool results carry no cryptographically attestable provenance — is not patched by any of the above mitigations. They reduce the attack surface and increase detection probability, but they do not give the model a reliable way to distinguish trustworthy from untrusted content in its context window. That requires a protocol-level solution: a provenance field on tool results with a verifiable binding to the server's identity, analogous to TLS certificate verification at the transport layer.
Until such a mechanism exists and is widely deployed, the confused-deputy risk in MCP is structural. Defenders cannot patch it away — they can only reduce exposure through layered detection, strict network controls, and architectures that treat all external tool results as untrusted by default.
For the network-layer RCE class of MCP vulnerability and AEGIS fast-path detection, see Anthropic MCP RCE: 7,000 Servers Exposed and Why L1 Fast-Path Matters. For Sable's agentic security assessment offering, see our engagement options.