IETF MCP Draft Turns Tool Safety Into a Standards Problem

The most useful agent security story this week is not a single zero-day. It is the appearance of a new security draft that says the quiet part out loud: MCP has become infrastructure before its security expectations have become infrastructure-grade.

In early June, Anas Mohiuddin Syed published an individual IETF Internet-Draft, Security Considerations for Model Context Protocol Implementations in AI Agent Systems. The document is not an IETF-endorsed standard. Internet-Drafts are working documents, and this one has no formal standing yet. That caveat matters.

The reason it still matters to developers is that it collects the security conversation now happening in public issue trackers, mailing lists, vulnerability databases, and vendor research: MCP servers are not just convenience adapters. They are tool-execution surfaces that need authentication, permission boundaries, input validation, egress controls, logging, and review when exposed capabilities change.

The draft’s core claim is simple: the MCP specification does not define normative security requirements. From that gap, it catalogs recurring vulnerability classes including SSRF, excessive tool permissions, prompt-injection surface exposure, lifecycle bypass, information leakage, and authentication enforcement gaps.

That framing landed at the same time as several public reports kept the issue active. A Full Disclosure advisory described SSRF risk in Anthropic mcp-server-fetch and Microsoft playwright-mcp, pointing to public GitHub issues in modelcontextprotocol/servers #4116, #4143, #4205, and microsoft/playwright-mcp #1626. Snyk also published CVE-2026-44428, an SSRF-class issue in the MCP registry publisher auth package. CloudSEK published a fresh case study on unauthenticated MCP, SSRF, LFI, and AWS credential theft. Trend Micro’s recent sweep of more than 19,000 MCP server repositories found that the ecosystem is growing faster than manual review can handle.

That is why this is the story to watch. The public discussion has moved from “MCP tools can be risky” to “MCP needs a security profile that implementors and operators can actually test against.”

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. The 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 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.

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. The Snyk advisory shows that even registry-adjacent MCP infrastructure can carry supply-chain-relevant authentication flaws. CloudSEK’s case study shows the operational version: an unauthenticated MCP endpoint with a proxy-like tool can turn into credential exposure. Trend Micro’s research shows the scale problem: thousands of MCP servers, many written quickly, some with exploitable bugs, and too many for hand review.

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 the discussion of protocol pivoting.

The draft describes a cross-protocol lateral-movement pattern where influence over one layer can carry into another: 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 acts under inherited trust.

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.

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 169.254.169.254, 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. 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, 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.