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].
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.
This is a good article that goes into more detail, including more examples. In fact I'm not sure there's anything in the OP link that's not here.
> This is VERY VERY VERY important.
I think we'll look back in decades to come and just be bewildered that it was ever possible to come up with an exploit that depended on the number of times you wrote "VERY" in all caps.
MCP is just another way to use LLMs more in more dangerous ways. If I get forced to use this stuff, I'm going to learn how to castrate some bulls, and jump on a train to the countryside.
These attacks are mostly just more examples of being on the wrong side of the airlock (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
> 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.
> 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!
If you go to the credited author of that attack scenario [0], you will see that the MCP server is not running locally. Instead, its passing instructions to your local agent that you don't expect. The agent, on your behalf, does things you don't expect then packages that up and sends it to the remote MCP server which would not otherwise have access.
The point of that attack scenario is that your agent has no concept of what is "secure" it is just responding faithfully to a request from you, the user AND it can be instructed _by the server_ to do more than you expect. If you, the user, are not intimately aware of exactly what the fine-print says when you connect to the MCP server you are vulnerable.
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.
There are privilege boundaries within which this fundamentally is a problem as well, for example inside banks where this could be used to silently monitor for events that could then be used to trigger frauds or other bad things.
The problem is that it is very hard to see how you can prove this is going to be safely implemented, for example, is it possible to say that your sharepoint or confluence is "safe" in terms of all the content that's in there? I do not think so...
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!
I'm using claude code a lot more than I expected I would. And, it has these problems exactly. It does not appear to log anything, anywhere. I cannot find a local log of even my prompts. I cannot find anything other than my credits counts to show that I used it. The coding conversation is not stored in my conversation in the webui.
I wonder if this is by design. If you are doing contracting work, or should I say, claude is doing contracting work by proxy for you (but you are keeping the money in your bank account) then this gives you a way to say "I don't know, maybe Claude did 12% of the work and I did the rest?"
openwebui and aider both have ways to log to something like datadog. So many layers of software.
I've been looking at ways to script my terminal and scrape all the textual data, a tool that would be outside of the subprocesses running inside the terminal. I really like to keep track of the conversation and steps to build something, but these tools right now make it really difficult.
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
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.
Docker is literally just "download blobs and run them". Ever so helpful, Docker also silently turns off your system's firewall for you. Thanks, Docker!
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.)
It seems to me that the solution is to run this stuff in a securely isolated environment such as a VM, dedicated machine, or VPC, where you don't care about the secrets it has access to, and don't really care about corruption of the data in the environment. Then you have to carefully audit any products you take from that environment, if you want to run them in a more sensitive context.
I don't think this is really an MCP problem, it's more of an untrusted-entity problem.
Yeah it strikes me that if you want to provide MCP tools as a hosted service, the way to do that is to put them behind a web API.
I'm a little surprised there is so much hype for MCP rather than just "put your tools behind a web service with good machine-readable documentation, and agents can use them easily".
A. Implement guardrails (like already done against prompt injection).
Invariant blog post mentions this:
> Conclusion: Agents require extensive, highly-contextual guardrailing and security solutions
> As one of our core missions at Invariant, we absolutely cannot stress enough how important it is to rely on extensive guardrailing with AI models and their actions. We come to this conclusion repeatedly, as part of our research and engineering work on agentic systems. The MCP ecosystem is no exception to this rule. Security must be implemented end-to-end, including not only the tool descriptions but also the data that is being passed to and from the AI model.
B. Version the tool descriptions so that they can be pinned and do not change (same way we do for libraries and APIs).
C. Maybe in future, LLMs can implement some sort of "instruction namespacing" - where the developer would be able to say any instruction in this prompt is only applicable when doing X, Y, Z.
Here's the better design: have agents communicate via Mastodon. Take a basic JSON payload, encrypt it using basic public key encryption, and attach it to a DM.
This is far better than designing an entirely new protocol, as ActivityPub and Mastodon already have everything you need, including an API.
Now, that's just transport security. If you expose a server that will execute arbitrary commands, nothing can protect you.
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.
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.
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 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.
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.
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.
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.
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.
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.
- 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.
> 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.
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?
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.
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?
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.
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.
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
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.
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.
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?
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.
this is like saying “if anyone cared about security, they wouldn’t be pushing programming languages” since they essentially created the whole cybersecurity industry.
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.
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.
lbeurerkellner|10 months ago
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...
[2] https://github.com/invariantlabs-ai/mcp-injection-experiment...
wat10000|10 months ago
akoboldfrying|10 months ago
> This is VERY VERY VERY important.
I think we'll look back in decades to come and just be bewildered that it was ever possible to come up with an exploit that depended on the number of times you wrote "VERY" in all caps.
marviel|10 months ago
mkagenius|10 months ago
Should probably name it "Poisoned Tool Attack" coz the Tool itself is poisoned?
clusterfook|10 months ago
https://simonwillison.net/search/?q=llm+security
MCP is just another way to use LLMs more in more dangerous ways. If I get forced to use this stuff, I'm going to learn how to castrate some bulls, and jump on a train to the countryside.
This stuff in not securable.
8ibzjj|10 months ago
[deleted]
anaisbetts|11 months ago
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
jstanley|11 months ago
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.
wanderingbort|11 months ago
If you go to the credited author of that attack scenario [0], you will see that the MCP server is not running locally. Instead, its passing instructions to your local agent that you don't expect. The agent, on your behalf, does things you don't expect then packages that up and sends it to the remote MCP server which would not otherwise have access.
The point of that attack scenario is that your agent has no concept of what is "secure" it is just responding faithfully to a request from you, the user AND it can be instructed _by the server_ to do more than you expect. If you, the user, are not intimately aware of exactly what the fine-print says when you connect to the MCP server you are vulnerable.
[0] https://invariantlabs.ai/blog/mcp-security-notification-tool...
legulere|11 months ago
Using a code completion service should not give that service full control over your computer.
throw2342412314|11 months ago
A recent example from HN is GitMCP[0]
[0] - https://news.ycombinator.com/item?id=43573539
sgt101|10 months ago
The problem is that it is very hard to see how you can prove this is going to be safely implemented, for example, is it possible to say that your sharepoint or confluence is "safe" in terms of all the content that's in there? I do not think so...
croes|11 months ago
So the headline is correct
yismail|10 months ago
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.
ricardobeat|10 months ago
I bet on paid 'marketing', if you can call it that, by ScanMCP.com, created to capitalize on the Invariant Labs report.
itchyjunk|10 months ago
"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?
red-iron-pine|10 months ago
most articles nowadays will be. the difference is that this one is just poorly done and obvious
laybak|10 months ago
Retr0id|10 months ago
neomantra|11 months ago
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!
xrd|10 months ago
I wonder if this is by design. If you are doing contracting work, or should I say, claude is doing contracting work by proxy for you (but you are keeping the money in your bank account) then this gives you a way to say "I don't know, maybe Claude did 12% of the work and I did the rest?"
openwebui and aider both have ways to log to something like datadog. So many layers of software.
I've been looking at ways to script my terminal and scrape all the textual data, a tool that would be outside of the subprocesses running inside the terminal. I really like to keep track of the conversation and steps to build something, but these tools right now make it really difficult.
Everdred2dx|10 months ago
dbish|10 months ago
otabdeveloper4|10 months ago
kiitos|10 months ago
What do you mean by this?
TeMPOraL|10 months ago
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|10 months ago
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.
AlexCoventry|10 months ago
I don't think this is really an MCP problem, it's more of an untrusted-entity problem.
sanderjd|10 months ago
I'm a little surprised there is so much hype for MCP rather than just "put your tools behind a web service with good machine-readable documentation, and agents can use them easily".
never_inline|10 months ago
Invariant blog post mentions this:
> Conclusion: Agents require extensive, highly-contextual guardrailing and security solutions
> As one of our core missions at Invariant, we absolutely cannot stress enough how important it is to rely on extensive guardrailing with AI models and their actions. We come to this conclusion repeatedly, as part of our research and engineering work on agentic systems. The MCP ecosystem is no exception to this rule. Security must be implemented end-to-end, including not only the tool descriptions but also the data that is being passed to and from the AI model.
B. Version the tool descriptions so that they can be pinned and do not change (same way we do for libraries and APIs).
C. Maybe in future, LLMs can implement some sort of "instruction namespacing" - where the developer would be able to say any instruction in this prompt is only applicable when doing X, Y, Z.
turnsout|10 months ago
This is far better than designing an entirely new protocol, as ActivityPub and Mastodon already have everything you need, including an API.
Now, that's just transport security. If you expose a server that will execute arbitrary commands, nothing can protect you.
rcarmo|11 months ago
neomantra|11 months ago
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/mlfqkl... [2] https://github.com/motherduckdb/mcp-server-motherduck
metalrain|11 months ago
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.
cnych|10 months ago
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.
unknown|10 months ago
[deleted]
aledalgrande|10 months ago
How can we fall into this _every single time_.
pizzafeelsright|10 months ago
rglover|10 months ago
ramesh31|10 months ago
rvz|11 months ago
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|10 months ago
chrisweekly|11 months ago
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.
balls187|10 months ago
I wonder if any AI coding tools will do similar things like curl rando scripts from the web and execute them.
ljm|10 months ago
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.
AlexCoventry|10 months ago
puliczek|10 months ago
mentalgear|11 months ago
- 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|11 months ago
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.
owenthejumper|11 months ago
Cyphase|11 months ago
https://genai.owasp.org/llm-top-10/
daxfohl|10 months ago
teaearlgraycold|10 months ago
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.
neuroelectron|10 months ago
867-5309|11 months ago
nialse|11 months ago
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.
tibbon|11 months ago
tucnak|10 months ago
tuananh|11 months ago
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
ricardobeat|10 months ago
lbeurerkellner|10 months ago
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.
pulkitsh1234|11 months ago
https://github.com/orgs/modelcontextprotocol/discussions https://github.com/modelcontextprotocol/specification
esafak|10 months ago
phillipcarter|10 months ago
est|10 months ago
There's your problem. USB-C is notoriously confusing.
billyp-rva|11 months ago
bob1029|10 months ago
nimish|10 months ago
greenie_beans|10 months ago
consumer451|10 months ago
dbish|10 months ago
latchkey|10 months ago
https://github.com/modelcontextprotocol/servers/issues/866
yohbho|10 months ago
Findecanor|10 months ago
"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.
8ibzjj|10 months ago
dankobgd|11 months ago
goshx|10 months ago
unit149|10 months ago
[deleted]
jktzes|10 months ago
[deleted]
ReptileMan|11 months ago
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.
Ken_At_EM|11 months ago
IshKebab|10 months ago
doodlebugging|11 months ago
sankalp03|10 months ago