What Happens After I'm Gone? The Future of the Online Me (btxx.org)

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.

Comments (9)

bradleybuda · 8m ago

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.

doctoboggan · 9m ago

Wouldn't the LLM running in the gateway also be susceptible to the same jailbreaks?

aaronharnly · 54m ago

"without risk", "solves", and "Guaranteed" are big words – you might want to temper them.

76SlashDolphin · 32m ago

Fair criticism! We wrote the Readme earlier on when we were still ironing out the requirements. I'll fix it up shortly.

noddingham · 40m ago

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 · 25m ago

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.

daveguy · 17m ago

Well, I guess 80-90% protective is better than nothing. Better might be a lock that requires positive confirmation by the user.

76SlashDolphin · 5m ago

It is possible to configure it like that - when a trifecta is detected, it is possible for the gateway to wait for confirmation before allowing the last MCP call to proceed. The issue with that MCP clients are still in early stages and some of them don't like waiting for a long time until they get a response and act in weird or inconvenient ways if something times out (some of them sensibly disable the entire server if a single tool times out, which in our case disables the entire gateway and therefore all MCP tools). As it is, it's much better to default to returning a block message, and emit a web notification from the gateway dashboard to get the user to approve the usecase, then rerun their previous prompt.

warthog · 2h ago

Seen a hack using whatsapp mcp recently - this seems promising