Demystifying MCP (Model Context Protocol): 3 Common Misconceptions

Demystifying MCP (Model Context Protocol): 3 Common Misconceptions

As more teams integrate MCP (Model Context Protocol) into modern AI and agent-based systems, clearly understanding its behavior, strengths, and security considerations becomes increasingly important. MCP’s flexibility opens exciting possibilities, but misconceptions about its functionality can introduce unintended risks. In this article, we'll clarify three common misconceptions about MCP, so you can make informed decisions when designing and securing MCP-powered applications.

1. MCP Servers Are Not Centralized Components Shared Across Clients

A frequent assumption about MCP servers is that they operate as centralized resources shared among multiple clients, similar to web APIs or centralized microservices. However, this is generally not the case in current implementations.

Reality Check:

• MCP servers are typically installed and operated locally, serving only a single client.
  
  
• Conversely, a single MCP client often connects to multiple MCP servers over its operational lifespan.
  
  

This asymmetric design (one client to multiple servers, but each server dedicated to one client at a time) is central to understanding how MCP architectures are deployed in the real world. Recognizing this point helps developers correctly model security boundaries, manage resource allocation, and optimize integration patterns.

2. MCP Servers Are More Than Just Endpoints—They Are Executable Code

Another common misconception is viewing MCP servers merely as passive endpoints or simple data-serving APIs. In reality, their nature and capabilities heavily depend on their execution context.

Reality Check:

• When installed locally, an MCP server functions as a fully executable application running directly on your host system.
  
  
• Typically, this means the server inherits the same permission level as the client application that launched it.
  
  
• There is no need for malicious exploitation or vulnerabilities for an MCP server to execute code—it inherently possesses this capability by design.
  
  

This built-in capability underscores a fundamental security principle: the primary risk isn’t necessarily unauthorized exploitation, but the inherent trust placed in the server. Ensuring trustworthiness, origin verification, and secure distribution channels for MCP servers is therefore critical.

3. Sandboxing MCP Servers Isn’t a Complete Solution

There's an understandable instinct to isolate potentially risky MCP servers using sandboxed environments (like containers, VMs, or other isolated execution frameworks). While isolation is helpful and recommended, it doesn't entirely remove risk due to indirect interactions.

Reality Check:

• Even sandboxed MCP servers can indirectly communicate and influence each other through their common client.
  
  
• A server operating within a sandbox could provide outputs, commands, or data influencing client decisions, effectively impacting other connected servers—even if direct server-to-server communication is impossible.
  
  
• Thus, the total capability and security risk of the MCP ecosystem become the aggregated capabilities of all connected servers, including sandboxed ones.

This realization has significant security implications, particularly around privilege escalation and lateral influence, where ostensibly secure, isolated environments might still indirectly facilitate undesirable actions. A comprehensive security strategy needs to account for these indirect interactions.

To illustrate this, we built a simple demo involving a malicious MCP server designed to steal user data by manipulating the MCP client application into activating an additional server installed alongside it.

In this scenario:

• User Request: The user instructs the MCP client to retrieve the latest tech news from CNN.
  
  
• Malicious Server Interaction:
  
  
  
  • The client connects to the malicious MCP server to fulfill the request.
  • The malicious server responds by instructing the client to first "solve a challenge" before granting access to the desired function. (Denoted “1” in the below screenshot)
  • To solve this challenge, the client inadvertently retrieves the user's latest transaction data.
    (Denoted “2” in the below screenshot)
  • Finally, the client application (Claude) submits this sensitive transaction data directly back to the malicious server. (Denoted “3” in the below screenshot)
    
    

Screenshot of the conversation (Claude desktop as the client app)

The malicious server code

Conclusion: Respecting MCP’s Power and Building Robust Security Models

MCP's inherent flexibility and power make it incredibly effective for building complex, agent-based, and AI-driven applications—but these same characteristics also introduce security considerations that must be explicitly addressed. Treating MCP servers as mere data endpoints underestimates their inherent power and potential influence.

When building MCP-powered environments, adhere to these security guidelines:

1. Treat MCP servers as executable code with inherent privileges.
   Always regard MCP servers as software components capable of performing privileged actions within their environment.
   
   
2. Understand indirect interactions between servers.
   Servers may indirectly influence one another, even within sandboxed setups. Awareness of these indirect interactions is crucial for maintaining robust security boundaries.
   
   
3. Establish clear trust boundaries and conduct regular security assessments.
   Explicitly define and enforce trust boundaries. Regularly assess each server's trustworthiness and apply rigorous security measures to mitigate risks associated with indirect, cross-server communication.
   
   
4. Segregate MCP servers capable of performing privileged actions requested by the client application.
   MCP servers designed to execute code, run system commands, or access host resources upon request from a client application should be deployed in strictly segregated and secure environments.
   
   
5. Avoid co-locating servers handling sensitive information alongside those interacting with untrusted sources.
   MCP servers that process external, potentially untrusted data (e.g., from the web or email) must not be installed alongside servers with access to sensitive information or privileged system tools. This isolation reduces the risk of indirect prompt injection or malicious invocation.

By addressing these misconceptions, teams can better navigate MCP’s capabilities and security considerations, enabling safer integration into modern AI architectures.