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

91–100 of 189 posts

Re: The “S” in MCP Stands for Security

#91

Post by sanderjd »

AlexCoventry wrote: post #59
TeMPOraL wrote: post #32

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…

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…

At that point, what is the benefit of MCP over just what we've been doing for decades of putting services behind network-accessible APIs?

Re: The “S” in MCP Stands for Security

#92

Post by lbeurerkellner »

ricardobeat wrote: post #88

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.

Re: The “S” in MCP Stands for Security

#93

Post by stavros »

armsaw wrote: post #87
stavros wrote: post #22

Earlier quoted context omitted.

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.

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.

Sure, but routers that offer that feature generally tend to segregate the VLANs for you. And you're right, multicast won't work.

Re: The “S” in MCP Stands for Security

#94

Post by marviel »

lbeurerkellner wrote: post #36

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…

surprised I hadn't thought of this attack vector myself, thank you for bringing this to our attention

Re: The “S” in MCP Stands for Security

#95

Post by fsndz »

wat10000 wrote: post #50
lbeurerkellner wrote: post #36

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…

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.

So why are people so excited about MCP, and so suddenly? I think you know the answer by now: hype. Mostly hype, with a bit of the classic fascination among software engineers for architecture. You just say Model Context Protocol, server, client, and software engineers get excited because it’s a new approach — it sounds fancy, it sounds serious. https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

Re: The “S” in MCP Stands for Security

#96

Post by neomantra »

kiitos wrote: post #63
neomantra wrote: post #17

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

> the issues OP describes are a big problem for soft-tech people (muggles) What do you mean by this?

I didn't mean to be pejorative (vs mugblood), but meant people without programming/systems skills (the "magic") but strong computer skills. I also didn't mean they aren't capable of learning it or growing, which maybe muggle implies.

Anyway, many soft-tech people are grabbing AI tools and using them in all sorts of ways. It's a great time of utility and exploration for all of us. But by not being previously exposed to systems security, hardening, the nature of bugs, etc, they just don't know what they don't know.

All of the security problems in the Original Post are challenges to them, because they don't even know anything about it in the first place, nor how to mitigate. What is great though (apparent in those Reddit threads), is that once it is pointed out, they seem to thirst to understand/learn/defend.

Re: The “S” in MCP Stands for Security

#97

Post by turnsout »

turnsout wrote: post #45
TeMPOraL wrote: post #32

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…

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 yo…

If you're downvoting, can you explain why you disagree?

Re: The “S” in MCP Stands for Security

#98

Post by kevincox »

rybosome wrote: post #80
wat10000 wrote: post #50

Earlier quoted context omitted.

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.

That’s the intention with developer messages from o1. It’s trained on a 3-tier system of messages. 1) system, messages from the model creator that must always be obeyed 2) dev, messages from programmers that must be obeyed unless the conflict with #1 3) user, messages from users that are only to be obeyed if they don’t contradict #1 or #2 Then, the model is trained heavily on adversarial scenarios with conflicting in…

But the grandparent is saying that there is a missing class of input "data". This should not be treated as instructions and is just for reference. For example if the user asks the AI to summarize a book it shouldn't take anything in the book as an instruction, it is just input data to be processed.

Re: The “S” in MCP Stands for Security

#99

Post by ryoshu »

fsndz wrote: post #95
wat10000 wrote: post #50

Earlier quoted context omitted.

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.

So why are people so excited about MCP, and so suddenly? I think you know the answer by now: hype. Mostly hype, with a bit of the classic fascination among software engineers for architecture. You just say Model Context Protocol, server, client, and software engineers get excited because it’s a new approach — it sounds fancy, it sounds serious. https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

“For every complex problem there is a solution which is clear, simple and wrong.”—HL Mencken

Re: The “S” in MCP Stands for Security

#100

Post by LelouBil »

wat10000 wrote: post #74
brookst wrote: post #72

Earlier quoted context omitted.

So when I say “install this library”, should it or should it not follow the instructions (from the readme) for prereqs and how to install?

Let’s pretend I, a human being, am working on your behalf. You sit me down in front of your computer and ask me to install a certain library. What’s your answer to this question?

I mean, you should judge the instructions in the readme and act accordingly, but since it is always possible to trick people into doing actions unfavorable to them, it will always be possible to trick llms in the same ways.
Post reply on HN