The Model Context Protocol widened the attack surface
Author:
Logan Matson
Time for reading:
5 min read

What the Model Context Protocol solved
The move from isolated chatbots to integrated agents was enabled by a connectivity standard. Anthropic released the Model Context Protocol in November 2024 and donated it to the Agentic AI Foundation under the Linux Foundation in December 2025. It runs over JSON-RPC 2.0 and defines how an AI application discovers, invokes, and exchanges data with external resources.
Before that standard, connecting a set of agents to enterprise tools meant writing bespoke point-to-point integration code, with custom authentication, error handling, and data formatting for every agent-tool pair. The protocol resolves that N times M problem: build one server per system, and any compatible client can reach it.
Adoption followed quickly. By early 2026 the protocol had passed 97 million monthly SDK downloads across more than 17,000 public servers, and OpenAI, Google DeepMind, and Microsoft had all shipped support within thirteen months of launch. That infrastructure is what makes a market in licensed tools, agent skills, and prompt packages possible at all.
What it expanded
The same connectivity widened the supply chain risk surface considerably, because the protocol inverts the usual direction of network interaction. Instead of human clients requesting data from controlled servers, servers expose tool metadata and execute actions on behalf of non-deterministic AI clients. The NSA’s guidance on this is blunt: the protocol shipped with a flexible and underspecified design, and its proliferation outpaced its security model.
The consequences showed up fast. Researchers filed more than 30 CVEs against MCP servers, clients, and proxy packages in the first months of 2026. A scan of public address space in early 2026 found nearly 7,000 internet-exposed servers running default transport configurations that permitted unauthenticated remote code execution. The most severe finding, CVE-2025-6514, carried a CVSS score of 9.6 and affected the widely used mcp-remote proxy package.
Prompt injection and tool poisoning
Beyond configuration flaws, the models themselves bring failure modes that no amount of network hardening addresses. Because a language model consumes trusted system instructions and untrusted user input in the same channel, as natural language, it has no reliable way to tell a command from data that merely looks like one.
That gap is exploitable at a distance. If an agent is authorized to read email or scrape a website, an attacker can plant instructions in that external content, an indirect prompt injection. Once the agent processes the poisoned input it may change behavior, exfiltrate data, or take a destructive action, all while appearing to operate normally.
Tool poisoning attacks the discovery layer instead. An attacker who can alter a third-party server’s tool descriptions or parameter schemas can mislead the model during planning, so it misuses a legitimate tool rather than calling a malicious one. Detection is genuinely hard here, which is why work on evidence-based detection for MCP traffic is active.
Signing would help, and it is worth asking for. As of early 2026, though, there is no widely adopted initiative to sign agent skills, which makes provenance a control buyers should demand rather than one they can assume.
Defense in depth
Relying on a foundation model’s built-in alignment filters is not a security posture. Those defenses are routinely bypassed, and treating them as a boundary means having no boundary.
The architectural answer is to stop asking one model to distinguish instructions from data. The dual-LLM pattern, proposed by Simon Willison in 2023 and now well documented, splits the job: a privileged model plans actions and calls tools but never sees untrusted content, while a quarantined model processes untrusted text and has no tool access at all. Results pass between them as opaque variables the privileged model cannot read. It separates command logic from content by construction rather than by instruction.
The same principle applies to the prompts themselves. A licensed prompt package is a structured asset, not a string of text: role and style instructions, prompt chains for multi-stage tasks, domain-specific components, and audit and guardrail prompts that check consistency and facts. Treated that way, prompts get versioned, reviewed, and tested like any other software component, and they carry their own input validation and output schema enforcement.
At the network layer, a gateway centralizes what would otherwise be reimplemented per server: identity mapping against an existing provider, role-based access control, agent isolation, and an audit trail on every tool call. The build-versus-buy question there turns on governance speed rather than engineering cost, since audit logging bolted on per server tends to be inconsistent where it exists at all.
None of this is exotic. It is the same discipline applied to any component with production access: bound what it can reach, verify what it produces, log what it did, and assume the input is hostile. The protocol made the connections easy. It did not make them safe.
What the Model Context Protocol solved
The move from isolated chatbots to integrated agents was enabled by a connectivity standard. Anthropic released the Model Context Protocol in November 2024 and donated it to the Agentic AI Foundation under the Linux Foundation in December 2025. It runs over JSON-RPC 2.0 and defines how an AI application discovers, invokes, and exchanges data with external resources.
Before that standard, connecting a set of agents to enterprise tools meant writing bespoke point-to-point integration code, with custom authentication, error handling, and data formatting for every agent-tool pair. The protocol resolves that N times M problem: build one server per system, and any compatible client can reach it.
Adoption followed quickly. By early 2026 the protocol had passed 97 million monthly SDK downloads across more than 17,000 public servers, and OpenAI, Google DeepMind, and Microsoft had all shipped support within thirteen months of launch. That infrastructure is what makes a market in licensed tools, agent skills, and prompt packages possible at all.
What it expanded
The same connectivity widened the supply chain risk surface considerably, because the protocol inverts the usual direction of network interaction. Instead of human clients requesting data from controlled servers, servers expose tool metadata and execute actions on behalf of non-deterministic AI clients. The NSA’s guidance on this is blunt: the protocol shipped with a flexible and underspecified design, and its proliferation outpaced its security model.
The consequences showed up fast. Researchers filed more than 30 CVEs against MCP servers, clients, and proxy packages in the first months of 2026. A scan of public address space in early 2026 found nearly 7,000 internet-exposed servers running default transport configurations that permitted unauthenticated remote code execution. The most severe finding, CVE-2025-6514, carried a CVSS score of 9.6 and affected the widely used mcp-remote proxy package.
Prompt injection and tool poisoning
Beyond configuration flaws, the models themselves bring failure modes that no amount of network hardening addresses. Because a language model consumes trusted system instructions and untrusted user input in the same channel, as natural language, it has no reliable way to tell a command from data that merely looks like one.
That gap is exploitable at a distance. If an agent is authorized to read email or scrape a website, an attacker can plant instructions in that external content, an indirect prompt injection. Once the agent processes the poisoned input it may change behavior, exfiltrate data, or take a destructive action, all while appearing to operate normally.
Tool poisoning attacks the discovery layer instead. An attacker who can alter a third-party server’s tool descriptions or parameter schemas can mislead the model during planning, so it misuses a legitimate tool rather than calling a malicious one. Detection is genuinely hard here, which is why work on evidence-based detection for MCP traffic is active.
Signing would help, and it is worth asking for. As of early 2026, though, there is no widely adopted initiative to sign agent skills, which makes provenance a control buyers should demand rather than one they can assume.
Defense in depth
Relying on a foundation model’s built-in alignment filters is not a security posture. Those defenses are routinely bypassed, and treating them as a boundary means having no boundary.
The architectural answer is to stop asking one model to distinguish instructions from data. The dual-LLM pattern, proposed by Simon Willison in 2023 and now well documented, splits the job: a privileged model plans actions and calls tools but never sees untrusted content, while a quarantined model processes untrusted text and has no tool access at all. Results pass between them as opaque variables the privileged model cannot read. It separates command logic from content by construction rather than by instruction.
The same principle applies to the prompts themselves. A licensed prompt package is a structured asset, not a string of text: role and style instructions, prompt chains for multi-stage tasks, domain-specific components, and audit and guardrail prompts that check consistency and facts. Treated that way, prompts get versioned, reviewed, and tested like any other software component, and they carry their own input validation and output schema enforcement.
At the network layer, a gateway centralizes what would otherwise be reimplemented per server: identity mapping against an existing provider, role-based access control, agent isolation, and an audit trail on every tool call. The build-versus-buy question there turns on governance speed rather than engineering cost, since audit logging bolted on per server tends to be inconsistent where it exists at all.
None of this is exotic. It is the same discipline applied to any component with production access: bound what it can reach, verify what it produces, log what it did, and assume the input is hostile. The protocol made the connections easy. It did not make them safe.


