| Internet-Draft | MCP Security Considerations | June 2026 |
| Syed | Expires 3 December 2026 | [Page] |
The Model Context Protocol (MCP) connects large language models (LLMs) to external tools, data sources, and services. The MCP specification does not define normative security requirements. This document analyzes recurring vulnerability classes that have been publicly reported in MCP server implementations, describes an automated detection approach implemented in the open-source tool mcp-safeguard, and proposes security considerations and mitigations for implementors and operators. The document also describes Protocol Pivoting, a cross-protocol lateral-movement pattern in systems that compose MCP with other agent protocols.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 December 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The Model Context Protocol (MCP) is an interface for connecting LLMs to external capabilities. The protocol enables AI agents to invoke tools exposed by MCP servers, which are software components that accept tool calls from an AI host and execute operations against external systems.¶
The MCP specification does not include normative security requirements. This document analyzes vulnerability classes that arise from that gap, references public reports of those vulnerabilities in specific implementations, describes an automated detection approach, and offers guidance to implementors and operators.¶
The detection approach described in this document is implemented in mcp-safeguard, an open-source automated MCP security scanner developed by the author that performs black-box evaluation of running MCP servers. Detection results referenced in this document were obtained against controlled test fixtures that model the vulnerability classes described in Section 4. Independent research, such as MCPTox, reports high attack-success rates against production MCP servers and corroborates that these classes are exploitable outside controlled environments.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
An MCP deployment consists of three components:¶
The trust relationship is asymmetric. The host trusts the server to correctly scope its tool effects, and the server trusts tool call parameters to originate from an authorized host with vetted inputs. Both assumptions are frequently violated in practice.¶
Tool call parameters originate from LLM reasoning, which is susceptible to prompt injection. An adversary who can influence the content the LLM processes can influence tool call parameters. MCP servers MUST treat all tool call parameters as untrusted.¶
MCP servers that accept URL parameters and pass them to HTTP clients without validating the resolved IP address are vulnerable to SSRF. An adversarial prompt can cause such a tool to request:¶
Naive mitigations that block a literal metadata IP can be bypassed by DNS rebinding, where a hostname resolves to a public address at validation time and to a restricted address at connection time, and by redirect chains, where an allowed URL returns an HTTP 3xx redirect to a restricted destination.¶
MCP filesystem tools frequently expose paths beyond what their documented function requires, allowing an adversarial prompt to read arbitrary files.¶
Some MCP tools return content from external sources to the LLM without sanitization, allowing an adversary who controls that content to inject instructions that alter the agent's subsequent behavior.¶
Some implementations answer tools/list before the initialize handshake completes, which can skip access-control logic applied during initialization.¶
Some servers return verbose errors including stack traces, internal paths, and dependency versions, which aid fingerprinting.¶
Some servers answer tool calls without verifying authentication, which is especially serious for servers exposing code execution or filesystem access.¶
This section references public reports of the SSRF class. These reports were filed by their respective reporters in public issue trackers and are cited here as evidence that the class occurs in deployed implementations. This document does not claim authorship of those reports.¶
SSRF affecting an HTTP-fetching MCP server in the modelcontextprotocol/servers repository has been discussed in public issues, including issues 4116, 4143, and 4205. The reported pattern matches the SSRF class above: a URL parameter passed to an HTTP client without IP validation, reachable through DNS rebinding and redirect chains.¶
SSRF affecting a browser-automation MCP server has been discussed in public issue 1626 of the microsoft/playwright-mcp repository. Because such servers may run with access to a local browser profile, the reported impact includes access to internal services and to authenticated session state.¶
mcp-safeguard implements black-box probes for the classes above. For SSRF, it submits a benign request to a controlled external host, a request that redirects to a restricted address, and a direct metadata-endpoint request, and it classifies a server as affected when a restricted destination is reachable. Against test fixtures modeling the SSRF class, mcp-safeguard detects the class and emits machine-readable findings suitable for use in continuous integration. Validation against production deployments is future work and is not claimed here.¶
This document describes Protocol Pivoting, a lateral-movement pattern in systems that compose multiple agent protocols, for example MCP for tool invocation together with Agent-to-Agent (A2A) delegation and an autonomous negotiation protocol. Related work has described pivoting within a shared MCP context; this document focuses on movement that crosses protocol boundaries.¶
An adversary who gains influence over one protocol layer can use that influence to act across other layers:¶
Mitigations that consider each protocol in isolation do not address movement that crosses protocol boundaries. This is identified here as an area for further analysis.¶
URL validation: servers that accept URL parameters MUST validate the resolved IP address before issuing requests, and MUST perform this check at connection time rather than at parse time to resist DNS rebinding. Servers SHOULD block RFC 1918 ranges, loopback, link-local (169.254.0.0/16, fe80::/10), and other non-routable ranges.¶
Network egress: server processes SHOULD run with egress restrictions enforced at the OS or container level, independent of application validation.¶
Redirects: servers SHOULD NOT follow HTTP redirects by default. When redirects are followed, each destination MUST undergo the same IP validation as the original URL.¶
Tool permission scoping: filesystem tools MUST scope path access to the minimum set of directories required, and MUST NOT expose root filesystem access absent explicit operator configuration.¶
Lifecycle enforcement: servers MUST NOT process tool calls before the initialize handshake completes.¶
Logging: servers SHOULD emit structured, attributable logs of tool invocations to support detection and incident response.¶
Operators deploying MCP-based systems SHOULD apply network egress controls, run servers with least privilege, and monitor tool invocations. Operators SHOULD treat any MCP server that processes externally controlled content as exposed to prompt injection and SHOULD constrain the effects available to such servers.¶
This document has no IANA actions.¶