MCP Security: Risks, Threats and Controls

The Model Context Protocol turned a hard integration problem into a plug-in one. Any AI agent can now discover tools, read resources, and call live systems through a single standardized interface. That convenience is also the security story.

Every MCP server you connect is executable code that runs with real permissions, and the protocol spec itself describes tool invocation as "arbitrary code execution." So the question enterprise teams keep asking is fair: "are MCP servers secure enough to trust with production data and production actions?"

The short answer is that MCP does not invent many new vulnerability classes, but it does concentrate old ones onto a new attack surface where an LLM, not a human, decides what to call. This guide walks through how MCP works, the top MCP security risks, and the controls that contain them, with a governance layer as the enforcement point.

What Is MCP Security?​

MCP security is the practice of protecting the Model Context Protocol layer that connects AI agents and LLMs to external tools, data, and systems. It covers authenticating and authorizing agent-to-server calls, vetting the MCP servers you install, defending against prompt injection and tool poisoning, and monitoring the whole path from prompt to downstream API. The goal is to keep agent actions inside intended, least-privilege boundaries.

Due to the Model Context Protocol being young and evolving, its security posture depends heavily on implementation choices rather than defaults. Many risks are addressable with established controls, provided they are enforced consistently at a chokepoint rather than left to each server.

How MCP Works (and Where Risk Enters)​

MCP does not directly connect LLMs with tools. The MCP client accesses the LLM, and the MCP server accesses the tools. One MCP client has access to one or more MCP servers, and each server exposes some combination of three primitives: tools (executable functions), resources (data containers), and prompts. When a user writes a query, the client retrieves available tools, the model adds tool context, generates a function call, and the server executes that call against a downstream service before returning output to augment the answer.

That flow is where risk enters, and it enters at every hop:

• Client to Model: The prompt and tool metadata that reach the LLM can be manipulated, which is the root of prompt injection.
• Model to Server: The model chooses which tool to call, so a deceptively named or altered tool can be selected without a human ever approving it.
• Server to Downstream Service: The server runs with its own credentials and scope, so an over-permissioned server becomes an over-permissioned agent.

Local vs. remote servers change the threat model. Local MCP servers run on a host you control and usually execute OS commands or custom code locally, which raises command injection and sandbox-escape concerns. Remote MCP servers run remotely by a third party, which shifts weight onto authentication, transport security, and supply-chain trust. Non-stdio implementations need publicly accessible API endpoints, so standard API security measures like authentication, authorization, rate limiting, and a web application firewall become mandatory rather than optional.

The figure above shows the MCP architecture and threat surface: client, server, tools, resources, and prompts with annotated risk points for prompt injection, tool poisoning, command injection, and supply chain.

Top MCP Security Risks​

Five competitors on the first page of search agree on the same core taxonomy, and so does the OWASP GenAI security guidance. Here are the risks that matter, why they exist, and the shape of each attack.

Prompt Injection​

Prompt injection is the headline agentic risk, listed as LLM01 in the OWASP Top 10 for LLM applications. Even when a user intends nothing malicious, the LLM might decide an action is appropriate and take it. A legitimate user can also submit an obfuscated prompt recommended by a malicious third party that quietly leaks private information. MCP widens the blast radius because the model can now act on injected instructions by calling real tools, not just producing text. Indirect injection is the nastier variant: poisoned content inside a resource or tool description becomes instructions the model follows.

Tool Poisoning and Rug Pulls​

A malicious MCP server might look completely safe during installation and then have its tools modified during a later update, a pattern known as a rug pull. Deceptive tool names and descriptions can also nudge the model into selecting the attacker's tool over a legitimate one. This is why the MCP spec is explicit that tool annotations "should be considered untrusted unless obtained from a trusted server." Treat the metadata your agent reads as attacker-controllable input, not documentation.

Excessive Permissions and the Confused Deputy​

Most MCP servers do not offer native mechanisms to restrict which downstream functions an LLM can access, favoring broad access that results in oversharing and excessive permissions. That default sets up the classic confused deputy problem: the server holds broad credentials and executes actions on a user's behalf, so an attacker who influences the agent inherits the server's full reach. The server should execute actions only on behalf of the user, with the user's permission, respecting least privilege. Scoped, per-user authorization is the fix, and it has to be enforced somewhere the individual server cannot bypass.

Command Injection on Local Servers​

Local MCP servers may execute any code and can be vulnerable to command injection. If a server passes model-supplied data straight into a function that runs shell commands, an attacker can smuggle in extra commands. A minimal illustration:

# Unsafe: model-controlled input concatenated into a shell command
os.system(f"convert {user_supplied_filename} out.png")
# user_supplied_filename = "x.png; rm -rf /data" runs the second command too

Sanitize and validate data before using it as an argument to anything that executes commands, and run local MCP servers in a sandbox so they can only access what they are explicitly allowed to touch.

Supply-Chain Risks From Unvetted Servers​

MCP servers are executable code, so users should only run MCP servers they trust. The ecosystem makes this hard: developers pull servers from public catalogs, and integrating unverified MCP servers without scanning and assessing them first is common. Many security issues here are not new, so traditional supply chain security still applies, including code scanning, dependency review, and provenance checks. Shadow MCP, where teams stand up servers without review, compounds the problem.

Token Theft and Data Leakage​

Because servers hold credentials and often broad scopes, a compromised or malicious server becomes a path to token theft and data exfiltration. Lack of observability makes this worse: without built-in monitoring, it is difficult to trace activity or correlate an action back to the prompt that caused it. Malicious servers can also exploit MCP sampling to coax completions out of the client, a risk worth flagging even though the specification's July 2026 revision deprecated Sampling alongside Roots and Logging; it still works during a transition window, but new server builds shouldn't be built around it. If you cannot see which agent called which tool with which token, you cannot detect the leak, let alone contain it.

Risk to mitigation at a glance​

MCP Security Controls and Mitigations​

MCP's risks are mostly addressable with controls security teams already know. What changes is that they must be applied to a non-human caller and enforced at a consistent point. Here is how to secure an MCP server in practice.

Authentication and Authorization: MCP defines authorization using OAuth 2.1. Earlier spec revisions left real gaps against enterprise identity practice, and the specification's July 2026 update closed much of that gap: it now requires MCP servers to implement OAuth Protected Resource Metadata (RFC 9728) so clients can discover the right authorization server, requires clients to validate the token issuer on authorization responses (RFC 9207) to block mix-up attacks, and is phasing out Dynamic Client Registration in favor of Client ID Metadata Documents. None of this makes authorization mandatory. It's still optional at the protocol level, and stdio-based servers are expected to pull credentials from the environment rather than follow this flow. For any server reachable over a network, enforce authentication rather than treat it as optional, and issue short-lived, scoped tokens so each agent gets only the access its task requires.

Least Privilege and Invocation Controls: Restrict which downstream functions an agent can call instead of granting broad access. Fine-grained, context-aware authorization, where the allowed tool set depends on the user, the prompt, and the resulting API call, is what turns least privilege from a slogan into an enforced boundary.

Supply-chain Hygiene: MCP components should be signed by the developer. Build them on pipelines that run Static Application Security Testing (SAST) and Software Composition Analysis (SCA) to catch known vulnerabilities in dependencies, and have cloud MCP services implement cryptographic server verification. Pin versions and notify users of changes after installation so a rug pull cannot slip through silently.

Input Validation and Sandboxing: Sanitize any model-supplied data before it reaches a function that executes commands, and isolate local servers so a compromise cannot spread.

Human-in-the-loop and Sampling Controls: Actions performed by MCP servers should be confirmed by users or otherwise restricted for critical operations. Sampling, the mechanism that lets a server request a completion from the client's model, was deprecated in the same July 2026 specification revision noted above. It keeps working for now, but new implementations should route completions through direct provider APIs or tool parameters instead. Where Sampling is still in use, keep the existing guardrails: clients should show users the completion request, allow them to modify or reject it, control which model is used, and apply rate limits, cost caps, and timeouts.

Observability and Vulnerability Management: MCP servers can execute sensitive commands, so send logs and events to centralized logging for investigation, and add runtime tracing across every stage of the execution path. Treat servers as code inside your standard vulnerability management process, upgrading clients, servers, and dependencies at planned intervals.

MCP Security Best Practices Checklist​

Use this as a fast pre-deployment gate. It condenses the controls above into a checklist you can hand to a review:

• Authenticate every non-stdio server and reject anonymous agent calls.
• Issue scoped, short-lived tokens and enforce per-user, least-privilege authorization.
• Only run verified servers, preferably from an official or vendor-approved catalog.
• Pin versions and require change notifications and signature verification on updates.
• Scan dependencies with SAST and SCA before a server reaches production.
• Validate and sanitize inputs; sandbox local servers that execute OS commands.
• Gate critical actions behind human approval and constrain sampling.
• Log centrally and trace at runtime so every action ties back to an identity and a prompt.
• Rate-limit and firewall publicly exposed endpoints.
• Patch on a schedule as part of normal vulnerability management.

Securing MCP at Enterprise Scale With WSO2​

Dedicated AI-security vendors specialize in runtime threat detection and model-level defenses, and that work matters. The gap most enterprises hit first, though, is structural: the controls above are only as good as the point where they are enforced. If authentication, authorization, rate limiting, and logging live inside each individual MCP server, every new server is a new place to get it wrong. A gateway collapses that sprawl into one control plane.

That's the difference between an MCP proxy and an MCP gateway: a proxy moves traffic, a gateway decides whether that traffic should happen at all. WSO2 AI Gateway, part of the WSO2 API Platform, is built as the latter. It governs inbound agent traffic and lets you enforce authentication and authorization, throttling, and rate limiting on agent calls at the edge rather than trusting each server to police itself. That maps directly to the confused-deputy and excessive-permission risks: identity and scope are checked before a call ever reaches a tool. Rather than requiring a rebuild, it can create MCP proxies on top of your existing MCP servers, so already-deployed servers come under governance without a code rewrite.

For the supply-chain and shadow-MCP problem, WSO2 AI Gateway provides an MCP Hub, a searchable catalog of MCP servers for developers and agents, which gives teams a known, curated set of servers to draw from rather than arbitrary public ones. MCP traffic insights address the observability gap, giving you the centralized visibility needed to trace agent activity and correlate actions back to callers. Because the WSO2 AI Gateway spans both inbound MCP traffic and outbound LLM traffic in one control plane, you can apply consistent policy across the whole agentic path instead of stitching together point tools.

WSO2 API Platform is 100% open source and deploys self-hosted, hybrid, or SaaS, which matters for teams with data-sovereignty or air-gap requirements. WSO2 was named a Leader in the Forrester Wave: API Management Software, Q3 2024.

A gateway will not read a model's mind or catch a novel jailbreak on its own. What it does is guarantee that the identity, scope, rate, and logging controls you've defined apply consistently to every agent call, which is the enforcement layer MCP itself leaves to implementers.

Conclusion​

MCP's risks are real, but they're mostly familiar ones, such as prompt injection and weak observability, reshaped for a caller that happens to be an AI agent. Avoiding MCP isn't the fix. Enforcing authentication, least privilege, server vetting, and monitoring at a single point every agent call passes through is. The specification will keep evolving, as the July 2026 revision shows; a control plane at that chokepoint means the next spec change is a policy update, not a re-architecture. Cite the spec, follow OWASP, and put a control plane where the enforcement belongs.

See how WSO2 AI Gateway turns these controls into policy you apply once and enforce consistently, or explore the WSO2 API Platform to govern APIs, AI, and MCP from a single plane.

Frequently Asked Questions​

What is MCP security? MCP security is the set of identity, authorization, and monitoring controls placed around the Model Context Protocol layer that connects agents to tools and data: vetting which servers an agent can reach, requiring authentication and least-privilege scopes for each call, and watching for prompt injection or tool poisoning in what a server sends back.

Are MCP servers secure? MCP servers run as executable code with real permissions, and the protocol leaves many of the relevant security decisions to whoever implements it. How secure any given server is comes down to its authentication, least-privilege scoping, supply-chain hygiene, and monitoring, which is why enforcing those controls at a gateway works better than trusting each server to get them right on its own.

How do I secure an MCP server? Enforce authentication and scoped, least-privilege authorization. Run only verified, version-pinned servers. Scan dependencies with SAST and SCA. Validate inputs and sandbox local servers. Gate critical actions behind human approval and log and trace all activity centrally.

Is MCP secure by default? MCP does not enforce secure defaults on its own. Authentication is optional at the protocol level, non-stdio implementations should treat it as mandatory in practice, and most servers default to broad access. Secure defaults have to be imposed by the operator or a governing control plane.

How does MCP handle data privacy and security? MCP defines authorization using OAuth 2.1 and requires user consent before a tool can be invoked, but it does not guarantee privacy on its own. Protecting data requires scoped tokens, resource-level access controls, encryption in transit, centralized logging, and least-privilege enforcement layered on top of the protocol.