MCP Server Security Risks in Agentic AI Workflows

MCP server security is not just API security applied to AI agents. The protocol lets untrusted text influence tools that act with real permissions, creating risks across the whole workflow. Those risks require layered controls over execution, identity, and access.

What MCP is and why its architecture creates trust boundaries that did not exist before

The Model Context Protocol gives language models a standard way to discover, reason about, and invoke external tools at runtime. That changes who decides what happens next. Untrusted content can influence both the choice of tool and the instructions sent to it, rather than simply becoming data inside a request written by an application developer.

Anthropic introduced MCP in late 2024. The March 2025 specification formalized OAuth 2.1 for remote servers, and the November 2025 specification added OpenID Connect Discovery and Client ID Metadata Documents. In December 2025, MCP moved to the Linux Foundation’s Agentic AI Foundation. It is now cross-vendor infrastructure.

Its architecture creates three distinct trust boundaries. The model reads tool descriptions it cannot independently verify, the client connects to servers whose responses need validation, and those servers act on downstream systems with their own permissions. Cloud Security Alliance’s 2026 best practices guide documents hundreds of servers and more than 150 million package downloads by mid-2025 [1][2][3]. Governance has to cover all three boundaries, but adoption has moved faster than those controls.

How adoption has outrun security governance, and what that gap looks like in practice

CSA’s guide catalogued nearly 7,000 internet-exposed MCP servers by early 2026, with roughly half operating without authentication controls. Exposure was not confined to experimental tools. CSA’s May 2026 research note documented at least seven confirmed high- or critical-severity CVEs across major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor IDE, LibreChat, and Windsurf.

Those findings came after a surge in CVE filings between January and February 2026 that targeted servers, clients, and the infrastructure supporting them. The guide identified CVE-2025-6514 in the widely used mcp-remote proxy package as a critical finding affecting a vast number of installed environments. The weakness affected more than one server implementation.

Common deployment choices help explain the exposure. Overprivileged credentials sit in plaintext configuration files, while default STDIO setups run without isolation from the host operating system. Some servers aggregate credentials for several enterprise systems without requiring authentication at all. In that configuration, a single exposed interface provides a route to the permissions of every connected system.

The STDIO command injection flaw baked into every official MCP SDK

Missing authentication is a deployment failure, but not every MCP risk begins with careless setup. OX Security’s April 2026 research, “The Mother of All AI Supply Chains,” identified command execution behavior embedded in the official SDKs. Anthropic described that behavior as intentional and declined to change the protocol architecture. Downstream developers therefore inherit responsibility for containing it.

The STDIO transport illustrated in the official documentation passes incoming configuration parameters directly to the host operating system shell without sanitization or validation. A supplied process command executes whether or not it starts a valid MCP server. The affected SDKs include Python, TypeScript, Java, and Rust. OX showed how four exploitation families worked against live production systems.

CSA’s research note estimated approximately 200,000 vulnerable instances. An attacker who can influence an MCP configuration file through a compromised repository, malicious package entry, or social engineering can gain arbitrary code execution on the target machine. Patching one downstream product does not remove the design behavior inherited elsewhere.

Tool poisoning, rug pull attacks, and cross-server shadowing

Even when a STDIO setup is isolated, another route stays open. MCP tool descriptions are JSON schemas whose text guides the model’s choices, so hostile instructions inside that text can redirect how it uses tools.

In tool poisoning, a malicious server embeds instructions in a description visible to the model but absent from the user interface. The model follows those instructions and invokes tools with the permissions of their connected systems. A rug pull attacks the same trust assumption over time by changing tool descriptions after they have been accepted. Approval of the original description does not establish the integrity of its replacement.

Cross-server shadowing extends that influence across a session. An agent may connect to file-system, GitHub, Slack, Stripe, and database servers at once, giving one malicious description several neighboring tools to influence. Invariant Labs demonstrated that a compromised server could weaponize adjacent trusted servers through this mechanism. The attack works even with encryption and authentication in place because it travels through metadata that the protocol expects the model to read.

Privilege escalation through tool chaining

Authorization for one tool does not bound a session. An agent can combine individually permitted actions into an outcome that no human approved, crossing the client-to-server boundary repeatedly as it works.

For example, an agent might begin with legitimate read access to a GitHub repository, then discover accessible CI/CD, secrets-management, and deployment tools. Each invocation could pass its own authorization check while the combined sequence deploys arbitrary code to production. Maloyan & Namiot’s peer-reviewed analysis tested 847 attack scenarios across five MCP server implementations. It found that MCP’s architectural choices amplified attack success rates by 23–41% compared with equivalent non-MCP integrations, attributing the effect to implicit trust propagation in multi-server configurations.

CSA identifies additional enablers, including servers’ ability to claim permissions without capability attestation and bidirectional sampling without origin authentication. The highest-risk combination joins external content ingestion, private data access, and outbound network reach. Each capability can have a legitimate purpose. Together, they undermine the traditional API assumptions of a deterministic caller and a bounded request, because the agent can change its plan and combine permissions as it goes.

Authentication gaps and the broken OAuth model

At the downstream boundary, the MCP server acts with credentials for the systems it connects to. The authorization specification defines OAuth 2.1 but makes authorization optional. Under that design, a server can offer powerful tools without authentication and still follow the specification. Defining an identity standard is not the same as enforcing it.

Implementation failures make the consequences concrete. Dolt MCP versions 0.3.1–0.3.6 returned a 401 response for requests that contained any Bearer token, even an invalid one, but kept processing those requests. Callers who had no valid credentials could use the server’s credentials to run database tools. Version 0.3.7 fixed the bypass.

The April 2026 Azure DevOps MCP authentication bypass exposed API keys and tokens without credentials. Microsoft mitigated CVE-2026-32211 server-side, with no customer action required. These incidents show why a failed authentication check must stop execution as well as return an error response.

Credential aggregation also creates risk beyond MCP itself. Google Threat Intelligence Group documented UNC6395’s use of compromised Salesloft Drift OAuth tokens to access Salesforce customer instances beginning in August 2025. That incident involved no MCP server. Both depend on an intermediary that holds credentials, so a compromise there can reach downstream customer systems.

Supply chain exposure through the MCP package ecosystem

An organization need not build a vulnerable server to inherit one. By February 2026, the Sandworm_Mode campaign was using npm typosquatting to target Claude Code, Cursor, and Windsurf. Malicious packages mimicked popular utilities and installed rogue MCP servers into AI coding environments. Those servers then used prompt injection to exfiltrate SSH keys, AWS credentials, npm tokens, and other secrets.

Once installed, an attacker-controlled server entered an environment where tool descriptions could influence the agent and local process execution could reach the host. That connects supply chain exposure directly to both tool poisoning and the STDIO design. Reviewing only application code leaves this integration path outside the review.

CSA’s guide also documents malicious npm packages among the MCP ecosystem’s 2025 incidents, together with prompt injection against the GitHub MCP server and unauthenticated remote code execution in MCP Inspector. A third-party server puts another party’s code and metadata inside the agent’s trust boundary, with access determined by the surrounding configuration.

Why traditional API security controls fail at every layer of the MCP attack surface

Traditional API controls assume a human-authored application making bounded, predictable requests. MCP puts a language model in that decision loop, where content read at runtime can alter the next action. The controls still have uses. Their assumptions no longer cover the whole workflow.

HTTP input validation does not find instructions hidden in tool-description text that is otherwise valid. Per-request authorization cannot block an unauthorized outcome when each step in the sequence is allowed on its own. Static credential management does not address context leakage when an agent holds tokens for several systems and prompt injection can expose them. Network perimeter controls also miss STDIO attacks that run locally before they cross a network boundary.

CSA’s guide calls for defense in depth spanning authentication, tool integrity, session management, supply chain validation, execution isolation, and behavioral monitoring. The security model has to account for what the agent reads, what it can execute, and what its actions accomplish together. A protected HTTP endpoint covers only part of that path.

Layered mitigations at the protocol, identity, and access-control layers

The practical response is to harden all three layers together. At the protocol layer, teams should sandbox STDIO processes through containerization or process isolation to restrict host-level privileges. Incoming tool schemas should be treated as untrusted input, with descriptions validated, pinned, and checked for integrity. Keeping descriptions from changing during a session blocks the rug pull path. Explicit tool allowlists should also restrict discovery from untrusted servers.

At the identity layer, teams should enforce OAuth 2.1 despite its optional status in the specification. Authentication must gate tool execution, so an authentication error response also prevents execution. Per-agent tool allowlists should be bound to that agent’s OAuth 2.1 identity, so access is scoped to the agent rather than inherited wholesale from the server credential. This makes non-human identity part of authorization instead of treating every caller as an extension of the server.

At the access-control layer, a central MCP gateway should send tool invocations through one point where rules are enforced. That allows policy checks, audit logging, and anomaly detection to cover sequences of requests as well as single requests. High-risk boundaries need human approval, including production writes, code deployment, and actions that would send private data out. An agent should not have autonomous authority to cross those boundaries simply because it discovered the necessary tools.

Supply chain review must cover that same set of tools. Every third-party server should pass review before it is added, with its package versions pinned and its provenance checked. CSA’s four-level MCP Security Maturity Model can help teams report progress to auditors, but the model does not replace the execution, identity, and access controls it organizes.

What a real security assessment of an MCP deployment covers, and what a checkbox engagement misses

An MCP assessment needs visibility into the agent itself. Trust-boundary mapping should enumerate the system prompt, user inputs, tool responses, retrieved documents, external API responses, database records, and persistent memory. Each source needs classification by who controls it, including whether that control is partial or external. User-controlled and external content remain potential injection vectors despite pre-processing filters. This requires whitebox access to the agent configuration, tool inventory, and prompt chain.

The adversarial phase must then test decisions and sequences. It should attempt goal hijacking through content the agent reads, chain authorized calls into unauthorized outcomes, and test whether one server’s descriptions can redirect behavior toward trusted neighbors. Tests should also check persisted context for instructions that carry over into future sessions. An HTTP-only blackbox test cannot expose all those paths because it does not see how the agent builds and uses its context.

Warning signs include skipped STDIO testing, no adversarial tool descriptions, no sequence-level testing, and exclusions for third-party servers. Each exclusion leaves a route already present in the deployment outside the assessment, with its safety unverified.

For teams that ship integrations regularly, continuous pull-request scanning brings configuration changes into the assessment. A new community server added between tests can change the agent’s tool inventory and trust boundaries. The configuration layer needs regular security review, just as application code does.