MCP Security Testing 2026: Model Context Protocol Risks

The Model Context Protocol standardises how AI agents connect to external tools. That standardisation is what makes MCP powerful, and also what makes it dangerous. Before MCP, every AI integration was ad hoc, meaning every attacker had to write custom exploits. With MCP, every server implementation shares the same protocol surface, meaning every attacker can write one exploit and apply it across thousands of deployed servers.

Anthropic's reference implementation went live in November 2024. By April 2026, security researchers had disclosed more than 40 CVEs across MCP SDKs, servers, clients, and marketplaces. The cadence is now approximately one CVE every four days. Most of these vulnerabilities are not exotic: missing input validation, absent authentication, and blind trust in tool descriptions. What is new is the attack surface. Testing MCP deployments requires methodology that legacy application security testing does not automatically cover.

What MCP Actually Is and Why It Creates a New Attack Surface

Model Context Protocol is a client server protocol. An MCP client (typically an AI agent framework such as Claude Desktop, Cursor, Continue, or a custom LangChain application) connects to one or more MCP servers. Each server exposes a set of tools, resources, and prompts that the agent can invoke. The transport is either STDIO for local processes or HTTP/Server Sent Events for remote servers.

The security-relevant properties of this architecture are three.

Tool descriptions become instructions to the LLM. When an MCP client connects to a server, the server sends a list of available tools with human readable descriptions. The client passes those descriptions to the underlying LLM as context. The LLM decides when and how to invoke tools based on those descriptions. If the description contains adversarial content, the LLM's decision-making is compromised before any user prompt is even processed.

Tool invocations are subprocess-like. The protocol's default transport is STDIO, which means MCP servers are often spawned as subprocesses of the client. Command execution is not a bug in MCP; it is the intended interface. Every implementation inherits this surface, and every implementation must independently sanitise it correctly.

Server metadata is trusted by default. MCP clients typically render server-provided content directly to the user or pass it directly to the LLM without sanitisation. This creates a straight injection path from a compromised server to the client's rendering context, and from server metadata to the agent's action space.

The consequence: a single compromised server, or a single malicious tool description, can achieve outcomes that traditional AppSec threat models would classify as impossible without direct memory access. Prompt injection via tool metadata is the AI-era equivalent of stored XSS, except the target is not just a web page but the agent's entire decision loop.

The MCP Attack Class Registry

Between April 2025 and mid 2026, security researchers named and documented a growing set of attack classes specific to MCP. Simon Willison, Invariant Labs, JFrog Security Research, CyberArk, and the OWASP MCP working group have contributed distinct terminology. The matrix below consolidates the twelve attack classes that any MCP security assessment should cover, mapped to the observable behaviour that a test must catch.

How to Test Each MCP Attack Class

Testing MCP deployments requires methodology that spans three planes: the MCP server itself, the MCP client that consumes it, and the agent runtime that interprets both. Each attack class in the registry above tests one or more of these planes. What follows is the operational methodology for each category.

Tool poisoning testing. Inject adversarial content into tool descriptions and observe whether the agent alters its behaviour based on that content. This is the MCP equivalent of stored prompt injection testing, except the payload lives in the tool metadata rather than user input. Test coverage includes hidden instructions, priming attacks, and directive language embedded in what appears to be documentation.

Rug pull testing. Establish tool behaviour baseline, then simulate silent server-side redefinition and observe whether the client detects the change or silently accepts new behaviour. Rug pulls exploit the fact that most MCP clients do not pin or verify tool versions after initial handshake.

Tool shadowing testing. Enumerate all tools across all connected MCP servers, identify name collisions, and observe which server actually receives invocations. Namespace conflicts are commonly resolved by connection order or by client heuristics that attackers can influence.

Cross server attack testing. Set up two or more MCP servers with intentional adversarial relationships. Trigger data flow from one to another via the agent and observe whether server isolation boundaries hold. Data pulled from Server A that lands in a prompt to Server B is a cross server attack surface.

Confused deputy OAuth testing. Audit the OAuth consent flows for MCP tool invocations. Test whether attacker-controlled input can cause the agent to invoke authorised tools on behalf of an attacker's request rather than the user's stated intent.

Toxic agent flow testing. Model realistic agent action sequences and observe whether sequences that individually appear authorised combine into unauthorised outcomes (data exfiltration, privilege escalation, cross-account access). Sequence level analysis catches what per-call authorisation misses.

Lethal trifecta testing. Map the agent's capability graph. Identify systems where the agent has (a) exposure to untrusted external content, (b) access to private data, and (c) ability to send data outbound. Any deployment where all three coexist is at risk of trifecta exploitation. Segregation of one of these three is the defence.

STDIO command injection testing. Fuzz all MCP tool arguments with shell metacharacters, argument delimiters, and command chaining syntax. Every argument that reaches subprocess spawn without sanitisation is command injection.

DNS rebinding testing. Verify local MCP servers bind only to localhost, verify origin headers are validated, and simulate DNS rebinding attacks against exposed HTTP transports.

Supply chain impersonation testing. Verify package provenance for every MCP server in the deployment. Cross-check package signatures, publisher identity, and download source against known legitimate distributions. The 2026 Oura MCP clone incident affected developers who had no automated provenance verification.

Unicode TAG concealment testing. Inspect tool metadata for Unicode tag blocks (U+E0000 to U+E007F) that render invisibly but carry instructions to the LLM. Canonicalise all metadata before passing to the model.

Client script gadget testing. Test whether server-supplied content renders unsafely in the client's UI (Markdown injection, HTML injection, script gadget triggers). This is traditional XSS testing adapted to the MCP client rendering context.

MCP Client, Server, and Tool Security Boundaries

Effective MCP security testing separates the three security boundaries in the architecture and tests each independently before testing them in combination.

The MCP client boundary. The client is what the user actually interacts with: Claude Desktop, Cursor, Continue, VS Code MCP integration, or a custom application. Testing the client focuses on how it renders server content, how it authenticates users, how it handles OAuth flows, and how it isolates data from different servers. CVE-2025-58357 (5ire desktop) and CVE-2025-6514 (mcp-remote) both exploit client-side gaps.

The MCP server boundary. The server exposes tools to any authenticated client. Testing the server focuses on authentication (or lack of it), authorisation enforcement, input sanitisation, subprocess argument handling, and metadata canonicalisation. CVE-2025-49596 (MCP Inspector Proxy) and CVE-2026-33032 (nginx-ui) both exploit server-side authentication gaps.

The tool boundary. Each tool exposed by a server has its own attack surface. Tools that shell out, tools that access files, tools that make network requests, and tools that call other tools each need per-tool assessment. Individual tool audit is where per-server penetration testing spends most of its time.

The composition problem. The three boundaries above interact. A safe server exposing safe tools connected to a safe client may still produce unsafe agent behaviour when combined with an adversarial second server, a confused OAuth flow, or a toxic agent sequence. Testing must cover both isolated components and realistic multi-server, multi-tool, agent-driven scenarios. This is why sequence-level and capability-graph testing (lethal trifecta, toxic flow) are as important as per-component testing.

What Enterprise Buyers and Auditors Ask About MCP

Enterprise procurement and compliance functions are catching up to MCP faster than most AI developers realise. The questions that arrive during vendor security reviews now include MCP-specific items that were unheard of even six months ago.

Which MCP servers does your application connect to? Direct question in vendor assessment questionnaires. Undocumented server connections raise immediate red flags.

What is your tool vetting process? Buyers want to see explicit vetting criteria, package signature verification, source-code review requirements, and version pinning policies.

How do you handle tool poisoning? Answers that mention "we trust the servers we use" are increasingly rejected. Expected answers involve technical controls: tool description sanitisation, adversarial content detection, or explicit human review of every tool description.

Do you test for OWASP Agentic AI Top 10? The OWASP Agentic AI Top 10 is becoming a standard reference in enterprise AI procurement. MCP-specific items map to several categories including tool misuse, over-privileged tools, and prompt injection.

Have your MCP integrations been independently tested? Third party testing evidence is starting to appear in enterprise SaaS procurement checklists. A named security firm's report is stronger evidence than internal review.

What is your incident response plan for compromised MCP servers? When (not if) a third party MCP server in your dependency chain is compromised, what is your process? This question mirrors the traditional supply chain questions but is specific to the MCP threat model.

Do you comply with EU AI Act Article 15(5)? For agents deployed in the EU, EU AI Act Article 15 explicitly requires resilience against adversarial content, which includes MCP tool poisoning and prompt injection through metadata.

How SecurityWall Tests MCP Deployments

SecurityWall's AI and LLM penetration testing service covers MCP-specific attack classes as a standard part of every agent-based engagement. Each engagement produces framework-mapped output calibrated for enterprise procurement review and, where relevant, EU AI Act Article 9 documentation.

Per-attack-class coverage. The twelve attack classes in the registry above are individually tested against your deployment. Coverage is documented per class with pass, fail, or not applicable rationale. Findings tie back to specific tools, servers, or client configurations rather than generic categories.

Framework mapping. Reports map findings to OWASP Agentic AI Top 10 categories, MITRE ATLAS techniques where applicable, and EU AI Act Article 15(5) adversarial resilience requirements for European deployments.

CVE cross-reference. Where a finding matches a publicly disclosed MCP CVE, the report cites the CVE identifier and NVD entry. This gives your compliance team, procurement team, and enterprise buyers an anchor to well-known reference material.

Multi-plane testing. Server assessment, client assessment, and tool-by-tool audit combined with realistic multi-server scenario testing for cross-server attacks, toxic agent flows, and lethal trifecta exposure.

Retest included. After remediation, critical and high findings are retested to confirm closure. Retest is part of the engagement fee, not a separate cost.

Concrete pricing is quoted in the 30 minute scoping meeting because it depends on the number of MCP servers, complexity of tool graph, and whether client-side testing is in scope. What is standard across every engagement: coverage of all twelve documented attack classes, framework mapping, and named credentialed testers.

Frequently Asked Questions

What is MCP and why does it need security testing? Model Context Protocol is an Anthropic-released open standard (November 2024) that lets AI agents connect to external tools, APIs, files, and services. It has been widely adopted by AI agent frameworks including Claude Desktop, Cursor, Continue, and hundreds of open source projects. MCP creates new attack classes (tool poisoning, rug pulls, tool shadowing, cross-server attacks, confused deputy OAuth flaws) that traditional application security testing does not automatically cover. Between January and April 2026, more than 40 CVEs were disclosed against MCP implementations, making dedicated MCP security testing a live requirement.

Is MCP security testing different from regular penetration testing? Yes. MCP-specific testing requires methodology for tool description injection, sequence level analysis of agent action chains, capability graph mapping for lethal trifecta exposure, and cross-server isolation testing. Standard web application penetration testing does not automatically cover these categories. That said, MCP servers are still software and still need traditional testing: input validation, authentication, authorisation, and STDIO input handling all remain relevant.

How much does an MCP security assessment cost? Pricing depends on scope. A single MCP server with 5 to 10 tools connected to one client is a smaller engagement than a full agent framework connecting to a dozen third party servers. SecurityWall quotes fixed-fee per engagement in the 30 minute scoping meeting. No annual retainer required.

Can automated scanners find MCP vulnerabilities? Partially. Automated MCP scanners (Enkrypt AI MCP Scan, Akto MCP Proxy, and others) catch some patterns, particularly known CVE signatures. However, one independent audit in April 2026 found approximately 78% false positive rate on YARA based MCP scanners. Sequence level attacks, lethal trifecta exposures, and Unicode concealment techniques require human-driven testing. Combining automated scanning with expert assessment produces the strongest coverage.

What is the OWASP Agentic AI Top 10 and how does it relate to MCP? The OWASP Agentic AI Top 10 is a 2025-2026 project cataloguing the most significant security risks in AI agent systems. Several OWASP categories map directly to MCP-specific risks: tool misuse, over-privileged tools, prompt injection, hallucination-triggered actions, and unauthorised code execution. Any MCP deployment security review should reference OWASP Agentic AI Top 10 as a mapping baseline.

Does EU AI Act Article 15(5) apply to MCP deployments? Yes for high risk AI systems deployed in the EU. Article 15(5) explicitly requires resilience against adversarial manipulation including inputs designed to cause the AI model to make a mistake. MCP tool poisoning, indirect prompt injection through server content, and confused deputy attacks all fall within this requirement. Independent testing evidence covering these categories is expected in the Article 9 technical documentation package.

Related reading:

• LLM Penetration Testing Guide
• Vibe Coding Security Checklist: 44 Checks Before Ship
• LLM Penetration Testing: Scope, Cost, Providers
• OWASP Top 10 for Agentic AI 2026
• Prompt Injection Testing Guide
• LLM Security and AI Red Teaming
• Game Theory Jailbreaking LLM Security
• EU AI Act Security Testing: What Article 9 Requires
• Why AI Audits Find Issues in the First Hour
• ISO 42001 AI Compliance