MCP Security Risks: Seven Failure Modes, Ranked by What They Cost You
Model Context Protocol risk decomposes into seven failure modes: configuration-to-command execution, tool poisoning, confused-deputy token passthrough, capability inheritance on agent compromise, credential aggregation in the server, unauthenticated HTTP endpoints, and registry supply chain. Each has a different mechanism, a different owner, and a different relationship to the HTTP boundary. This ranks them by blast radius and states which ones an enforcement layer can answer.

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.
The ecosystem shipped for a year without most of those as defaults, and the 2026 CVE count records the result. More than 40 CVEs landed against MCP implementations between January and April across the Python, TypeScript, Java, and Rust SDKs (CSA Labs). Seven failure modes account for effectively all of them, and they differ enough in mechanism that a single control covers none.
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, configuration integrity, and workload isolation. 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, call other tools, or ignore its instructions, from a single line in a description file.
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 rather than the requesting user's.
Blast radius. Every permission the server's token holds, exercised by whoever can influence the model.
Owner. Identity propagation. The invocation has to carry the end user's identity to the downstream authorization decision, rather than 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 recon, credential theft, lateral movement, and database extortion autonomously, and each of those steps was a tool the agent had been granted (Sysdig).
Blast radius. Exactly the union of what the granted tools can do.
Owner. Scoping. The correct question when granting a tool is what an adversary gets if this agent is turned, rather than what the agent needs on a good day. Irreversible effects require a human approval step defined by effect rather than by tool name.
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. Short-lived, per-invocation credentials rather than long-lived stored ones, and a server that holds nothing worth stealing when it is breached.
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 squarely on the HTTP boundary and is fully addressable there: authenticate the caller, authorize the invocation, 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
| Risk | Blast radius | Crosses the HTTP boundary | |---|---|---| | 1. Config-to-command (STDIO) | Host compromise, unauthenticated | No | | 5. Credential aggregation | Every brokered system | Partially | | 6. Unauthenticated HTTP endpoint | Whatever the server executes | Yes | | 4. Capability inheritance | Union of granted tools | Yes, at invocation | | 3. Confused deputy | The server's token scope | Yes, at invocation | | 2. Tool poisoning | Model behavior across the session | Yes, in the prompt | | 7. Registry supply chain | Whatever an installed server runs | No |
Two of the seven live entirely outside HTTP, and I would rather say that plainly than sell a proxy as the answer to a local process pipe. The other five are decided at the moment an identity invokes a tool or a prompt reaches a model, which is a moment a policy point can own.
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 risks 2, 3, 4, and 6, that produces a per-invocation authorization decision tied to the identity that requested it rather than to a session established once, and a poisoned tool description reaching the model arrives inside a prompt the proxy classifies before the call proceeds. For risks 1 and 7, the honest contribution is different: a compromised host still has to reach a model for the attacker's agent to operate, and those calls are evaluated against policy and written to a signed, per-decision store the compromised host never had custody of.
If your agents are invoking MCP tools with no per-invocation authorization and no independent record, book an AI readiness assessment.
Frequently asked questions
- What are the main security risks of MCP?
Seven: configuration-to-command execution over STDIO, tool poisoning through model-visible descriptions, confused-deputy token passthrough where the server's identity replaces the user's, capability inheritance when an agent is compromised, credential aggregation inside the server, unauthenticated HTTP message endpoints, and the registry supply chain for installed servers. They differ in mechanism and owner, so a program that addresses one of them while leaving the others open has closed the cheapest gap.
- Is MCP over HTTP safer than MCP over STDIO?
They fail differently. 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 is not.
- 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, and the boundary matters. Five of the seven risks are decided at an HTTP request, where a policy point can authenticate, authorize, classify, and record. Configuration-to-command execution over STDIO and the registry supply chain for installed servers are host and artifact problems, owned by hardening, isolation, provenance, and patching. A gateway that claims coverage of a local process pipe is describing something it never sees.