22 comments
Same root causes again - check out https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
This can be easily used to search for seeds/private keys when AI coding agents are in YOLO mode.
The "lethal trifecta" refers to default configurations, excessive permissions, and inadequate authentication - three factors that plague MCP implementations just as they did with earlier technologies.
We have not learned anything from the hundreds of open MongoDB databases without passwords floating around the internet waiting to be breached.
We now have the same with MCP servers in the AI era as documented in [0].
MCP clearly needs an independent monitoring program to safeguard it. Let's call it Tron.
Truly, S in MCP stands for Security!
And P in WFH stands for productive.
The S in SFTP?
The S in SSH?
The S in HTTPS?
The S in MCP?
All stand for the same thing!
I remember when this joke was first applied to IoT.
I do love the joke, but it is worth remembering as well that all of those S were to a certain extent afterthoughts to fix otherwise insecure protocols.
Given how old FTP and HTTP are it's fairly understandable that they weren't initially designed with security in mind, but I think it's valid to question why we're still designing insecure systems in 2025.
Totally agree, If we have made a mistakes in past we must have learnt from it and when designing a standard specially with AI where the outcome is non deterministic we got be more careful.
That's quite the point of the joke. Even today, we still design things that will need an S tacked onto it at some point in the future.
MCP new spec has to an extent covered auth. But the MCPs are yet to adopt to that.
Auth doesn't protect against confused deputy attacks, which is a common problem exposed by MCP and other LLM tool systems. https://en.m.wikipedia.org/wiki/Confused_deputy_problem
100% - especially when Auth stands for just Authentication. Simple RBAC authorization also won't take us far. But Fine-grained Permissions(e.g. OPA, Cedar, OpenFGA, Permit.io) with ReBAC giving ai-agents Zero standing permissions, and only deriving on the fly the least privilege they need / got consent for, can dramatically reduce the problem
What are the actual exploits that should be tested though?
This post is an obvious victim of upvote manipulation. HN should ban the forgecode domain if it's going to abuse submissions like this.
Can you provide some context for your position? I’m not particularly familiar with ForgeCode. I’m interested in why you think there’s manipulation, and what you mean by “submissions like these”.
It's true that there were many inorganic upvotes on this submission, made within the first 10-20 minutes by a bot. Maybe bigyabai could see that there was an unusually high vote count for a story that was submitted so recently.
But this just goes to show how futile – indeed counter-productive – this kind of activity is. These votes are easily detected and were ignored, and the submission had enough legit upvotes to make it onto the front page organically. We've penalized the users involved and the domain, as we can't let this kind of attempted abuse go without any consequence.
But also, public callouts like this are against the guidelines and we ask that people let us know via email at hn@ycombinator.com. This allows us to know about it sooner and investigate it thoroughly before making a public comment about it.
[dead]
[dead]
MCP adoption is picking up fast.