Model Context Protocol (MCP) aka Multiple Cybersecurity Perils

The last few weeks, MCP is an acronym you probably seen across multiple articles, linkedin, twitter post, and more. It was introduced by Anthropic as a way to connect LLM models to systems (particularly systems where data lives), increasing the capabilities of an LLM. Imagine Chatgpt or Claude Desktop, having access to your filesystem and database to perform analysis, explore your database structure and data to perform analysis, improvements, investigations, etc. Now imagine to connect the LLM to almost any existing tool? The possibilities are endless.  Once you see it in action is game changing experience, it felt like when I walk my dog on a leash, and we reach the park where other dogs are playing and suddenly I set him free to play...

There are a lot of paralellism and people referring to MCP as the new API protocol, unlike traditional API servers that simply route requests, MCP servers translate natural language requests from LLMs into structured operations on tools, and then convert the results back into a format the LLM can understand. This enables LLMs to perform real-time actions like retrieving current data, executing transactions, or accessing proprietary information—all while maintaining a consistent interaction pattern.  So MCP at first looks like an API but is not. 

MCP are client side, meaning that is basically to enable local Applications powered by LLMs like Claude Desktop, ChatGPT app, AI powered IDEs like Cursor, Copilot, Windsurf, etc. 

"MCP is rapidly maturing into a powerful standard protocol that turns AI from an isolated “brain” into a versatile “doer.” By streamlining how agents connect with external systems, it clears the path for more capable, interactive, and user-friendly AI workflows." HuggingFace

Here is a brief diagram of MCP architecture:

• MCP Hosts: Programs like Claude Desktop, IDEs, or AI tools that want to access data through MCP
• MCP Clients: Protocol clients that maintain 1:1 connections with servers
• MCP Servers: Lightweight programs that each expose specific capabilities through the standardized Model Context Protocol
• Local Data Sources: Your computer’s files, databases, and services that MCP servers can securely access
• Remote Services: External systems available over the internet (e.g., through APIs) that MCP servers can connect to.

As Model Context Protocol (MCP) servers gain traction (and they are gaining it) in AI agent architectures, they introduce significant security challenges alongside their benefits. The standardized approach has led to rapid development of thousands of MCP server implementations in just months, demonstrating their utility in addressing real integration challenges, you can take a look at some of the MCP registers to get an idea of what is available https://mcp.so 

Security implications  in MCP Server Implementations

As MCP servers connect LLMs to external tools, they become a security hotspot in AI application architecture. They represent a focal point that attackers can target to gain access to multiple systems simultaneously. This concentrated access point creates an attractive target for attackers seeking to compromise organizations deploying AI agents.

Additionally, if MCP servers are published to registries like mcp.so, they could introduce significant supply chain security issues similar to those seen in traditional software supply chains. This is NPM all over again, but on stereoids. Buckle up, lets's review some of the recents known issues.

Sensitive Credential Management Challenges

MCP servers frequently juggle API keys, database credentials, and other secrets to function properly. Since they act as intermediaries between LLMs and external services, they handle sensitive credentials for many different systems simultaneously. This creates several potential security risks that are often overlooked in typical MCP implementations. 

Common credential management issues include hardcoded secrets in server code, long-lived credentials with extended exposure periods, lack of access control governing secrets, and insufficient audit trails for secret usage. These vulnerabilities can lead to credential leakage and compromise of multiple systems if an MCP server is breached. 

In this diagram we can see more details of the inner pieces of the MCP server, like the Request router and Tool registry.

Mitigations:

• Avoid hard coded secrets, use a secret management solution
• Limit exposure and use ephemeral credentials
• Isolate the access between servers and limit which server can access a secret.

Remote Code Execution

MCP servers, like any server software, may contain vulnerabilities that allow for remote code execution. While not specific to MCP, these types of vulnerabilities are common attack vectors that could be exploited to compromise MCP servers. Similar vulnerabilities in MCP servers could have horrible consequences given their privileged access to multiple systems. The nature of prompts provides a great case for command injection.

Command injection attacks exploit vulnerabilities in the way agents process and execute commands or queries. By injecting malicious code into seemingly innocent inputs, attackers can manipulate agents into executing unauthorized commands, potentially gaining access to sensitive systems or data.

Mitigations:  It's 2025, but here we go again... "always sanitize inputs, use parameterized commands instead of string concatenation", and run tools in isolated environments with minimal privileges.

Tool Poisoning (aka backdooring, aka hidden risk)

Tool poisoning attacks target the tools that AI agents use to interact with external systems. By compromising these tools, attackers can manipulate agent behavior, extract sensitive information, or gain unauthorized access to connected systems. These attacks are particularly dangerous because agents implicitly trust their configured tools.

Fake Updates (aka Rug pull) 

This attack involves replacing an already-approved tool's functionality after deployment. Initially, the tool appears legitimate during security review, but after receiving approval, attackers modify its behavior to perform malicious actions. Since the component was previously vetted and approved, the malicious update might escape rigorous review, allowing attackers to compromise agent communications or extract sensitive data.

Mitigations:

• Immutable deployments with versioning. (Version pinning) 
• Official registries? (Anthropic is close to release an official MCP registry) Internal registry ala Artifactory?

Cross-Server attacks 

This attack exploits naming conflicts between tools across different MCP servers. By registering a malicious tool with the same name as a legitimate tool on another server, attackers can trick systems into invoking their malicious version instead.

Cross-server tool shadowing is essentially an implementation of the confused deputy attack pattern in MCP architectures. The confused deputy problem is a fundamental security issue where an entity (the "deputy") that has certain privileges is tricked into misusing those privileges by another entity. The deputy is "confused" about who it's actually serving.

In this scenario, the MCP client (deputy) has legitimate access to database credentials. If it resolves the tool name to the malicious implementation, it will unwittingly pass those credentials to the attacker's tool, enabling the attacker to access sensitive data by exploiting the deputy's authority.

Some potential mitigations, which you might need to implement:

• Explicit Namespacing: Require fully qualified tool names (e.g., trusted-tools.com/database_query) to prevent ambiguity.
• Authority Validation: Implement verification checks that validate a tool's origin against an allowlist before execution. (ala CORS but reversing the roles)
• Principle of Least Privilege: Limit the credentials and context information passed to each tool to only what's necessary.

Unmonitored Access, Data Exposure and lack of audit logs

Finally, without proper visibility mechanisms, AI assistants could access or modify sensitive data through MCP servers without security teams' knowledge. A compromised prompt or malicious instruction could potentially extract confidential information through legitimate MCP connections, creating data exposure risks that may go undetected. 

While MCP enables powerful connections between AI systems and external tools, it doesn't inherently provide comprehensive logging capabilities required for security investigations or compliance reporting. This creates challenges for organizations that need to maintain detailed audit trails of all AI agent activities for regulatory compliance or security forensics.

Conclusion

In short, MCP is a great technology, enabling AI to do much more for us, but without any security consideration at the moment. All security responsability lays on the users at the moment, until we have better tools that could help prevent all these issues.  

Just look at the MCP protocol specification recommendations and advice:

As the adoption of MCP servers continues to grow, security practices will need to evolve alongside them. Organizations should stay vigilant, continuously monitor for new vulnerabilities, and adapt their security approaches to address emerging threats in this fast changing environment.

While tools are being created (MCP Guard, MCP Firewall, MCP whatever), to protect MCP architectures, you should put in place guidance on and processes (which are many) to ensure your users take all the precautions when adopting MCP servers as you did with Open Source Libraries, same common sense still applies.

Are you ready for this? 

If you liked this post, please subscribe to my newsletter to get content like this earlier.

Chris