Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The “S” in MCP Stands for Security

elenacross7.medium.com

Post reply on HN
Print view View original

21–30 of 189 posts

Re: The “S” in MCP Stands for Security

#21

Post by croes »

anaisbetts wrote: post #3

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…

>The rest of these are the same complaints you can levy against basically any other developer tool / ecosystem like NPM or VS Code Extensions

So the headline is correct

Re: The “S” in MCP Stands for Security

#22

Post by stavros »

nialse wrote: post #14
867-5309 wrote: post #2

stolen from IoT

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.

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.

Re: The “S” in MCP Stands for Security

#24

Post by mentalgear »

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.

Re: The “S” in MCP Stands for Security

#26

Post by paulgb »

mentalgear wrote: post #24

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.

> 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.

Re: The “S” in MCP Stands for Security

#27

Post by OJFord »

jstanley wrote: post #8
anaisbetts wrote: post #3

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…

> 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, y…

Isn't this like giving VS Code access to your filesystem, and maybe you didn't realise you also gave a VS Code plugin access to your filesystem?

Re: The “S” in MCP Stands for Security

#29

Post by chrisweekly »

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.

Re: The “S” in MCP Stands for Security

#30

Post by jstanley »

OJFord wrote: post #27
jstanley wrote: post #8

Earlier quoted context omitted.

> 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, y…

Isn't this like giving VS Code access to your filesystem, and maybe you didn't realise you also gave a VS Code plugin access to your filesystem?

Kind of, maybe more like not realising that each VS Code plugin has access to all your other VS Code plugins.
Post reply on HN