What are the main security risks of MCP?

The seven risks are configuration-to-command execution over STDIO, tool poisoning through model-visible descriptions, confused-deputy token passthrough, capability inheritance after an agent compromise, credential aggregation, unauthenticated HTTP message endpoints, and the registry supply chain. The confused-deputy case replaces the requesting user's identity with the server's identity. Each failure mode has a distinct owner, so closing only one leaves the others available.

Is MCP over HTTP safer than MCP over STDIO?

Their failure modes differ. STDIO is a local process transport where configuration becomes a command line, which produces host compromise with no authentication step and no network exposure, and it is invisible to any network control. HTTP MCP is exposed to the network, which raises the reachability of the endpoint and simultaneously makes every invocation an authorizable, recordable event. An HTTP endpoint with authentication and per-invocation authorization is a defensible design. A STDIO transport on a host processing untrusted input creates a separate host-hardening problem.

How do you secure an MCP server?

Authenticate every caller, authorize each tool invocation individually rather than the connection, validate model-produced arguments before execution, propagate the end user's identity to the downstream authorization decision rather than substituting the server's, hold short-lived credentials rather than long-lived ones, treat tool descriptions as untrusted content under change control, pin versions against the CVE feed, and record every invocation with the identity and the policy that permitted it.

What is the confused deputy problem in MCP?

The server is a deputy: it holds privileged credentials and acts on instructions that originate with a model, and the model's instructions can be influenced by anyone who can put text into its context. The downstream system sees the server's identity rather than the requesting user's, so its authorization check passes on the wrong subject. The fix is identity propagation, so the downstream decision is made against the human or agent that actually requested the action.

Can MCP risks be fully mitigated with a gateway?

No. An HTTP LLM proxy can classify a model-bound prompt and record its decision. MCP tool authorization, configuration-to-command execution over STDIO, registry supply chain, credential design, and downstream actions retain controls at their own endpoints or hosts. A gateway that claims coverage of a local process pipe is describing something it never sees.

MCP Security Risks: Seven Failure Modes, Ranked by What They Cost You

An MCP server is an RPC endpoint that executes code on behalf of a language model. Every requirement that has ever applied to an RPC endpoint that executes code applies to it: authenticate the caller, authorize the specific invocation, validate the arguments, bound the effect, record the decision.

MCP implementations shipped for a year without most of those defaults, and the 2026 CVE count records the result. More than 40 CVEs landed against MCP implementations between January and April across SDKs from Python through Rust (CSA Labs). The seven failure modes below have distinct mechanisms and owners, so a single control cannot cover the full set. The MCP authorization specification and RFC 8707 resource indicators define the current direction for authorization-code flow and token audience binding.

TL;DR

MCP risks split across host integrity, model context, tool authorization, and credential design.
An HTTP LLM proxy can inspect a poisoned tool description when it enters the model prompt.
Tool invocation, local execution, and registry provenance need controls at their own boundaries.

Risk 1: configuration-to-command execution

Mechanism: The STDIO transport treats the MCP configuration file as trusted input, and that input becomes a command line. Anything that can write configuration on the host has achieved command execution, in every language implementation, because the design decision was made once and inherited everywhere. The affected supply chain spans an estimated 150 million downloads, more than 7,000 publicly accessible servers, and up to 200,000 vulnerable instances (The Hacker News).

Blast radius: Full host compromise, no authentication required, no network round trip.

Owner: Host hardening and configuration integrity. This risk lives entirely outside any HTTP boundary, and no proxy inspects a local process pipe. Remove STDIO transports from hosts that process untrusted input.

Risk 2: tool poisoning

Mechanism: A tool description is text the model reads. A malicious description carries instructions that change model behavior without changing a line of client code, and it takes effect whether or not the tool is ever invoked. The attack is an indirect prompt injection with a delivery channel most reviews never examine, catalogued by MITRE ATLAS as AML.T0051.001.

Blast radius: The model can be redirected to exfiltrate context or call other tools after a single line in a description file alters its instructions.

Owner: Provenance and change control on tool descriptions, plus classification of the assembled context window before the model call. This one crosses the HTTP boundary, because the poisoned description reaches the model inside a prompt that an enforcement point can parse. Details in MCP tool poisoning prevention.

Risk 3: confused-deputy token passthrough

Mechanism: The MCP server holds credentials for a downstream system and acts on the model's behalf. The model is influenced by whoever controls its context. The server, holding a privileged token, executes what the model asks, and the downstream system sees the server's identity instead of the requesting user's.

Blast radius: Every permission the server's token holds, exercised by whoever can influence the model.

Owner: Identity propagation carries the end user's identity to the downstream authorization decision instead of substituting the server's. I go through the pattern in the MCP confused deputy attack.

Risk 4: capability inheritance on agent compromise

Mechanism: An agent's tool set is its capability set. When an attacker turns the agent, they inherit that capability set in full. Sysdig's July 1, 2026 JadePuffer disclosure documented an LLM agent running reconnaissance and database extortion autonomously, using tools the agent had been granted (Sysdig).

Blast radius: Exactly the union of what the granted tools can do.

Owner: Scoping and tool-endpoint authorization. Grant each tool only the effect the agent needs, and require human approval for irreversible effects. The tool endpoint must evaluate that authorization because local execution and downstream actions fall outside an HTTP LLM proxy's enforcement boundary.

Risk 5: credential aggregation in the server

Mechanism: An MCP server brokering a database, a repository, a ticketing system, and a model provider ends up holding the credentials for all of them, in one process, on one host. Langflow's CVE-2026-55255, a CVSS 9.9 cross-tenant IDOR reported as actively exploited on July 8, 2026, produced exactly this outcome in an adjacent tool class: an ordinary web bug became wholesale theft of LLM provider keys, cloud credentials, and database secrets (Help Net Security).

Blast radius: Every system the server brokers, on any isolation flaw at all.

Owner: Architecture should use short-lived, per-invocation credentials instead of long-lived stored ones, and keep the server from holding a cache of reusable secrets.

Risk 6: unauthenticated HTTP endpoints

Mechanism: An MCP server exposed over HTTP with no authentication on the message endpoint. CVE-2026-33032 in nginx-ui MCP, CVSS 9.8, was precisely this: no authentication check on command-execution requests. On June 2, 2026, NSA and CISA published cybersecurity guidance on MCP security design that makes authentication of callers and authorization of individual tool invocations an explicit expectation (NSA).

Blast radius: Whatever the server executes, available to anyone who can route a packet to it.

Owner: The gateway or policy point in front of the endpoint. This risk sits at the MCP endpoint's HTTP boundary: authenticate the caller, authorize the invocation, and record the decision.

Risk 7: registry and marketplace supply chain

Mechanism: MCP servers are installed from registries. The CSA and OX Security work found 9 of 11 MCP marketplaces affected by the design flaw. An installed server runs with the privileges of the host process and updates on its own schedule.

Blast radius: Whatever an installed server can execute, arriving through a channel with less review than a package manager.

Owner: Artifact provenance, version pinning, and CVE tracking on installed servers. I take this one in depth in MCP server supply chain security.

Ranked by blast radius, mapped to boundary

1. Configuration-to-command execution over STDIO: host compromise without authentication. This is a host and configuration-integrity problem outside the HTTP boundary.
5. Credential aggregation: every system the server brokers. Credential design and server isolation own this risk, with an HTTP model call as only one possible adjacent event.
6. Unauthenticated HTTP endpoint: whatever the MCP server executes. The MCP server or its own gateway must authenticate and authorize every tool request.
4. Capability inheritance: the full union of granted tools. Each tool endpoint must constrain the resulting action.
3. Confused deputy: the scope of the server token. Identity propagation and downstream authorization decide it.
2. Tool poisoning: model behavior across the session. The poisoned text can reach the model inside an HTTP prompt, where an inline LLM policy point can inspect that model request.
7. Registry supply chain: whatever an installed server can execute. Artifact provenance, version pinning, and patching own this host-side risk.

The HTTP model-request boundary directly covers tool descriptions and other model context sent to an LLM. Tool invocation, local process execution, credential storage, and downstream authorization retain their own control points.

DeepInspect

This is where DeepInspect applies, at its actual boundary. DeepInspect is a stateless proxy between authenticated users or agents and any HTTP-based LLM endpoint. It binds every call to a verified identity, evaluates the assembled context window against policy and data classification, and permits, redacts, or denies inline with a fail-closed default at under 50 ms of overhead in internal testing.

For tool poisoning, a model-visible description reaches the LLM inside a prompt that the proxy can classify before the call proceeds. The MCP server or its dedicated gateway must authenticate a tool caller, authorize the invocation, propagate identity to downstream systems, and constrain the actual effect. Risks 1 and 7 also retain host-side ownership. A compromised host may still make an HTTP model call, and DeepInspect can evaluate that routed call against policy and write a per-decision record; it cannot secure the local pipe or installed artifact.

Book a technical deep dive at deepinspect.ai.