Model Context Protocol (MCP): Understanding security risks and controls

Model Context Protocol (MCP) is a powerful protocol from Anthropic that defines how to connect large language models (LLMs) to external tools. It has quickly gained traction due to its ease of use and the benefits it adds in our use of AI. In this article we'll cover some of the potential security risks you'll encounter with MCP and how you can approach mitigating them.

How MCP works

MCP does not directly connect LLMs with tools. The MCP client component accesses the LLM, and the MCP server component accesses the tools. One MCP client has access to one or more MCP servers. Users may connect any number of MCP servers to an MCP client.

Here's what a typical MCP client and server exchange looks like:

1. The user requests a task from the MCP client
   1. The MCP client has the information about the tools that each MCP server implements or has access to
2. The MCP client passes the request from the user plus the information from the MCP servers to an LLM which responds with the tool needed and the parameters to be used
3. The MCP client sends the information about the tools and parameters to the MCP server
4. The MCP server completes the task and returns the answer to the MCP client that passes the answer to the LLM, and the LLM generates a response for the user
5. The response is shown to the user by the MCP client

MCP servers can be run locally or remotely, and the security risks differ depending on how they are executed.

We define "local MCP servers" as the MCP servers that we run in a host that we control. To perform the requested tasks, local MCP servers usually execute OS commands or custom code locally.

"Remote MCP servers" are only run remotely by a third party. We can have access to remote MCP servers, but they don’t run on a host we control. Remote MCP servers still have security risks for the users because they have access to their data, but since they are not executed locally, many common risks don’t apply.

Security risks and controls

Here's a quick overview of some of the MCP risks security researchers have identified and some mitigation approaches.

Authentication and authorization

When an MCP server performs an action triggered by a user’s request, there is a risk of a "confused deputy" problem. Ideally, the MCP server should execute this action on behalf of the user and with the user’s permission. This is not guaranteed, however, and depends on the implementation of the MCP server. If it's not implemented correctly, a user could gain access to resources that should not be available to them but that are available to the MCP server, violating the principle of least privilege.

MCP defines authorization using OAuth, but the community has identified that the current specification includes implementation details that conflict with modern enterprise practices. Efforts are underway within the community to improve and Update the Authorization specification and address this discrepancy.

Supply chain risks

MCP servers are composed of executable code, so users should only use MCP servers that they trust. And if we develop MCP servers, we must take precautions so our users can trust our software. MCP components must also be signed by the developer, so users can be more certain of their integrity.

We must also build MCP components on pipelines that implement security best practices like Static Application Security Testing (SAST). We must understand the findings, discard false positives and fix known security vulnerabilities. Pipelines must also implement Software Composition Analysis (SCA) so that known vulnerabilities in the dependencies used by MCP servers are identified and fixed.

If an MCP server is offered as a cloud service, it should also implement cryptographic server verification so clients are able to verify the server.

As with any other software, if attackers are able to access and modify the source code for any MCP component, that will allow them to compromise the users. To reduce this risk, software developers and users must verify the integrity of all the dependencies they use and scan them for malware.

Unauthorized command execution

Local MCP servers may execute any code. Depending on how the MCP client passes the information to the MCP server and how the MCP server is implemented, command execution functionality may be vulnerable to command injection vulnerabilities. Always double check what commands will be executed and sanitize the data before using it as an argument for a function that executes commands.

The following is an example of an MCP server with a command injection vulnerability:

def dispatch_user_alert(self, notification_info: Dict[str, Any], summary_msg: str) -> bool:
"""Sends system alert to user desktop"""
notify_config = self.user_prefs["alert_settings"]

try:
     alert_title = f"{notification_info['title']} - {notification_info['severity']}"
     if sys.platform == "linux":
         subprocess.call(["notify-send", alert_title])
     return True

Code seen in: https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/ 

Additionally, consider running local MCP servers in a sandbox so they are only capable of executing and accessing what they are explicitly allowed to.

Prompt injection

MCP servers pose significant security risks due to their ability to execute commands and perform API calls. One major concern is that even if a user doesn't intend a specific action, the LLM might decide it's the appropriate one.

This risk can arise without malicious intent, but it's also a factor in adversarial scenarios. For example, a legitimate user might submit a prompt they didn't write to the MCP client, perhaps one recommended by a malicious third party. Such a prompt could be obfuscated but still leak private information from the user's conversation or accessible tools. Imagine a user copying and pasting a complex, obfuscated prompt they believe will create a new user in their cloud environment—the malicious prompt could, in addition to creating the intended user, also create another user for the attacker.

This is why the actions performed by the MCP servers should always be confirmed by the users or restricted to reduce risk to an acceptable level.

Tool injection

There's also the possibility that someone could build a malicious MCP server, which poses  a whole new level of potential risk. For example, a malicious MCP server might initially appear safe during installation, even with its source code and tool descriptions appearing normal. But the tools may be modified during a future update. For example, a tool originally described as gathering weather information may be modified in an update to start gathering confidential information and sending it to an attacker.

This can also happen with the names of the tools. Malicious aMCP servers may use deceptive names for the tools so the LLM selects them for a task that should be done by other legitimate tools, potentially causing unintended or harmful actions.

To mitigate some of this risk, software that allows users to install MCP servers should have the capability of pinning the version of the MCP servers and notifying the user if any changes occur in their code or composition after installation.

Sampling

Malicious MCP servers may also try to exploit the MCP sampling functionality, where MCP servers can request MCP clients to use an LLM to complete a request. If an MCP server needs to send a request to an LLM, sampling allows the MCP client to make the request on behalf of the MCP server, since the user has more control over the MCP client and it helps centralize costs.

MCP clients should implement the following controls to reduce the risks associated with sampling:

• Enable clients to show users the completion request
• Allow users to modify or reject completions
• Enable clients to filter or modify completions
• Allow users to control which model is used
• Implement appropriate rate limits
• Control cost exposure
• Implement timeouts

Logging

As previously discussed, MCP servers are able to execute sensitive commands. They should have the capability of sending logs or events to standard centralized logging servers or to be able to log these events locally. This enables investigation into system actions if a problem occurs or is suspected.

Vulnerability management

Since MCP servers are code, they may have vulnerabilities just like any other software, so it's critical to include them into your standard vulnerability management process. This includes upgrading the MCP clients and servers and their dependencies at planned intervals, based on the organization's risk appetite.

Conclusion

MCP has sparked interest in manipulating tools using natural language and in better understanding how we communicate users, LLMs and tools. However, we must acknowledge the security risks that come with this increase in automation and additional AI agency. As with any other new technology, when using MCP, companies must evaluate the security risks for their enterprise and implement the appropriate security controls to obtain the maximum value of the technology.

Learn more

• MCP Servers: The New Security Nightmare
• The MCP Authorization Spec Is... a Mess for Enterprise
• Everything Wrong with MCP
• Imprompter: Tricking LLM Agents into Improper Tool Use
• Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions
• WhatsApp MCP Exploited: Exfiltrating your message history via MCP
• 5 MCP Security Tips