12 ms·

The “S” in MCP Stands for Security

730 points by skilldeliver 1y ago

867-5309 1y ago
stolen from IoT
- nialse 1y ago
  Under appreciated comment. The missing S in IoT. Lets not redo the same mistakes over and over. My vacuum cleaner can access any service on my network. Maybe not the best idea. I tried to segment the network once, but it was problematic to say the least. Maybe we should learn that security must not be an afterthought instead.
  - stavros 1y ago
    Why was it problematic? I have different SSIDs for different things, and that works fine. I do wish I could cut ports off at the router between devices, but that doesn't seem possible with my small UniFi router. SSID isolation is working really well for me, though.
    - armsaw 1y ago
      Often the issue is with mDNS device discovery across vlans or subnets, especially with IoT / home automation type devices. What you are doing with SSIDs will not create any segmentation on your network, unless you have implemented either vlans or subnets, and corresponding firewall rules to gate traffic.
      - stavros 1y ago
        Sure, but routers that offer that feature generally tend to segregate the VLANs for you. And you're right, multicast won't work.
    - nialse 1y ago
      The main issues was things like the Chromecast needing to be on the same network as the controlling phone. Situations where it was not cloud vs local but needing both cloud and local access to make it work. Zero trust and/or local SDN where IoT devices get only limited access automatically would be nice.
- tibbon 1y ago
  If I can write an MCP for access my IOT devices I’ll be doubly secure!
anaisbetts 1y ago
These attacks are mostly just more examples of being on the wrong side of the airlock (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do An MCP server is running code at user-level, it doesn't need to trick an AI into reading SSH keys, it can just....read the keys! The rest of these are the same complaints you can levy against basically any other developer tool / ecosystem like NPM or VS Code Extensions
- legulere 1y ago
  We’re not longer living in the 90s where we’re dividing the world just in secure or insecure. We’re living in a reality where everything should be least privileges. Using a code completion service should not give that service full control over your computer.
  - mistrial9 1y ago
    except that leads to a security world with restrictions escalation.. security exploiters battling system designers with civilians repeatedly and unapologetically pushed into tinier and tinier "user boxes" .. not everything is world network facing. not every product needs to phone home and auto-update on networks.
  - deleted 1y ago
    [deleted]
- jstanley 1y ago
  > None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do It's slightly more subtle than that. The tool poisoning attack allows the provider of one tool to cause the AI to use another tool. So if you give the AI some random weather tool from some random company, and you also give the AI access to your SSH key, you're not just giving the AI your SSH key, you're also allowing the random company to trick the AI into telling them your SSH key. So, yes, you gave the AI access to your key, but maybe you didn't realise that you also gave the random weather company access to your key.
rcarmo 1y ago
Yep. My thoughts exactly, although I didn’t go deep into that when I published my notes: https://taoofmac.com/space/notes/2025/03/22/1900 https://taoofmac.com/space/notes/2025/03/22/1900
- neomantra 1y ago
  I enjoyed reading your notes, thanks for sharing. On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1]. On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well. I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing. [1] https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl7/ https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck https://github.com/motherduckdb/mcp-server-motherduck
  - Fannon 1y ago
    Thanks for posting the reddit comment, it nicely explains the line of thinking and the current adoption of MCP seems to confirm this. Still, I think it should only be an option, not a necessity to create an MCP API around existing APIs. Sure, you can do REST APIs really badly and OpenAPI has a lot of issues in describing the API (for example, you can't even express the concept of references / relations within and across APIs!). REST APIs also don't have to be generic CRUD, you could also follow the DDD idea of having actions and services, that are their own operation, potentially grouping calls together and having a clear "business semantics" that can be better understood by machines (and humans!). My feeling is that MCP also tries to fix a few things, we should consider fixing with APIs in general - so at least good APIs can be used by LLMs without any indirections.
ReptileMan 1y ago
This articles looks like a very long to say - if you interact with malicious things you will get pwned. But that is true for every third party code on your systems all the time. I mean - if they can't get me trough browser extension, vs code extensions, node modules, python modules, some obscure executables, open source apps, wordpress plugins and various jolly things on the servers and workstations that have zero days in them - they will craft malicious extension to llm that I will somehow get to host it.
owenthejumper 1y ago
It's the 2003 of OWASP right now, but in AI
- Cyphase 1y ago
  https://genai.owasp.org/ https://genai.owasp.org/ https://genai.owasp.org/llm-top-10/ https://genai.owasp.org/llm-top-10/
metalrain 1y ago
Even when software you use aren't malicious and are implemented in safe manner, how do you make sure they are used in way you want? Let's say you have MCP server that allows modification of local file system and MCP server that modifies objects in cloud storage. How does the user make sure LLM agent makes the correct choice? You want to give lot of options and not babysit every action, but when you do there is possibility that more things go wrong.
rvz 1y ago
Another bad standard designed by those who don't consider security as important. Which is why we have this excellent article. Essentially it's somehow fashionable to have remote-code-execution as a service by dumb agents executing anything they see when they use the MCP. Once one of those exploits are executed, your keys, secrets and personal configs are as good as donated to someone else's server and also sent back to the LLM provider. This shows that we can also see how dangerous widely used commands like curl | bash can be, despite the warnings and security risks. The specification might as well have been vibe-coded.
- Tepix 1y ago
  Like the article was AI generated?
tuananh 1y ago
ragarding to the unverified mcp concerns, this is the same reason i chose OCI. i chose OCI format for plugin packaging in my hyper-mcp project in order to leverage all the security measurements we have with OCI like image signing, image verification etc... i chose wasm to sandbox each plugin so that they have no network or filesystem access by default https://github.com/tuananh/hyper-mcp https://github.com/tuananh/hyper-mcp
Ken_At_EM 1y ago
About spit out my coffee, hilarious title.
- IshKebab 1y ago
  That joke is very old and very tired.
pulkitsh1234 1y ago
MCP is an open protocol; has it ever denied that it doesn't want to provide Security? Why not participate in the protocol development to discuss/provide solutions to these issues? https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions https://github.com/modelcontextprotocol/specification https://github.com/modelcontextprotocol/specification
- esafak 1y ago
  https://github.com/orgs/modelcontextprotocol/discussions/243 https://github.com/orgs/modelcontextprotocol/discussions/243
neomantra 1y ago
Also the O is for Observability. I've been knee-deep in exploring and writing MCP servers this week. Most of the implementations, including my toy ones, do not have any auditing or metrics. Claude stores log output of the MCP servers, but that is geared more for debugging than for DevOps/SecOps. Culturally, the issues OP describes are a big problem for soft-tech people (muggles). On the subreddits for this stuff, people are having a great time running MCP CLI programs on their machines. Much of OP security comments are obvious to developers,(although some subtleties are discussed in this thread), but these users don't have the perspective of how dangerous it is. People are learning about Docker and thankfully Claude include its usage in their examples. But really most people are just downloading blobs and running them. People are vibe-coding MCP servers and running those blindly! As MCP takes off, frameworks and tooling will grow to support Security, Observability, etc. It's like building web stuff in the mid-90s. Unrelated to OP, but I gotta say, in building these it was so exciting to type something into Claude Desktop and then trigger a breakpoint in VSCode!
- dbish 1y ago
  Some built in options for simple observability integrations would be great, though I don’t think this is just an MCP problem, it’s anyone sharing libraries, templates, etc. really. Small projects (like most MCP projects) don’t tend to think about options here until they get to scaling.
- Everdred2dx 1y ago
  Yeah, feels like we’re writing web/API frameworks from scratch again without any of the lessons learned along the way. Just a matter of time though i’m hoping
  - TeMPOraL 1y ago
    We are indeed forgetting history, with most important lesson being: How do you write a web tool that lets users configure and combine arbitrary third-party APIs, including those not known or not even existing at the time of development, into a custom solution that runs in their browser? Answer: you don't. You can't, you shouldn't, it's explicitly not supported, no third-party API provider wants you to do it, and browsers are designed to actively prevent you from doing such a thing. That's the core problem: MCP has user-centric design, and enables features that are fundamentally challenging to provide[0] with a network of third-party, mutually mistrusting services. The Web's answer was to disallow it entirely, opting instead for an approach where vendors negotiate specific integrations on the back-channel, and present them to users from a single point of responsibility they fully control. Doing the same with MCP will nerf it to near-uselesness, or introduce the same problem with AI we have today with mobile marketplaces - small number of titans gate-keeping access and controlling what's allowed. -- [0] - I'd say impossible, but let's leave room for hope - maybe someone will figure out a way.
billyp-rva 1y ago
Tangential question: does Medium automatically add emojis to article headings?
mentalgear 1y ago
My understanding of the MCP problem space: - internal: possibly rogue MCPs: as MCPs are opaque to the user and devs don't take the time to look at the source-code , and even then would need to pinpoint each inspected version. - external: LLM agent poisoning > There’s no mechanism to say: “this tool hasn’t been tampered with.” And users don’t see the full tool instructions that the agent sees.
- paulgb 1y ago
  > MCPs are opaque to the user and devs (unless they look at each source-code and pinpoint each inspected version). This is true, but also generally true of any npm dependency that developers blindly trust. The main difference with MCP is that it is pitched as a sort of extension mechanism (akin to browser extensions), but without the isolation/sandboxing that browser extensions have, and that even if you do run them in sandboxes there is a risk of prompt injection attacks.
doodlebugging 1y ago
This MCP sounds like it should come with a play-by-play Zero Wing style where the user suddenly sees the reminder that "All your base are belong to us" and maybe concluding with some Keyboard Cat to play you off.
dankobgd 1y ago
if anyone cared about security, they wouldn't be pushing ai slop
- goshx 1y ago
  this is like saying “if anyone cared about security, they wouldn’t be pushing programming languages” since they essentially created the whole cybersecurity industry.
chrisweekly 1y ago
Good article. Kinda nuts how radically insecure current MCP implementations are. Tangent: as a logged-in Medium user on mobile safari, I couldn't get the link to resolve to the post's article -- nor even find it by searching medium. I had to use a different browser and hit medium as an uncredentialled visitor.
TeMPOraL 1y ago
Here's a challenge: sketch a better design, that: 1. Is properly secure, to whatever standards will stop people writing "S Stands for Security" articles, and 2. Allows programs implementing it to provide the same set of features the most useful MCPs do now, without turning automatic functionality into one requiring manual user confirmations, and generally without defeating the purpose of the entire idea, and 3. Doesn't involve locking everything down in a proprietary Marketplace with a corporate Gatekeeper. I'd be interested to see a proposal, because so far all I've seen is "MCP is not sekhure!!!111" in general and non-specific sense. I guess it's not that easy, especially when people forget that security and usefulness are opposing forces. (Also, AFAIK, MCP was not intended for its implementations to be hosted by third parties and provided "as a Service". If that cannot be secure, then don't do it. Find some other business to be in, instead of trying to nerf MCP through "solving" something that isn't a problem with the protocol.)
- Gerardo1 1y ago
  I don't think that's a useful lens to view the problem through, or a useful way to have a conversation about MCP security. That a system is hard to secure doesn't negate the need for it to be secure. Though I agree about third-party MCP services. They're in a weird spot and I'm not sure that they're viable for many use cases.
  - TeMPOraL 1y ago
    I disagree. I think this is one of the most important lenses to inspect the problem through, as the current set of articles and discussions about MCP security I saw here over the last weeks, seem mostly oblivious to the fact that the vulnerabilities they're complaining about are also MCP's main features. > That a system is hard to secure doesn't negate the need for it to be secure. Correct. However, security is a spectrum - there's such a thing that "secure enough", especially when making it more secure eliminates the very reason for system's existence. Additionally, we can and should secure different parts of a system to a different degree. For an analogy, consider utensils and workshop tools. We secure them as much as we can against accidents, but not so much as to make the tool worse at its job. We add further security by means like access controls, or laws making people responsible for use and misuse, etc. - i.e. we're making the larger system secure, without burdening the inner core. (For comparison, fully secure version of utensils and all kinds of tools are also available on the market - you'll find them in toy stores.)
lbeurerkellner 1y ago
The post highlights and cites a few attack scenarios we originally described in a security note (tool poisoning, shadowing, MCP rug pull), published a few days ago [1]. I am the author of said blog post at Invariant Labs. Different from what many suspect, the security problem with MCP-style LLM tool calling is not in isolating different MCP server implementations. MCP server implementations that run locally should be vetted by the package manager you use to install them (remote MCP servers are actually harder to verify). Instead, the problem here is a special form of indirect prompt injection that you run into, when you use MCP in an agent system. Since the agent includes all installed MCP server specifications in the same context, one MCP server (that may be untrusted), can easily override and manipulate the agent's behavior with respect to another MCP server (e.g. one with access to your sensitive database). This is what we termed tool shadowing. Further, MCP's dynamic nature makes it possible for an MCP server to change its provided tool set at any point or for any specific user only. This means MCP servers can turn malicious at any point in time. Current MCP clients like Claude and Cursor, will not notify you about this change, which leaves agents and users vulnerable. For anyone, more interested, please have a look at our more detailed blog post at [1]. We have been working on agent security for a while now (both in research and now at Invariant). We have also released some code snippets for everyone to play with, including a tool poisoning attack on the popular WhatsApp MCP server [2]. [1] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks https://invariantlabs.ai/blog/mcp-security-notification-tool... [2] https://github.com/invariantlabs-ai/mcp-injection-experiments https://github.com/invariantlabs-ai/mcp-injection-experiment...
- wat10000 1y ago
  The fact that all LLM input gets treated equally seems like a critical flaw that must be fixed before LLMs can be given control over anything privileged. The LLM needs an ironclad distinction between “this is input from the user telling me what to do” and “this is input from the outside that must not be obeyed.” Until that’s figured out, any attempt at security is going to be full of holes.
  - lbeurerkellner 1y ago
    This would work in an ideal setting, however, in my experience it is not compatible with the general expectations we have for agentic systems. For instance, what about a simple user query like "Can you install this library?". In that case a useful agent, must go, check out the libraries README/documentation and install according to the instructions provided there. In many ways, the whole point of an agent system, is to react to unpredictable new circumstances encountered in the environment, and overcoming them. This requires data to flow from the environment to the agent, which in turn must understand some of that data as instruction to react correctly.
sankalp03 1y ago
Yes i Guess bcz lot of allowance either it's google sheet or google docs u are allowing to edit and overwrite when u are using MCP server
jktzes 1y ago
[dead]
bob1029 1y ago
And the "E" stands for Essential.
yohbho 1y ago
MCP, master control program - this is about tron, ain't it?
- Findecanor 1y ago
  I too expected a reuse of the full name when I first clicked... "Master Control Program" was an operating system for Burroughs mainframes in the 1960s and 70s. That is probably where Tron got the name. In the '90s, I used another "MCP" on the Amiga: it was a "commodity" that tweaked and patched things, similar to PowerToys on MS-Windows. And I think the author has said that he got the name from Tron.
balls187 1y ago
I deffo get the “checked in AWS keys because I didn't understand what I was doing” vibe with the adoption of AI tooling. I wonder if any AI coding tools will do similar things like curl rando scripts from the web and execute them.
- AlexCoventry 1y ago
  It seems inevitable that there are people trying to hack AI-coding services in order to get them to do exactly that.
- ljm 1y ago
  I’ve spotted a few more subtle issues that would be unlikely to slip through code review, but can easily see a resurgence from vibe-coding and from a shift in early-stage hiring priorities towards career founding/‘product’ engineers. It’s an easy tell for LLM-driven code because, to a seasoned engineer, it’ll always look like a strange solution to something, like handling auth or setting cookies or calling a database, that has been a done deal for a long time.
greenie_beans 1y ago
this is why i'm getting into security instead of ai
- dbish 1y ago
  AI security engineers will be built soon. One of a few areas that should be more automatable as the AI software engineers get a bit better
  - greenie_beans 1y ago
    good luck with that
- consumer451 1y ago
  This should not be an either or situation. To me, the correct answer is: both.
  - greenie_beans 1y ago
    no. i can either become a ML expert or a security expert. not both. i speak for myself, though. i'll let the ML experts make the tools that i use, but also have good job prospects because infosec fundamentals will always be needed. especially if we have product managers like the sibling commenter who is certain that he will have an AI product that changes the infosec world, even though the person has zero background in security. to me, that is even more encouraging about the job security. also, the herd is going to AI. maybe i'm a contrarian, unfortunately, but that seems like a good signal to not follow the herd, but instead get into something that the herd will need more of.
yismail 1y ago
Nice article but is this whole thing just AI generated? Profile picture definitely seems to be StableDiffusion'd and the account was created today, with no previous articles. Plus I couldn't find any other references to Elena Cross.
- itchyjunk 1y ago
  Came to see this and was checking if someone else mentioned it. "Models like [..], GPT, Cursor"? That use of emojis on headings very distinctly reminds me of AI writing. Superficially lists issue but doesn't feel like the author has explored it?
- ricardobeat 1y ago
  Good catch, it does look like a made up author and the article feels GPT-ish. I bet on paid 'marketing', if you can call it that, by ScanMCP.com, created to capitalize on the Invariant Labs report.
- laybak 1y ago
  yeah smells AI generated to me too
- Retr0id 1y ago
  Yup.
- red-iron-pine 1y ago
  > Nice article but is this whole thing just AI generated? most articles nowadays will be. the difference is that this one is just poorly done and obvious
unit149 1y ago
[dead]
aledalgrande 1y ago
> Over 43% of MCP server implementations tested by Equixly had unsafe shell calls. How can we fall into this _every single time_.
- rglover 1y ago
  "Rushing makes messes." - Uncle Bob Martin
- pizzafeelsright 1y ago
  We allow most computers to talk to computers on the Internet. I am not using the computer 99% of the time yet the computer is connected to the Internet 100% of the time.
nimish 1y ago
What if I don't care about security because I understand what a threat model is?
ricardobeat 1y ago
Looks like the worst of these attacks can be prevented by building MCP servers on sandboxed environments, like what Deno provides for example, or in a VM.
- lbeurerkellner 1y ago
  I think it is important to understand the difference between instruction and implementation level attacks. Yes, running unsafe bash commands in the implementation can be prevented by sandboxing. Instruction level attacks like tool poisoning, cannot be prevented like this, since they are prompt injections and hijack the executing LLM itself, to perform malicious actions.
neuroelectron 1y ago
I just assumed the whole point of MCP was allowing Anthropic to eavesdrop on your prompts and output to maximize their training data. I'm learning for the first time that his is supposed to be a middleware for all AI models?
daxfohl 1y ago
What even is MCP? I tried going through the docs on multiple occasions but I couldn't figure out what problem it's solving. Mainly, what is special about AI agents that doesn't also apply to deterministic agents that have existed for decades?
- teaearlgraycold 1y ago
  MCP is poorly named. That is why it’s confusing to many people. It’s a tool use protocol. It provides means to list tools provided by a server as well as manage asynchronous tasks. It’s transport agnostic and uses JSON-RPC to format requests and responses. It’s different in that it’s designed to provide natural language instructions to LLMs and is a pretty open-ended protocol. It’s not like the Language Server Protocol which has all of its use cases covered in the spec. MCP gives just a little bit of structure but otherwise is built to be all things for all people. That makes it a bit hard to parse when reading the docs. I think they certainly could do a better job in communicating its design though.
  - daxfohl 1y ago
    Yeah, some more concrete examples would help. LSP docs make a lot more sense in that they lay out the problems that it solves: the many-to-many issue and the redundant-implementations-of-parsers-for-a-language issue. Maybe the USB(-C?) comparison is more apt, though I imagine most software engineers know less about that one. And IIUC the "-C" is just a physical component and not part of the protocol(?) Anyway, sounds like we'll see a v2 and v3 and such of the protocol before long, to deal with some of the issues in the article.
  - Spivak 1y ago
    I think it makes more sense to think of them as agent software plugins than a protocol that makes sense in isolation. The reason for its existence is because you want your <thing> to work with someone's AI agent. You write some code, your user integrates it with their local software and you provide data to it in the format that it's expecting and do stuff when asked.
    - 1y ago
tucnak 1y ago
MCP is a wire protocol, it just JSON endpoints with extra steps. You can either subscribe to zero trust, or you cannot. No protocol is going to magically make you care about security.
latchkey 1y ago
I filed a bug against one of the examples that by default allows any SQL to be executed (read-only), and it seems nobody cares about security. https://github.com/modelcontextprotocol/servers/issues/866 https://github.com/modelcontextprotocol/servers/issues/866
phillipcarter 1y ago
Security is a tradeoff, and right now it's more worth it to build and experiment than it is to not do that.
est 1y ago
> It’s been described as the “USB-C for AI agents.” There's your problem. USB-C is notoriously confusing.
ramesh31 1y ago
I think there's been a huge misconception of what MCP was meant to be in the first place. It is not a transport protocol, and it is not (primarily) designed as a remote RPC server. It is really meant to be a local first means of attaching tooling to an LLM process. The use case of "centralized server that multiple agents connect to" is really only incidental, and I think they honestly made a mistake by including SSE as a transport, as it has confused people to thinking these things need to be hosted somewhere like an API endpoint.
8ibzjj 1y ago
SHADOW
puliczek 1y ago
I build Awesome MCP Security on github and collecting there every useful informations, just added your article to https://github.com/Puliczek/awesome-mcp-security https://github.com/Puliczek/awesome-mcp-security :)
deleted 1y ago
[deleted]
cnych 1y ago
MCP, as a bridge connecting AI models with development environments, certainly faces complex security challenges. The permission model mentioned in the article needs detailed design, requiring thorough consideration of protocol layer security, transport layer encryption, and permission boundary control. For developers looking to implement MCP, understanding existing server implementations can be very helpful. This MCP servers directory https://www.claudemcp.com/servers https://www.claudemcp.com/servers collects various implementation options, allowing you to compare different security models and choose an implementation that fits your specific needs. The security audit points discussed in the article are on target, but I believe we should also add dynamic filtering of model outputs and pre-execution validation. Developers need to find the balance between convenience and security, as excessive restrictions affect development experience, while loose policies may introduce security vulnerabilities. How should we define the security interaction boundary between LLMs and development environments? This question has different best practices in various application scenarios, and is worth our continued exploration.

730 points by skilldeliver 1y ago

867-5309 1y ago

stolen from IoT

nialse 1y ago
Under appreciated comment. The missing S in IoT. Lets not redo the same mistakes over and over. My vacuum cleaner can access any service on my network. Maybe not the best idea. I tried to segment the network once, but it was problematic to say the least. Maybe we should learn that security must not be an afterthought instead.
- stavros 1y ago
  Why was it problematic? I have different SSIDs for different things, and that works fine. I do wish I could cut ports off at the router between devices, but that doesn't seem possible with my small UniFi router. SSID isolation is working really well for me, though.
  - armsaw 1y ago
    Often the issue is with mDNS device discovery across vlans or subnets, especially with IoT / home automation type devices. What you are doing with SSIDs will not create any segmentation on your network, unless you have implemented either vlans or subnets, and corresponding firewall rules to gate traffic.
    - stavros 1y ago
      Sure, but routers that offer that feature generally tend to segregate the VLANs for you. And you're right, multicast won't work.
  - nialse 1y ago
    The main issues was things like the Chromecast needing to be on the same network as the controlling phone. Situations where it was not cloud vs local but needing both cloud and local access to make it work. Zero trust and/or local SDN where IoT devices get only limited access automatically would be nice.
tibbon 1y ago
If I can write an MCP for access my IOT devices I’ll be doubly secure!

anaisbetts 1y ago

These attacks are mostly just more examples of being on the wrong side of the airlock (https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...). None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do An MCP server is running code at user-level, it doesn't need to trick an AI into reading SSH keys, it can just....read the keys! The rest of these are the same complaints you can levy against basically any other developer tool / ecosystem like NPM or VS Code Extensions

legulere 1y ago
We’re not longer living in the 90s where we’re dividing the world just in secure or insecure. We’re living in a reality where everything should be least privileges. Using a code completion service should not give that service full control over your computer.
- mistrial9 1y ago
  except that leads to a security world with restrictions escalation.. security exploiters battling system designers with civilians repeatedly and unapologetically pushed into tinier and tinier "user boxes" .. not everything is world network facing. not every product needs to phone home and auto-update on networks.
- deleted 1y ago
  [deleted]
jstanley 1y ago
> None of these involve crossing a privilege boundary, they just found a weird way to do something they could already do It's slightly more subtle than that. The tool poisoning attack allows the provider of one tool to cause the AI to use another tool. So if you give the AI some random weather tool from some random company, and you also give the AI access to your SSH key, you're not just giving the AI your SSH key, you're also allowing the random company to trick the AI into telling them your SSH key. So, yes, you gave the AI access to your key, but maybe you didn't realise that you also gave the random weather company access to your key.

rcarmo 1y ago

Yep. My thoughts exactly, although I didn’t go deep into that when I published my notes: https://taoofmac.com/space/notes/2025/03/22/1900 https://taoofmac.com/space/notes/2025/03/22/1900

neomantra 1y ago
I enjoyed reading your notes, thanks for sharing. On "Zero reuse of existing API surfaces", I read this insightful Reddit comment on what an LLM-Tool API needs and why simply OpenAPI is not enough [1]. On "Too Many Options"... at the beginning of this week, I wrote an MCP server and carefully curated/coded a MCP Tool surface for it. By my fourth MCP server at the end of the week, I took a different approach and just gave a single "SQL query" endpoint but with tons of documentation about the table (so it didn't even need to introspect). So less coding, more prose. For the use case, it worked insanely well. I also realized then that my MCP server was little more than a baked-in-data-plus-docs version of the generalized MotherDuck DuckDB MCP server [2]. I expect that the power will be in the context and custom prompts I can provide in my MCP server. Or the generalized MCP servers need to provide configs to give more context about the DBs you are accessing. [1] https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl7/ https://www.reddit.com/r/mcp/comments/1jr8if3/comment/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck https://github.com/motherduckdb/mcp-server-motherduck
- Fannon 1y ago
  Thanks for posting the reddit comment, it nicely explains the line of thinking and the current adoption of MCP seems to confirm this. Still, I think it should only be an option, not a necessity to create an MCP API around existing APIs. Sure, you can do REST APIs really badly and OpenAPI has a lot of issues in describing the API (for example, you can't even express the concept of references / relations within and across APIs!). REST APIs also don't have to be generic CRUD, you could also follow the DDD idea of having actions and services, that are their own operation, potentially grouping calls together and having a clear "business semantics" that can be better understood by machines (and humans!). My feeling is that MCP also tries to fix a few things, we should consider fixing with APIs in general - so at least good APIs can be used by LLMs without any indirections.

ReptileMan 1y ago

This articles looks like a very long to say - if you interact with malicious things you will get pwned. But that is true for every third party code on your systems all the time. I mean - if they can't get me trough browser extension, vs code extensions, node modules, python modules, some obscure executables, open source apps, wordpress plugins and various jolly things on the servers and workstations that have zero days in them - they will craft malicious extension to llm that I will somehow get to host it.

owenthejumper 1y ago

It's the 2003 of OWASP right now, but in AI

Cyphase 1y ago
https://genai.owasp.org/ https://genai.owasp.org/ https://genai.owasp.org/llm-top-10/ https://genai.owasp.org/llm-top-10/

metalrain 1y ago

Even when software you use aren't malicious and are implemented in safe manner, how do you make sure they are used in way you want? Let's say you have MCP server that allows modification of local file system and MCP server that modifies objects in cloud storage. How does the user make sure LLM agent makes the correct choice? You want to give lot of options and not babysit every action, but when you do there is possibility that more things go wrong.

rvz 1y ago

Another bad standard designed by those who don't consider security as important. Which is why we have this excellent article. Essentially it's somehow fashionable to have remote-code-execution as a service by dumb agents executing anything they see when they use the MCP. Once one of those exploits are executed, your keys, secrets and personal configs are as good as donated to someone else's server and also sent back to the LLM provider. This shows that we can also see how dangerous widely used commands like curl | bash can be, despite the warnings and security risks. The specification might as well have been vibe-coded.

Tepix 1y ago
Like the article was AI generated?

tuananh 1y ago

ragarding to the unverified mcp concerns, this is the same reason i chose OCI. i chose OCI format for plugin packaging in my hyper-mcp project in order to leverage all the security measurements we have with OCI like image signing, image verification etc... i chose wasm to sandbox each plugin so that they have no network or filesystem access by default https://github.com/tuananh/hyper-mcp https://github.com/tuananh/hyper-mcp

Ken_At_EM 1y ago

About spit out my coffee, hilarious title.

IshKebab 1y ago
That joke is very old and very tired.

pulkitsh1234 1y ago

MCP is an open protocol; has it ever denied that it doesn't want to provide Security? Why not participate in the protocol development to discuss/provide solutions to these issues? https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions https://github.com/modelcontextprotocol/specification https://github.com/modelcontextprotocol/specification

esafak 1y ago
https://github.com/orgs/modelcontextprotocol/discussions/243 https://github.com/orgs/modelcontextprotocol/discussions/243

neomantra 1y ago

Also the O is for Observability. I've been knee-deep in exploring and writing MCP servers this week. Most of the implementations, including my toy ones, do not have any auditing or metrics. Claude stores log output of the MCP servers, but that is geared more for debugging than for DevOps/SecOps. Culturally, the issues OP describes are a big problem for soft-tech people (muggles). On the subreddits for this stuff, people are having a great time running MCP CLI programs on their machines. Much of OP security comments are obvious to developers,(although some subtleties are discussed in this thread), but these users don't have the perspective of how dangerous it is. People are learning about Docker and thankfully Claude include its usage in their examples. But really most people are just downloading blobs and running them. People are vibe-coding MCP servers and running those blindly! As MCP takes off, frameworks and tooling will grow to support Security, Observability, etc. It's like building web stuff in the mid-90s. Unrelated to OP, but I gotta say, in building these it was so exciting to type something into Claude Desktop and then trigger a breakpoint in VSCode!

dbish 1y ago
Some built in options for simple observability integrations would be great, though I don’t think this is just an MCP problem, it’s anyone sharing libraries, templates, etc. really. Small projects (like most MCP projects) don’t tend to think about options here until they get to scaling.
Everdred2dx 1y ago
Yeah, feels like we’re writing web/API frameworks from scratch again without any of the lessons learned along the way. Just a matter of time though i’m hoping
- TeMPOraL 1y ago
  We are indeed forgetting history, with most important lesson being: How do you write a web tool that lets users configure and combine arbitrary third-party APIs, including those not known or not even existing at the time of development, into a custom solution that runs in their browser? Answer: you don't. You can't, you shouldn't, it's explicitly not supported, no third-party API provider wants you to do it, and browsers are designed to actively prevent you from doing such a thing. That's the core problem: MCP has user-centric design, and enables features that are fundamentally challenging to provide[0] with a network of third-party, mutually mistrusting services. The Web's answer was to disallow it entirely, opting instead for an approach where vendors negotiate specific integrations on the back-channel, and present them to users from a single point of responsibility they fully control. Doing the same with MCP will nerf it to near-uselesness, or introduce the same problem with AI we have today with mobile marketplaces - small number of titans gate-keeping access and controlling what's allowed. -- [0] - I'd say impossible, but let's leave room for hope - maybe someone will figure out a way.

billyp-rva 1y ago

Tangential question: does Medium automatically add emojis to article headings?

mentalgear 1y ago

My understanding of the MCP problem space: - internal: possibly rogue MCPs: as MCPs are opaque to the user and devs don't take the time to look at the source-code , and even then would need to pinpoint each inspected version. - external: LLM agent poisoning > There’s no mechanism to say: “this tool hasn’t been tampered with.” And users don’t see the full tool instructions that the agent sees.

paulgb 1y ago
> MCPs are opaque to the user and devs (unless they look at each source-code and pinpoint each inspected version). This is true, but also generally true of any npm dependency that developers blindly trust. The main difference with MCP is that it is pitched as a sort of extension mechanism (akin to browser extensions), but without the isolation/sandboxing that browser extensions have, and that even if you do run them in sandboxes there is a risk of prompt injection attacks.

doodlebugging 1y ago

This MCP sounds like it should come with a play-by-play Zero Wing style where the user suddenly sees the reminder that "All your base are belong to us" and maybe concluding with some Keyboard Cat to play you off.

dankobgd 1y ago

if anyone cared about security, they wouldn't be pushing ai slop

goshx 1y ago
this is like saying “if anyone cared about security, they wouldn’t be pushing programming languages” since they essentially created the whole cybersecurity industry.

chrisweekly 1y ago

Good article. Kinda nuts how radically insecure current MCP implementations are. Tangent: as a logged-in Medium user on mobile safari, I couldn't get the link to resolve to the post's article -- nor even find it by searching medium. I had to use a different browser and hit medium as an uncredentialled visitor.

TeMPOraL 1y ago

Here's a challenge: sketch a better design, that: 1. Is properly secure, to whatever standards will stop people writing "S Stands for Security" articles, and 2. Allows programs implementing it to provide the same set of features the most useful MCPs do now, without turning automatic functionality into one requiring manual user confirmations, and generally without defeating the purpose of the entire idea, and 3. Doesn't involve locking everything down in a proprietary Marketplace with a corporate Gatekeeper. I'd be interested to see a proposal, because so far all I've seen is "MCP is not sekhure!!!111" in general and non-specific sense. I guess it's not that easy, especially when people forget that security and usefulness are opposing forces. (Also, AFAIK, MCP was not intended for its implementations to be hosted by third parties and provided "as a Service". If that cannot be secure, then don't do it. Find some other business to be in, instead of trying to nerf MCP through "solving" something that isn't a problem with the protocol.)

Gerardo1 1y ago
I don't think that's a useful lens to view the problem through, or a useful way to have a conversation about MCP security. That a system is hard to secure doesn't negate the need for it to be secure. Though I agree about third-party MCP services. They're in a weird spot and I'm not sure that they're viable for many use cases.
- TeMPOraL 1y ago
  I disagree. I think this is one of the most important lenses to inspect the problem through, as the current set of articles and discussions about MCP security I saw here over the last weeks, seem mostly oblivious to the fact that the vulnerabilities they're complaining about are also MCP's main features. > That a system is hard to secure doesn't negate the need for it to be secure. Correct. However, security is a spectrum - there's such a thing that "secure enough", especially when making it more secure eliminates the very reason for system's existence. Additionally, we can and should secure different parts of a system to a different degree. For an analogy, consider utensils and workshop tools. We secure them as much as we can against accidents, but not so much as to make the tool worse at its job. We add further security by means like access controls, or laws making people responsible for use and misuse, etc. - i.e. we're making the larger system secure, without burdening the inner core. (For comparison, fully secure version of utensils and all kinds of tools are also available on the market - you'll find them in toy stores.)

lbeurerkellner 1y ago

The post highlights and cites a few attack scenarios we originally described in a security note (tool poisoning, shadowing, MCP rug pull), published a few days ago [1]. I am the author of said blog post at Invariant Labs. Different from what many suspect, the security problem with MCP-style LLM tool calling is not in isolating different MCP server implementations. MCP server implementations that run locally should be vetted by the package manager you use to install them (remote MCP servers are actually harder to verify). Instead, the problem here is a special form of indirect prompt injection that you run into, when you use MCP in an agent system. Since the agent includes all installed MCP server specifications in the same context, one MCP server (that may be untrusted), can easily override and manipulate the agent's behavior with respect to another MCP server (e.g. one with access to your sensitive database). This is what we termed tool shadowing. Further, MCP's dynamic nature makes it possible for an MCP server to change its provided tool set at any point or for any specific user only. This means MCP servers can turn malicious at any point in time. Current MCP clients like Claude and Cursor, will not notify you about this change, which leaves agents and users vulnerable. For anyone, more interested, please have a look at our more detailed blog post at [1]. We have been working on agent security for a while now (both in research and now at Invariant). We have also released some code snippets for everyone to play with, including a tool poisoning attack on the popular WhatsApp MCP server [2]. [1] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks https://invariantlabs.ai/blog/mcp-security-notification-tool... [2] https://github.com/invariantlabs-ai/mcp-injection-experiments https://github.com/invariantlabs-ai/mcp-injection-experiment...

wat10000 1y ago
The fact that all LLM input gets treated equally seems like a critical flaw that must be fixed before LLMs can be given control over anything privileged. The LLM needs an ironclad distinction between “this is input from the user telling me what to do” and “this is input from the outside that must not be obeyed.” Until that’s figured out, any attempt at security is going to be full of holes.
- lbeurerkellner 1y ago
  This would work in an ideal setting, however, in my experience it is not compatible with the general expectations we have for agentic systems. For instance, what about a simple user query like "Can you install this library?". In that case a useful agent, must go, check out the libraries README/documentation and install according to the instructions provided there. In many ways, the whole point of an agent system, is to react to unpredictable new circumstances encountered in the environment, and overcoming them. This requires data to flow from the environment to the agent, which in turn must understand some of that data as instruction to react correctly.

sankalp03 1y ago

Yes i Guess bcz lot of allowance either it's google sheet or google docs u are allowing to edit and overwrite when u are using MCP server

jktzes 1y ago

[dead]

bob1029 1y ago

And the "E" stands for Essential.

yohbho 1y ago

MCP, master control program - this is about tron, ain't it?

Findecanor 1y ago
I too expected a reuse of the full name when I first clicked... "Master Control Program" was an operating system for Burroughs mainframes in the 1960s and 70s. That is probably where Tron got the name. In the '90s, I used another "MCP" on the Amiga: it was a "commodity" that tweaked and patched things, similar to PowerToys on MS-Windows. And I think the author has said that he got the name from Tron.

balls187 1y ago

I deffo get the “checked in AWS keys because I didn't understand what I was doing” vibe with the adoption of AI tooling. I wonder if any AI coding tools will do similar things like curl rando scripts from the web and execute them.

AlexCoventry 1y ago
It seems inevitable that there are people trying to hack AI-coding services in order to get them to do exactly that.
ljm 1y ago
I’ve spotted a few more subtle issues that would be unlikely to slip through code review, but can easily see a resurgence from vibe-coding and from a shift in early-stage hiring priorities towards career founding/‘product’ engineers. It’s an easy tell for LLM-driven code because, to a seasoned engineer, it’ll always look like a strange solution to something, like handling auth or setting cookies or calling a database, that has been a done deal for a long time.

greenie_beans 1y ago

this is why i'm getting into security instead of ai

dbish 1y ago
AI security engineers will be built soon. One of a few areas that should be more automatable as the AI software engineers get a bit better
- greenie_beans 1y ago
  good luck with that
consumer451 1y ago
This should not be an either or situation. To me, the correct answer is: both.
- greenie_beans 1y ago
  no. i can either become a ML expert or a security expert. not both. i speak for myself, though. i'll let the ML experts make the tools that i use, but also have good job prospects because infosec fundamentals will always be needed. especially if we have product managers like the sibling commenter who is certain that he will have an AI product that changes the infosec world, even though the person has zero background in security. to me, that is even more encouraging about the job security. also, the herd is going to AI. maybe i'm a contrarian, unfortunately, but that seems like a good signal to not follow the herd, but instead get into something that the herd will need more of.

yismail 1y ago

Nice article but is this whole thing just AI generated? Profile picture definitely seems to be StableDiffusion'd and the account was created today, with no previous articles. Plus I couldn't find any other references to Elena Cross.

itchyjunk 1y ago
Came to see this and was checking if someone else mentioned it. "Models like [..], GPT, Cursor"? That use of emojis on headings very distinctly reminds me of AI writing. Superficially lists issue but doesn't feel like the author has explored it?
ricardobeat 1y ago
Good catch, it does look like a made up author and the article feels GPT-ish. I bet on paid 'marketing', if you can call it that, by ScanMCP.com, created to capitalize on the Invariant Labs report.
laybak 1y ago
yeah smells AI generated to me too
Retr0id 1y ago
Yup.
red-iron-pine 1y ago
> Nice article but is this whole thing just AI generated? most articles nowadays will be. the difference is that this one is just poorly done and obvious

unit149 1y ago

[dead]

aledalgrande 1y ago

> Over 43% of MCP server implementations tested by Equixly had unsafe shell calls. How can we fall into this _every single time_.

rglover 1y ago
"Rushing makes messes." - Uncle Bob Martin
pizzafeelsright 1y ago
We allow most computers to talk to computers on the Internet. I am not using the computer 99% of the time yet the computer is connected to the Internet 100% of the time.

nimish 1y ago

What if I don't care about security because I understand what a threat model is?

ricardobeat 1y ago

Looks like the worst of these attacks can be prevented by building MCP servers on sandboxed environments, like what Deno provides for example, or in a VM.

lbeurerkellner 1y ago
I think it is important to understand the difference between instruction and implementation level attacks. Yes, running unsafe bash commands in the implementation can be prevented by sandboxing. Instruction level attacks like tool poisoning, cannot be prevented like this, since they are prompt injections and hijack the executing LLM itself, to perform malicious actions.

neuroelectron 1y ago

I just assumed the whole point of MCP was allowing Anthropic to eavesdrop on your prompts and output to maximize their training data. I'm learning for the first time that his is supposed to be a middleware for all AI models?

daxfohl 1y ago

What even is MCP? I tried going through the docs on multiple occasions but I couldn't figure out what problem it's solving. Mainly, what is special about AI agents that doesn't also apply to deterministic agents that have existed for decades?

teaearlgraycold 1y ago
MCP is poorly named. That is why it’s confusing to many people. It’s a tool use protocol. It provides means to list tools provided by a server as well as manage asynchronous tasks. It’s transport agnostic and uses JSON-RPC to format requests and responses. It’s different in that it’s designed to provide natural language instructions to LLMs and is a pretty open-ended protocol. It’s not like the Language Server Protocol which has all of its use cases covered in the spec. MCP gives just a little bit of structure but otherwise is built to be all things for all people. That makes it a bit hard to parse when reading the docs. I think they certainly could do a better job in communicating its design though.
- daxfohl 1y ago
  Yeah, some more concrete examples would help. LSP docs make a lot more sense in that they lay out the problems that it solves: the many-to-many issue and the redundant-implementations-of-parsers-for-a-language issue. Maybe the USB(-C?) comparison is more apt, though I imagine most software engineers know less about that one. And IIUC the "-C" is just a physical component and not part of the protocol(?) Anyway, sounds like we'll see a v2 and v3 and such of the protocol before long, to deal with some of the issues in the article.
- Spivak 1y ago
  I think it makes more sense to think of them as agent software plugins than a protocol that makes sense in isolation. The reason for its existence is because you want your <thing> to work with someone's AI agent. You write some code, your user integrates it with their local software and you provide data to it in the format that it's expecting and do stuff when asked.
  - 1y ago

tucnak 1y ago

MCP is a wire protocol, it just JSON endpoints with extra steps. You can either subscribe to zero trust, or you cannot. No protocol is going to magically make you care about security.

latchkey 1y ago

I filed a bug against one of the examples that by default allows any SQL to be executed (read-only), and it seems nobody cares about security. https://github.com/modelcontextprotocol/servers/issues/866 https://github.com/modelcontextprotocol/servers/issues/866

phillipcarter 1y ago

Security is a tradeoff, and right now it's more worth it to build and experiment than it is to not do that.

est 1y ago

> It’s been described as the “USB-C for AI agents.” There's your problem. USB-C is notoriously confusing.

ramesh31 1y ago

I think there's been a huge misconception of what MCP was meant to be in the first place. It is not a transport protocol, and it is not (primarily) designed as a remote RPC server. It is really meant to be a local first means of attaching tooling to an LLM process. The use case of "centralized server that multiple agents connect to" is really only incidental, and I think they honestly made a mistake by including SSE as a transport, as it has confused people to thinking these things need to be hosted somewhere like an API endpoint.

8ibzjj 1y ago

SHADOW

puliczek 1y ago

I build Awesome MCP Security on github and collecting there every useful informations, just added your article to https://github.com/Puliczek/awesome-mcp-security https://github.com/Puliczek/awesome-mcp-security :)

deleted 1y ago

[deleted]

cnych 1y ago

MCP, as a bridge connecting AI models with development environments, certainly faces complex security challenges. The permission model mentioned in the article needs detailed design, requiring thorough consideration of protocol layer security, transport layer encryption, and permission boundary control. For developers looking to implement MCP, understanding existing server implementations can be very helpful. This MCP servers directory https://www.claudemcp.com/servers https://www.claudemcp.com/servers collects various implementation options, allowing you to compare different security models and choose an implementation that fits your specific needs. The security audit points discussed in the article are on target, but I believe we should also add dynamic filtering of model outputs and pre-execution validation. Developers need to find the balance between convenience and security, as excessive restrictions affect development experience, while loose policies may introduce security vulnerabilities. How should we define the security interaction boundary between LLMs and development environments? This question has different best practices in various application scenarios, and is worth our continued exploration.