Show HN: An MCP Gateway to block the lethal trifecta
12 comments
·September 12, 2025bradleybuda
I think the "lethal trifecta" framing is useful and glad that attempts are being made at this! But there are two big, hard-to-solve problems here:
1. The "lethal trifecta" is also the "productive trifecta" - people want to be able to use LLMs to operate in this space since that's where much of the value is; using private / proprietary data to interact with (do I/O with) the real world.
2. I worry that there will soon be (if not already) a fourth leg to the stool - latent malicious training within the LLMs themselves. I know the AI labs are working on this, but trying to ferret out Manchurian Candidates embedded within LLMs may very well be the greatest security challenge of the next few decades.
76SlashDolphin
Those are really good points and we do have some plans for them, mainly on the first topic. What we're envisioning in terms of UX for our gateway is that when you set it up it's very defensive but whenever it detects a trifecta, you can mark it as a false positive. Over time the gateway will be trained to be exactly as permissive as the user wishes with only the rare false positive. You can already do that with the gateway today (you get a web notification when the gateway detects a trifecta and if you click into it, you get taken to a menu to approve/deny it if it occurs in the future). Granted, this can make the gateway overly-permissive but we do have plans on how to improve the granularity of these rules.
Regarding the second point, that is a very interesting topic that we haven't thought about. It would seem that our approach would work for this usecase too, though. Currently, we're defending against the LLM being gullible but gullible and actively malicious are not properties that are too different. It's definitely a topic on our radar now, thanks for bringing it up!
doctoboggan
Wouldn't the LLM running in the gateway also be susceptible to the same jailbreaks?
76SlashDolphin
That's a good question! We do use an LLM to categorise the MCP tools but that is at "add" or "configure" time, not at the time they are called. As such we don't actively run an LLM while the gateway is up, all the rules are already set and requests are blocked based on the hard-set rules. Plus, at this point we don't actually look at the data that is passed around, so even if we change the rules for the trifecta, there's no way for any LLM to be poisoned by a malicious actor feeding bad data.
aaronharnly
"without risk", "solves", and "Guaranteed" are big words – you might want to temper them.
76SlashDolphin
Fair criticism! We wrote the Readme earlier on when we were still ironing out the requirements. I'll fix it up shortly.
noddingham
Agreed. If someone could help answer the question of "how" I'd appreciate it. I'm currently skeptical but not sure I'm knowledgeable enough to prove myself right or wrong.
But, it just seems to me that some of the 'vulnerabilities' are baked in from the beginning, e.g. control and data being in the same channel AFAIK isn't solvable. How is it possible to address that at all? Sure we can do input validation, sanitization, restrict access, etc. ,etc., and a host of other things but at the end of the day isn't it still non-zero chance that something is exploited and we're just playing whack-a-mole? Not to mention I doubt everyone will define things like "private data" and "untrusted" the same. uBlock tells me when a link is on one of it's lists but I still click go ahead anyways.
76SlashDolphin
At least in its current state we just use an LLM to categorise each individual tool. We don't look at the data itself, although we have some ideas of how to improve things, as currently it is very "over-defensive". For example, if you have the filesystem MCP and a web search MCP, open-edison will block if you perform a filesystem read, a web search, and then a filesystem write. Still, if you rarely perform writes open-edison would still be useful for tracking things. The UX is such that after an initial block you can make an exception for the same flow the next time it occurs.
noddingham
Thanks for the follow up. I can see the value in trying to look at the chained read - search - write or similar patterns to alert the user. Awareness of tool activity is definitely helpful.
daveguy
Well, I guess 80-90% protective is better than nothing. Better might be a lock that requires positive confirmation by the user.
warthog
Seen a hack using whatsapp mcp recently - this seems promising
Hi there, me and some friends were inspired by Simon Willison's recent post on the "lethal trifecta" (https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ ) and started building a gateway to defend against it.
The idea: instead of connecting an LLM directly to multiple MCP servers, you point them all through a Gateway.
The Gateway:
- Connects to each MCP server and inspects their tools + requirements
- Classifies tools along the "trifecta" axes (private data access, untrusted content, external comms)
- When all three conditions are about to align in a single session, the Gateway blocks the last step and tells the LLM to show a warning instead.
That way, before anything dangerous can happen, the user is nudged to review the situation in a web dashboard.
We'd love for the HN community to try it out: https://github.com/Edison-Watch/open-edison
Any feedback very welcome - we'll be around in the thread to answer questions.