MCP security — the four attack surfaces of a Model Context Protocol server

MCP defines how a host application — the LLM runtime and its surrounding orchestration layer — communicates with external servers. Each MCP server exposes three categories of extension:

• Tools — callable functions. Each tool has a name, a natural-language description, and a JSON Schema defining its parameters. The model reads the description to determine when and how to invoke the tool.
• Resources— data the server exposes for the model to read. Files, database rows, API responses. Resources are retrieved and injected into the model's context window.
• Prompts — reusable prompt templates. The host can request a template and inject it into the conversation turn.

Transport options are stdio (the host spawns the MCP server as a local subprocess) and HTTP with Server-Sent Events (the host connects to a remote MCP server over HTTP). The protocol session is stateful — the host maintains a persistent connection with each server for the duration of an agent session.

The design implication that matters most for security: the model reads the tool descriptions, resource content, and prompt templates that MCP servers provide as part of its context. Anything a server injects into that context can influence the model's decisions. This is not a flaw — it is the intended mechanism. But it means that the security boundary for an MCP-connected system is not just the application layer. It extends into every server the model is connected to.

An MCP deployment has four distinct attack surfaces. They are independent: a control that addresses the transport surface provides no protection against a tool-surface attack, and vice versa. Traditional application security coverage addresses the transport layer reasonably well. It misses the other three almost entirely.

The four surfaces are: the transport layer (how the host and server communicate), the tool surface (the tools the server exposes), the context injection surface (the data that flows from the server into the model's context), and the authentication boundary (how the server verifies the identity of the caller and the end user). Each is addressed in turn below.

The transport surface covers how messages flow between the host and the MCP server. For stdio transports, the server runs as a local subprocess: messages pass through standard input and output. For HTTP/SSE transports, messages travel over the network as HTTP requests and server-sent events.

The security requirements differ significantly by transport type. Stdio transport inherits the security context of the host process and the local operating system. The primary concerns are process isolation — can other processes on the same host connect to or interfere with the MCP server subprocess? — and local file permissions, since stdio servers often need access to the filesystem.

HTTP/SSE transport exposes all the usual network-layer concerns: whether TLS is enforced end-to-end, whether certificate validation is correctly implemented, and for sensitive deployments, whether mutual authentication is in place to verify both the server and the client. The MCP specification does not mandate TLS. Many implementations in assessed systems operate over plaintext HTTP, particularly in internal or development deployments where the assumption is that the network is trusted.

Review questions for the transport surface: Is TLS enforced for all HTTP/SSE transports? Is certificate validation active (not bypassed)? For stdio transports, is the subprocess run with the minimum required OS permissions? Can the server process be reached by processes other than the intended host?

For a full treatment of transport-layer security requirements and review evidence, see Transport security for MCP servers.

The tool surface is the set of tools the MCP server exposes. Each tool is defined by its name, description, and parameter schema. The model reads the description to decide when to invoke the tool and what arguments to pass. This makes the tool description a direct input to the model's decision-making process — and therefore an attack surface.

Tool poisoning — the attack where a malicious tool description manipulates the model into invoking tools outside its intended scope, revealing information it should not, or passing arguments that downstream systems will misinterpret — is the highest-severity threat on this surface. It exploits the fact that the model treats tool descriptions as authoritative context about what a tool does and when to use it.

Beyond poisoning, the tool surface raises questions about excess capability: does the server expose tools that the specific deployment context does not need? Every tool in the manifest is a capability the model can exercise. Least-privilege principles apply to the tool manifest just as they apply to API permissions.

Review questions for the tool surface: Is each tool in the manifest justified for this deployment? Are tool descriptions accurate and minimal — do they describe what the tool does without embedding instructions to the model? Is the manifest served from a version-controlled, authenticated source? Are destructive tools (write, delete, execute, send) gated behind an explicit approval step?

For a detailed analysis of tool poisoning mechanics and controls, see Tool poisoning in MCP servers.

The context injection surface covers the data that MCP servers return and that ends up in the model's context window. This includes tool results (the response to a tool invocation), resources (documents, records, API data fetched and injected into context), and prompt templates (reusable instruction fragments the server provides).

When that data contains instructions — either deliberately placed by an attacker who controls the data source, or accidentally present in content the server fetches — the injection vector is the MCP server itself. This is indirect prompt injection: the attacker does not interact with the model directly. They place instructions in a resource or data source that the MCP server will eventually fetch and inject into the model's context.

The context injection surface is the attack surface that most AI security reviews miss entirely. It looks like a data pipeline. Its security implications are those of a prompt channel. Every data source that flows into model context through an MCP server must be treated as untrusted input to the reasoning engine, not as trusted output from a data system.

Review questions for the context injection surface: Are tool results treated as untrusted data before being passed to the model? Is there output validation between the MCP server response and the model context injection? Do prompt templates contain secrets, credentials, or internal policy text that should not be exposed? Are resources scoped to the minimum required for the task?

For a full treatment of context injection via MCP tools, see Prompt-context injection through MCP tools.

The authentication boundary surface covers how the MCP server verifies who is calling it and what they are permitted to do. In most MCP implementations, the server authenticates the client (the agent host) — not the end user who initiated the agent session. This creates a structural gap: when multiple users share an agent that calls an MCP server, the server may have no way to enforce per-user authorization unless that layer is explicitly built in.

The failure mode is that all users of the agent effectively share the MCP server's client-level permissions. A user who can invoke the agent can, through it, invoke any tool the agent has access to — regardless of what that user would be permitted to do if they called the underlying service directly.

Review questions for the authentication boundary: Does the MCP server require client authentication before accepting tool invocations? Is per-user authorization enforced at the MCP layer or delegated to downstream services? Are the server's credentials managed and rotated? Does the server run under a least-privilege identity?

For a full treatment of the MCP authentication gap and the controls that close it, see The MCP authentication boundary, reviewed.

A security review of an MCP deployment must address all four surfaces. Reviews that focus only on the transport layer — the surface most familiar to infrastructure and AppSec teams — will miss the tool-surface, context-injection, and authentication threats that account for the majority of high-severity control gaps in assessed systems.

The review should be structured around three questions for each surface:

1. What is the threat? — What can an attacker do if this surface is not controlled? What is the blast radius?
2. What controls are in place? — What mechanisms exist to detect, prevent, or limit exploitation at this surface? Are those mechanisms design-time controls (in the architecture and configuration) or operational controls (monitoring and response)?
3. What evidence is required? — What artefact demonstrates that the control is in place and effective? A review assertion is not evidence. A test result, configuration excerpt, or audit log sample is.

The cluster articles below go deep on each surface. The capstone checklist — An MCP server security review checklist — brings the four surfaces together into a structured review document you can use directly in an assessment.

MCP security cluster

• Transport security for MCP servers — TLS, stdio isolation, mutual auth
• Tool poisoning in MCP servers — how malicious descriptions manipulate the model
• Prompt-context injection through MCP tools — tool results as injection vectors
• The MCP authentication boundary, reviewed — client auth vs user auth gap
• Vetting a third-party MCP server before you connect it — supply-chain review
• Securing an internal MCP server exposed to agents — internal deployment checklist
• MCP security vs traditional API security — what the traditional model misses
• An MCP server security review checklist — structured review document
• Threat modeling an MCP server — 11 threats across 4 surfaces with controls