MCP security vs traditional API security — what changes

An MCP server shares infrastructure characteristics with a REST API:

• It listens on a network port (HTTP/SSE transport) or a process socket (stdio).
• It accepts structured requests (JSON-RPC).
• It authenticates callers using tokens or certificates.
• It authorises operations based on the caller's identity.
• It accesses backend systems (databases, APIs, filesystems) to fulfil requests.
• It returns structured responses.

A traditional API security review covers all of these properties. But it was designed for a client that is a deterministic software application. The client makes requests based on code: specific conditions trigger specific API calls with specific parameters. The client cannot be persuaded to make different calls by modifying the API's documentation.

The client of an MCP server is an LLM-based agent. It decides which tools to call, and with what parameters, based on its reasoning over the task context. That reasoning is influenced by the tool descriptions, the resources injected into its context, and the instructions it has received. It can be persuaded, manipulated, and hijacked through these channels — and none of those attack vectors are present in a deterministic API client.

The most important difference between MCP security and API security is the nature of the client. In traditional API security, the client is a deterministic system: given the same state and inputs, it makes the same API call. In MCP, the client is a probabilistic reasoning engine that synthesises context, applies learned patterns, and generates decisions that are not fully predictable from the inputs.

This difference has concrete security implications:

Attacker reach

An attacker trying to abuse a traditional API must gain the ability to make requests to the API — which typically means compromising the application, stealing credentials, or exploiting an authentication vulnerability. An attacker trying to abuse an MCP-connected system can target the model's reasoning instead: by modifying the tool descriptions, injecting content into the model's context through data sources the MCP server reads, or crafting user inputs that redirect the model's use of MCP tools. These attack paths do not require API-layer access.

Defense scope

Defending an API means defending the API's interface: the inputs it accepts, the authentication it requires, the responses it returns. Defending an MCP server means defending both the API-layer interface and the model's reasoning about that interface. The second layer does not exist in traditional API security.

REST APIs have documentation — OpenAPI specs, README files, developer portals. Documentation describes what the API does. It is not part of the API's attack surface because no deterministic client executes behaviour based on documentation. Documentation can be inaccurate or misleading without creating a security vulnerability.

MCP tool descriptions are different. They are not documentation — they are operational data that directly influences the model's decision-making. A model reads a tool description to determine when to invoke the tool and how to structure the invocation. A malicious or compromised tool description is therefore a direct attack on the model's behaviour — not an information accuracy problem.

The practical implication: the content of every tool description is in scope for the security review in a way that has no equivalent in API security review. The reviewer must ask: does this description accurately represent the tool, and does it contain any content that could be used to manipulate the model's invocation decisions?

API security review validates that the API behaves correctly when called correctly. MCP security review must additionally validate that the model will call the API correctly given its description — and that the description cannot be modified to cause the model to call it incorrectly. The documentation layer has become a security layer.

In a traditional API deployment, the trust boundary is at the API gateway or application layer. The security model is: requests from authenticated, authorised callers are trusted; requests from others are rejected. The trust decision happens at the protocol layer, before any application logic executes.

In an MCP deployment, the trust boundary is at the model's reasoning layer — inside the model. The model must distinguish between instructions it should follow (from the system prompt and the task context), data it should process (from tool results and resources), and content it should treat as potentially malicious (injection attempts embedded in data sources). This is not a protocol-layer enforcement — it is a probabilistic reasoning task.

The consequence: an MCP deployment cannot achieve security through protocol-layer controls alone. The protocol-layer controls (authentication, TLS, input validation) are necessary but not sufficient. The model-layer trust decisions — how the system prompt frames authority, how tool results are represented to the model, how the model is instructed to handle conflicting instructions — are security-relevant design decisions that have no equivalent in traditional API security.

Traditional API authorization models are explicit and role-based: a caller with role X can call endpoints in set Y. The authorization decision is deterministic: given a caller identity and a requested endpoint, the system returns allow or deny.

MCP authorization is more complex for two reasons. First, the caller is the agent — a shared identity that may represent many end users — rather than an individual user. This creates the per-user authorization gap described in The MCP authentication boundary, reviewed.

Second, the set of operations the model will attempt is not known at design time. A deterministic client makes a predictable set of API calls. An LLM agent makes calls based on its reasoning about the task — which means the set of tool invocations in a session is determined at runtime by the model, not at design time by the developer. Authorization must be enforced at the tool handler level (rejecting requests that exceed the caller's permissions), not just at the routing level.

A traditional API security review of an MCP server will typically produce a coverage report that appears comprehensive. It will address: TLS configuration, authentication mechanism and enforcement, input schema validation, rate limiting, logging, and network exposure. These are all real and important controls.

What it will not address:

• Tool description content — whether the descriptions are accurate, minimal, and free of manipulation payloads.
• Manifest integrity — whether the tool manifest is served from an authenticated, version-controlled source and whether deviations from an approved baseline are detectable.
• Context injection risk from tool results— whether tool results are treated as untrusted data before being injected into the model's context, and whether the system prompt frames the trust boundary correctly.
• Per-user authorization at the MCP layer — whether the server enforces end-user access controls, or only client-level controls.
• Behavioral testing — whether the model, when connected to this server, behaves as intended under adversarial conditions.

An MCP security review extends the traditional API security review with five additional review domains:

1. Tool manifest review — every tool description reviewed for accuracy, minimality, and the absence of manipulation content. The approved manifest baseline documented and version-controlled.
2. Context injection surface review — every data source that MCP tools access assessed for write access control and the potential for attacker-controlled content. System prompt framing of tool results reviewed.
3. Authentication boundary review — per-user authentication and authorization assessed separately from client authentication.
4. Behavioral testing — adversarial test cases that present the model with scenarios where tool poisoning, context injection, or goal hijacking would be attempted, with results documented.
5. Supply chain review (for third-party servers) — source, manifest, permissions, and dependencies reviewed per the vetting process described in Vetting a third-party MCP server before you connect it.

The traditional API security review and the MCP-specific additions together constitute a complete security review of an MCP server deployment. Neither is sufficient without the other. For the structured checklist combining both, see An MCP server security review checklist.