Live data from Hacker News

The “S” in MCP Stands for Security

elenacross7.medium.com

41–50 of 189 posts

Re: The “S” in MCP Stands for Security

#43

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…

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.

Re: The “S” in MCP Stands for Security

#45

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

Re: The “S” in MCP Stands for Security

#50

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.
Post reply on HN