What’s obvious to the audience of HN isn’t necessarily obvious to anyone else.
Articles like this are intended to serve the latter group of people.
And it’s true, AI agents with MCP servers are pretty much unsafe by design, because security was never considered from the start. Until that changes, if it ever even does, the best thing to do is to inform.
The recent npm supply chain attacks were directly targeting people in the HN crowd. Don’t think because you’re here and know tech that you’re immune.
The npm supply chain attacks (or any similar ones) are essentially the same issue described in the article. You can't trust 3rd-party provided code implicitly. Even if the code is initially fine it's subject to change in later revisions. This issue goes all the way down the stack. Obviously, with a large user base the likelihood of quick detection goes up, but the issue never goes away.
> You can't trust 3rd-party provided code implicitly.
But that is what (almost) all of us do.
There is debate about this the rust world, where there are mitigations that very few even aware of
Mostly rusticans block their ears, close their eyes, and pretend everything will be just peachy
Until some ordinary developer develops a crypto wallet in Rust, honestly, that steals money for a third party this will not be addressed. Even then...
This is a big problem and we need to make everybody aware that they can protect themselves, and make them Liable for not taking those steps, before that happens
What exactly are you talking about? Interested to learn more.
Almost every developer outside the defense and aerospace sector is just stuffing code from internet randos into their binaries, JARs, and wheels. Just after they run this code on their developer machine that they keep their SSH keys on. It's a wonder/mystery/miracle we're not all hacked all day every day. The Rust and JS worlds are especially bad because somehow people got it into their heads that more dependencies are better. Why write 5 lines of your own code when you can use a dependency? (This is a real example of a discussion I've had at work)
Ah, I see. True. In my case I am looking forward to setting up a Linux workstation where I will severely limit random access to my system (and $HOME) via various means i.e. Flatpak and others. $HOME/.ssh is definitely first on the list.
But I agree that the out-of-the-box settings really make you wonder how we are not indeed hacked all day every day.
> What’s obvious to the audience of HN isn’t necessarily obvious to anyone else.
AI amplifies the problem.
Before AI, the idiot who accidentally has too much access probably doesn't have the ability to actively exploit it.
Given how much AI is being shoved down everybody's throats, an idiot with access now is an attack vector because they are have neither the ability nor desire to vet anything the AI is feeding to them.
> Before AI...
yes. Previously that idiot had to write code. Now it's the LLM that is directing invocation of these functions. And the LLM is a coding prodigy with the judgment of a 3 year old kid.
> Until that changes
MCP is just JSON RPC API dialect. It is not "safe" or "unsafe" by design - it's a layer where notion of safety (as talked about in the article) is not applicable. Saying that "MCP is unsafe" is not a meaningful statement in the scope of what MCP is. Nothing about any RPC (by itself) can guarantee that the remote system would do or not do something when some method is invoked.
Unless someone figures out a way to make end-user comprehensible language for formal software verification, so there could be an accompanying spec that describes the behavior to the dot, and technology that validates the implementation against the spec.
Right now the only spec is the actual codebase, and most users aren't typically reviewing that at all.
It isn't just an RPC spec, it's a use case. Specs never exist without a reason. I can assure you, a spec is a lot of work to write. You don't do it unless there is a purpose.
And with MCP, that purpose is fundamentally unsafe. It cannot be done safely without a different underlying technology. So yeah, it's pretty fair to say MCP is unsafe by design. It wouldn't exist except for that desire to create systems which cannot be secure.
MCPs are just fancy wrappers over rest apis, at least majority of the MCP servers out in the market are like that.
Having an MCP necessarily does not mean it is unsafe until and unless the company rushed execution and released something which it should not have in the first place.
Sorry, I don’t understand. My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they’re called is - in my understanding - out of scope of MCP. To me MCP is literally a plumbing between black boxes, and plumbing cannot do anything about the safety of what happens outside of it. So to me MCP is not “safe” or “unsafe” - those terms are meaningless for a plumbing (as long, of course, as plumbing itself doesn’t somehow explode or connect somewhere it’s not supposed to or stuff like that). Do you mean the purpose and/or scope are different somehow?
> My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call.
That's exactly the point the GP was making: this is a fundamentally unsafe idea. It's impossible to allow an LLM to automatically run tools in a safe way. So yes, MCP as means to enable this fundamentally unsafe use case is fundamentally unsafe.
My point is that the term “safe” is not a good one. In context of the article it erodes the scope of what MCP is and what it does (bringing way more stuff into the picture) and misattributes issue.
MCP safety is stuff like access controls, or lack of vulnerabilities on the protocol level (stuff like XML entity bombs). Software behavior of what MCP bridges together is not MCP anymore.
People discovering and running malware believing it’s legit is not a MCP problem. This line of thought is based on that “P” stands for “protocol” - MCP is interface, not implementation. And it’s humans who pick and connect programs (LLMs and MCP servers), not technology.
Not an XML bomb, but... at the protocol level, AFAIK, MCP allows the server to change its list of tools and what they do, and the description of what they do, at any point. The chatbot when it starts up, calls "tools/list" and gets a list of tools. So, if "approval for use" depends on that data, .. the approval is built on something that can shift at any time.
That, coupled with dynamic invocation driven by the LLM engine, seems like a security problem at the protocol level.
-----
Contrast to connecting an agent to a service that is defined by a spec. In this hypothetical world, I can tell my agent: "here's the spec and here's the endpoint that implements it". And then my agent will theoretically call only the methods in the spec. The endpoint may change, my spec won't.
I still need to trust the endpoint; that it's not compromised. Maybe I'm seeing a difference where there is none.
You’re correct. MCP is just a defined way of mapping string descriptions to functions.
I thought about it, and I think I know what the confusion could possibly be about.
To me, postmark-mcp is not a part of MCP, it’s a black box that talks MCP on one end. And its behavior is not an MCP but software trust and distribution issue, not specific to MCP (just like running any executables from random sources). I guess others may see differently.
Right but you have a good security posture and hygiene. MCP as a use case (not a protocol) is encouraging risky usage by less security minded people.
I was more referring to the environment that MCP servers run within, which at the end of the day is simply a massive interpolated string that blends instructions and data/content together in a way that an LLM will do its best to figure out a helpful response.
A 'perfectly secured' MCP server will become insecure simply by existing along neighbouring, insecure, tools. With that, I think it's safe to take a broader, less technical definition and say that you should use AI agents + MCP servers with caution.
Do people outside the HN audience exist that are using MCP servers?
Well, yes but they are not less nerd (actually, HN audience is not like it used to be, too)
> the best thing to do is to inform.
While also not using them yourself/actively trying to find and strip them out of workflows you have control over.