IETF MCP Draft Turns Tool Safety Into a Standards Problem

An individual IETF Internet-Draft published in June 2026, Security Considerations for Model Context Protocol Implementations in AI Agent Systems, catalogs 6 recurring MCP vulnerability classes and states that the MCP specification defines no normative security requirements. It is not an IETF standard and has no formal standing. It is still the clearest public map of the gap.

Updated September 2026: the draft is still at revision 00. No IETF working group has adopted it, and it expires on 3 December 2026. Treat it as a reading list with section numbers, not as a conformance target.

The author is Anas Mohiuddin Syed. The document is Informational in intent, 10 sections long, and its abstract is blunt about the premise:

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.

— draft-mohiuddin-mcp-security-considerations-00, Abstract

The gap is real but narrower than “MCP has no security document.” The protocol’s own maintainers publish security best practices alongside the authorization spec, with MUST-level rules on confused-deputy consent, token passthrough, session IDs and SSRF during OAuth discovery. What the draft adds is the server implementor’s side of the problem — the tool surface itself — and a vocabulary for it.

The 6 vulnerability classes

Class	What goes wrong	Draft section
Server-Side Request Forgery	A URL parameter is passed to an HTTP client with no validation of the resolved IP	4.1
Excessive Tool Permissions	Filesystem tools expose paths beyond what their documented function needs	4.2
Prompt Injection Surface Exposure	External content is returned to the model unsanitized	4.3
MCP Lifecycle Bypass	tools/list is answered before the initialize handshake completes	4.4
Information Leakage	Verbose errors return stack traces, internal paths and dependency versions	4.5
Authentication Enforcement Gaps	Tool calls are served without verifying authentication	4.6

Those names matter more than they look. Before them, every MCP incident was reported as its own story; with them, a scanner, a checklist and a bug report can refer to the same thing.

What Changed

The draft is useful because it turns scattered MCP incidents into named classes.

SSRF is the easiest class to understand. A server exposes a tool that accepts a URL, then fetches that URL on behalf of the agent. If the server does not block link-local, loopback, private network, or redirected destinations, a prompt-injected agent can ask it to fetch cloud metadata services, internal admin panels, local-only endpoints, or other resources the attacker cannot reach directly.

That is not a theoretical edge case. A Full Disclosure advisory describes an attack path where a malicious webpage influences an agent using mcp-server-fetch or playwright-mcp, then steers the tool toward the AWS metadata endpoint. If the host is in the wrong cloud configuration, the tool can return credential material to the agent context. The draft cites the public trail for that class directly: issues 4116, 4143 and 4205 in modelcontextprotocol/servers, and issue 1626 in microsoft/playwright-mcp.

Figure: the draft’s section 7 and 8 requirements, in the order a request meets them. The fourth checkpoint exists precisely because the first three are code that can have bugs.

The deeper issue is delegation. An MCP server is often trusted because the agent host can reach it. The downstream resource is then trusted because the MCP server can reach it. A prompt-injected page, document, issue comment, email, or support ticket can become the first step in a confused-deputy chain.

That pattern applies beyond SSRF. A filesystem tool can expose more paths than intended. A browser automation tool can run with an authenticated browser profile. A server can answer tools/list before initialization gates apply. A verbose error can leak paths, versions, and internal structure. A tool can accept model-filled arguments without treating them as untrusted input.

Those are normal software bugs. MCP makes them agent-native bugs because the caller is not a fixed application path. The caller is a model reasoning over untrusted content. The draft puts that in normative terms: MCP servers MUST treat all tool call parameters as untrusted, because those parameters originate from LLM reasoning that an adversary may have influenced.

Why Public Issues Matter

One reason this story is important is that the evidence is not hidden inside private security reports. Much of it is happening in public.

The modelcontextprotocol and Playwright MCP issues are developer-facing debates about whether URL-fetching tools need network allowlists, redirect validation, cloud metadata blocking, and DNS rebinding defenses. Snyk’s advisory for CVE-2026-44428, an SSRF-class issue in the MCP registry publisher auth package, shows that even registry-adjacent MCP infrastructure can carry supply-chain-relevant authentication flaws. CloudSEK’s case study on unauthenticated MCP, SSRF, LFI, and AWS credential theft shows the operational version: an unauthenticated MCP endpoint with a proxy-like tool can turn into credential exposure. Trend Micro’s sweep of more than 19,000 MCP server repositories shows the scale problem: thousands of servers, many written quickly, some with exploitable bugs, and too many for hand review.

The draft is candid that its own detection results come from controlled fixtures rather than production servers, and it points at independent work for the field evidence. MCPTox is the load-bearing citation there: a benchmark built on 45 live MCP servers and 353 real tools, generating 1,312 malicious test cases, which measured a 36.5% average attack success rate across models and 72.8% against the most susceptible one. The counterintuitive result is that more capable models scored worse, because the attack rides on their instruction-following.

That public trail matters for two reasons.

First, it gives security teams concrete things to audit. Do we run URL-fetching MCP servers? Do any run in cloud environments with metadata access? Do browser automation tools use real user profiles? Do local tools accept file paths or URLs from model-generated arguments? Do any servers answer before authentication or initialization completes?

Second, it shows why MCP security cannot be left to individual prompt warnings. A malicious instruction hidden in a webpage is not the only control point. The server should reject dangerous destinations. The network should block egress to metadata and internal ranges. The host should require authentication and least privilege. The scanner should flag tool surfaces that combine untrusted inputs with sensitive sinks.

The agent may be the thing making the call, but the server still owns its security boundary.

Protocol Pivoting Is The Next Problem

The most interesting section of the draft is not SSRF. It is section 6, on protocol pivoting.

The draft describes a cross-protocol lateral-movement pattern in 4 steps: untrusted content affects an MCP-using agent, the agent invokes a tool against an internal service, then delegates work through an agent-to-agent channel, and the downstream agent negotiates with an external service under the originating agent’s inherited identity.

Figure: each hop is a legitimate call for the layer it lives in, which is why controls that examine one protocol at a time never see the chain.

That is exactly where the agent ecosystem is heading.

MCP handles tool invocation. Agent-to-agent protocols handle delegation. Marketplaces handle discovery. Skills and plugin bundles shape behavior before the agent ever selects a tool. Hosted connectors can change behavior server-side. Local desktop agents can bridge all of this into a developer’s machine.

Security controls that treat each layer in isolation will miss the chain.

A poisoned skill can steer an agent toward a legitimate MCP tool. A vulnerable MCP server can expose credentials that make a connector more powerful. A connector can pass data to another agent that was never meant to receive it. A marketplace update can alter a tool description after review. None of those steps requires the model itself to be compromised.

This is why SkillSafe keeps using the supply-chain lens. The artifact may be a Markdown skill, an MCP server, a connector manifest, an OAuth app, a tool schema, or an agent card. The practical question is the same: what capability did this add, who controls it, what can it reach, and has it changed since approval?

What Teams Should Do Now

Start by inventorying MCP servers the same way you inventory packages and OAuth apps. Include local developer machines, CI runners, cloud workloads, desktop assistants, browser automation servers, and any connector platform that exposes MCP-compatible tools. The 12 checks we run before install, at the call, in flight, and continuously are the working version of the sequence below.

For each server, record the source, version, deployment location, transport, authentication model, exposed tools, tool descriptions, schemas, credential scopes, and network reach. Mark tools that can fetch URLs, read files, write files, execute commands, drive browsers, query databases, send messages, open tickets, or call cloud APIs.

Then separate tool categories by blast radius. Documentation search and weather lookup do not need the same policy as shell execution, cloud admin, filesystem write, or authenticated browser automation. High-risk tools should require stronger review, explicit human approval for sensitive actions, and better logs.

Treat model-filled arguments as hostile. Validate URLs at connection time, not just parse time. Block RFC 1918 ranges, loopback, link-local addresses, and cloud metadata endpoints. Validate every redirect destination. Scope filesystem tools to explicit directories. Parameterize database calls. Avoid shell-built command strings. Require authentication before answering tool calls or tool listings.

Put egress controls below the application. If an MCP server has no legitimate reason to reach the cloud metadata address, local admin panels, private subnets, or arbitrary domains, the network should enforce that even if application validation fails.

Scan the server and the artifact. MCP-aware scanning should inspect tool descriptions, schemas, handlers, risky imports, command execution paths, URL-fetching behavior, filesystem reach, and authentication gates — the checklist we keep at /mcp-security/ maps to the same classes. Skill and plugin scanning should flag instructions that combine network access, credential reads, memory writes, or command execution.

Finally, review drift. A new tool, changed schema, broader OAuth scope, changed tool description, new dependency, or hosted endpoint change should not inherit the previous approval automatically.

Where SkillSafe Fits

SkillSafe focuses on the artifact layer: AI skills and plugin-like files that shape agent behavior before an agent acts. The MCP security draft is a reminder that this layer sits inside a larger tool supply chain.

A skill can tell an agent how to behave. A plugin can give it a new capability. An MCP server can expose that capability to a model. A connector can bind it to a business system. An agent-to-agent protocol can delegate it to another actor.

Attackers only need one weak link in that path.

That is why dual-side verification matters. Publisher-side scanning creates a baseline before sharing. Consumer-side scanning checks what actually arrives before install. Cryptographic hashes tie the scan report to the artifact, so a clean review cannot drift away from the installed files.

The same idea should extend to MCP and connector governance: pin what was reviewed, scan what can influence the model, compare what is installed against what was approved, and require a new decision when the capability surface changes.

We have covered pieces of this before: tool poisoning through hidden MCP metadata, MCP plugins as executable code, MCP inventory and operational guidance, taint tracking across tool boundaries, and Agent Bills of Materials. The new draft connects those pieces into a standards-shaped conversation.

It is still early. This is not a finished standard, and teams should not treat it as one. But the direction is right: MCP security needs named vulnerability classes, testable mitigations, operator guidance, and machine-readable findings that can fit into CI and asset inventory.

Agent tooling is becoming real infrastructure. Real infrastructure needs more than trust-by-install.

Frequently Asked Questions

Is the IETF MCP security draft a standard?

No. It is an individual Internet-Draft at revision 00, Informational in intent, not adopted by any working group, and it expires on 3 December 2026. Internet-Drafts are explicitly working documents that should be cited only as work in progress. Its value is the vocabulary — 6 named classes with section numbers you can put in a bug report or a checklist.

Are MCP servers a security risk?

Any MCP server is a tool-execution surface reachable by a model reading untrusted content, so yes, in proportion to what its tools can do. The draft’s 6 classes are the recurring failures. The MCPTox benchmark measured a 36.5% average attack success rate for tool poisoning across 45 live servers, which is the closest thing to a base rate currently published.

How do you secure an MCP server?

Four layers, in order of how much they save you. Treat every tool argument as untrusted; validate resolved IPs at connect time and re-check each redirect; scope filesystem and credential reach to the minimum; and enforce egress policy at the OS or container level so an application bug is not the last line of defence. The MCP security best practices page covers the authorization half.

What is protocol pivoting?

A lateral-movement pattern where influence over one agent protocol carries into another: an injected instruction reaches an MCP-using agent, the agent calls a tool against an internal service, delegates to a downstream agent over an agent-to-agent channel, and that agent acts under inherited trust. Each hop is legitimate for its own layer, so per-protocol controls never see the chain.

What are the best practices for MCP authentication?

Require authentication before answering tool calls or tools/list, and never process a call before the initialize handshake completes — the draft makes both MUST-level. On the authorization side, the MCP spec forbids token passthrough outright: a server MUST NOT accept a token that was not issued for it, and MUST NOT use a session ID as an authentication mechanism.