MCP Servers: A Double-Edged Sword

MCP servers are a double-edged sword. While they enabled an LLM to interact with tools, making them extremely helpful, they also enable an LLM to interact with tools, which makes them super dangerous.

A quick recap on MCP: it’s a protocol that allows LLMs to find and execute the best tool for the task they’re working on. In a world where everything is configured perfectly and there are no malicious actors, it’s great! But that type of story goes by a different name. A fairy tale.

Like so many things in the real world, MCP servers are not always built well or with security in mind. The often-forgotten story of Asana’s MCP server, which they took offline after discovering it was returning data from other customers, is one example. Then we have a malicious MCP server dancing around the Internet like a cat on a disco floor.

Yet, despite all of its flaws, MCP is still awesome and will stick around. So, what can we learn about the current state of MCP to predict the pain coming our way? To answer that, I reviewed O’Reilly’s write-up, MCP in Practice, where they analyzed over 2,800 MCP servers hosted on GitHub.

Here’s what stood out to me.

The most popular MCP servers are the most useful and the most dangerous. Put your old trauma aside because the current status of MCP servers is a lot like high school. It’s a big popularity contest. The top ten MCP servers, as denoted by the number of stars they received (similar to likes) on GitHub, held nearly 46% of the stars and held premium seating in the cafeteria.

Source: MCP in Practice

As O’Reilly points out in their write-up, this likely stems from practical use cases. We’re at a point where when something works, people will flock to it. Especially developers.

I know the aching question you have is what types of MCP servers were in the top 10? The top three categories: computer and web automation, software engineering, and database & search (RAG).

Source: MCP in Practice

Let’s put this in context. LLMs are incredibly stupid when it comes to security. They can be socially engineered much more easily than humans. When we say that MCP servers are scary, this is why. The top-rated MCP servers allowed computer and web automation. If you’re a human with a pulse and Internet access, you recognize that most of your life can be controlled through your computer and the web. Email accounts, social media, bank accounts…yikes.

The balancing act of convenience and security is always present. With LLMs and MCP, that balance is getting really interesting.

The key concerns with MCP servers I see are:

1. Remote code execution: When LLMs can interact with tools, especially tools that can execute code, we have a recipe for going from an AI system compromise to a traditional system-level compromise. In my incident response days, it was always interesting to watch attackers jump from a compromised Linux system to a Windows system. It’s much like that.

2. Unauthorized data access: MCPs are useful in calling tools that can retrieve data, like from databases. Securing access to data with proper permissions is difficult and error-prone. MCPs don’t make this easier.

To help mitigate the risks, keep the following in mind when building and deploying MCP servers:

1. Maintain a source of trusted and vetted MCP servers. Limit developers’ ability to download random MCP servers and implement them in production. Supply chain attacks are getting too common now, and the random MCP servers on the Internet aren’t always the most securely built.

2. Least privilege is still cool. Implement strong authentication and authorization, giving the MCP server access to only the tools and functions necessary for the task.

3. Monitor and protect tool calls. Implement the right level of visibility to create a baseline of “normal” activity. Monitor for abnormal tool calls and implement protections to prevent risky tool calls.

Here’s to a secure future, in spite of MCPs.