Old Security Rakes In New MCP Yards

This post will be (somewhat) short, because I want to call something out that is missed in the public discourse around Model Context Protocol (MCP) security and what it entails for its broader userbase.

Before I go any further, I should mention that I love the work that Anthropic and the community is doing with MCP. I use LLMs daily and being able to plug data into it through a standard set of conventions is wonderful.

The problem that I am describing in this blog post is not inherently an MCP problem - it’s a problem with our shared ability to filter out excitement against the backdrop of security common sense.

The tale of two components #

With MCP, you have two key components in play - a MCP client and a MCP server. There’s some nuance here in how these can act (e.g., MCP server itself can be a MCP client), but that’s beside the point of this post.

A MCP client can be software such as Claude Desktop or Visual Studio Code that exposes a Large Language Model in some capacity, that also enables its users to connect one or more MCP servers to it.

A MCP server is effectively a “plug-in” that you can connect to your MCP client to help it get information from, quite literally, any data source through a set of standard capabilities and conventions - resources, tools, roots, sampling, transports, and prompts.

Think of the MCP being the standard interface by which we can connect LLMs to external data. Simple, no?

The two types of MCP servers #

MCP servers can also come in two flavors - local (running on your developer box) and remote (running on some server in the cloud or your basement). This is where the crux of the perception problem lies. Think about it for a second:

• Local MCP server. It runs locally on your machine. You downloaded it from somewhere. Most users will execute it in the context of their own user account.
• Remote MCP server. May require authorization (we’re working on a RFC to enable a more robust implementation, by the way), where it requests the users to sign in with any of the thousands accounts that they have (e.g., Google, Microsoft, Spotify, WhatsApp, etc.)

Now imagine I remove the entire concept of MCP from your mind and present you a list like this:

• Local binary. It runs locally on your machine. You downloaded it from somewhere. Most users will execute it in the context of their own user account.
• Remote API. May require authorization, where it requests the users to sign in with any of the thousands accounts that they have (e.g., Google, Microsoft, Spotify, WhatsApp, etc.)

Your common user threat model from years ago is back into the picture!

I see so much excitement about MCP servers (justified, by the way), that people throw caution to the wind when it comes to whatever is trending on X/Twitter or any other social channel. You’re going to step on the exact same rakes people stepped in 2001!

So, what does that mean for average users? Simon Willison did a quick rundown of a recent security post, if you are curios. Notably, the threats I am discussing in this post are even simpler than what’s outlined in Simon’s write-up.

If you run a MCP server locally in the shape of an unknown binary - right on your computer, it doesn’t need prompt injection to exfiltrate data. It can just do it directly.

If you connect your account to some remote MCP server that claims to do something useful with a set of scary scopes (e.g., read your cloud drive or email), you never know what that server actually does behind the scenes. It might be summarizing your emails, but also funelling all of them to a server somewhere far, far away.

We are repeating history. “But hey,” you might ask, “what about all those consent prompts?” You mean this on Windows, that users routinely click “Yes” on?

You also don’t need admin access to get quite a bit of data out of the PC. What about this SmartScreen prompt - do you think some college student is not going to click “Run Anyway” for a MCP server that promised that it can summarize that 900-page PDF of a book that a report is due on in two days?

Of course not! They will click that in less time it took you to read this sentence. Or this, when you are signing in to Google with OAuth?

I am not at all saying that these consent prompts are bad - they are a required safeguard that can and does protect millions of customers worldwide from abuse of their data.

It’s just that in the excitement about MCP we should not forget about what we’re actually dealing with - local binaries and remote APIs that can do a lot with the credentials and permissions that we give them, way beyond what they might claim in their README files.

So what should we do #

Given that MCP brings (very) familiar security challenges back into the spotlight, here’s what I think you could to do today to protect yourself and your data:

1. Treat local MCP servers like any other local software:

   • Only install local MCP servers from trusted sources with established reputations.
   • Check code signatures and verify downloads when available. Not that code signatures are a bulletproof piece of evidence that what you get is not going to do bad things, but it’s better than not having it.
   • Consider running untrusted (or unknown) MCP servers in sandboxed environments or VMs, when possible.

2. Be skeptical about authentication requests:

   • Before connecting your accounts to a remote MCP server, verify who built it and what their privacy and service policy entails. Are they trustworthy? Do they have a history of building anything similar in the past, or is this a random Twitter user registered yesterday?
   • Review the requested scopes extremely carefully - does a PDF summarizer tool really need access to your entire email inbox?
   • Use the principle of least privilege - grant only the minimum permissions necessary.

3. Look for security-related signals:

   • Prefer MCP servers that have undergone security audits or are open source (so the community can at least review the code). I don’t want to say “Compile it yourself” but unless you do (and have the expertise to inspect the code), you don’t know what it’s doing.
   • Check if the developer follows security best practices like proper OAuth implementation. Again - requires looking through the code, but it’s a way to potentially spot issues.
   • See if the owner of the MCP server has a documented security policy or vulnerability disclosure process. It’s little help if the implementation is as secure as a slice of Siwss cheese, but at least it can tell you that the developer is actively looking to mitigate issues that might pop up.

4. Understand the data flow:

   • Know where your data is going when using an MCP server. Are you OK with all your private messages going through a binary made by someone three days ago and hosted on GitHub under a pseudonymous account?
   • Be aware if your queries are being stored, processed by third parties, or used for training. Look for the privacy policy (if any - it’s a bit of a Wild West right now).
   • Consider whether sensitive information should be shared with a particular MCP server at all.

The Model Context Protocol is an exciting development, there’s no doubt about it. It already makes our AI tools more capable and useful. But as with any major advancement, I highly recommend you approach it with the same security mindset you likely learned to apply elsewhere. Don’t let the novelty and excitement around MCP make you forget the basic security practices that protect you everywhere else.

Use common sense and ask questions - don’t just install and authorize every new MCP server that starts trending on Hacker News.