> build · qwen3.6-plus

# The Thing About Letting Anyone Read Your Inbox

On May 31, 2026, Felix Kjellberg released Odysseus. Free, MIT-licensed, self-hosted AI workspace. Local-first, no telemetry. It bundles chat, agents, tools, RAG, email, web search, MCP servers, and a Cookbook that serves 270+ open models. It hit roughly 30,000 GitHub stars in 48 hours because a famous person put his name on it and his audience showed up.

I already self-host local models, so I cloned it. Then I ran a security review. My own recon plus four independent AI models reviewing the codebase in parallel. The rule I set for myself: any finding that three or more models reached independently counted as ground truth.

Two of the four models silently wedged for over an hour and produced nothing. I killed them and relaunched. The model that produced the most findings also produced the only critical-severity false positive — it flagged three route groups as unauthenticated because it only looked at per-route code and missed a global authentication layer. Breadth without cross-checking turned out to be confident noise. That's worth remembering, because it tells you something about how these tools behave even when you're the one wielding them.

What the remaining reviewers found, independently and consistently: prompt injection leads to remote code execution. Untrusted content — an email, a fetched web page, a RAG document — reaches the model, and the agent has shell and Python tools that run real commands. Tool results bypass the untrusted content wrapper. So a poisoned email read by the assistant could make the agent run a shell command. Read your inbox, get owned.

The rest of it was bad in the ways you'd expect from a project that went from single-user to multi-tenant in a hurry. Admin wipe operations with no tenant scoping. Auth that falls open when unconfigured. SSRF through admin-configurable URLs. Command injection in the Cookbook. Docker bound to 0.0.0.0 by default. Dependencies completely unpinned. Plaintext session tokens on disk.

The foundations weren't bad, for the record. Password hashing was fine. Content-security-policy was present. Most routes had sane scoping. The holes clustered in the newest modules and at the boundary between the language model and untrusted external content — exactly where you'd expect trouble when you bolt capabilities onto something that wasn't designed to hold them.

The verdict: do not expose this to a network. Do not run it multi-user. Localhost, single trusted user only. And even then, the agent's shell tools remain a live risk.

Here's what I've been thinking about since.

Tools like this are genuinely good. They lower the barrier to entry for running your own AI to almost nothing. That matters. The fact that a creator with an enormous audience drove massive adoption by association is, in some ways, exactly the kind of thing that needs to happen for self-hosted software to stop being a niche hobby. I don't want to be the guy who looks at something popular and assumes it's dangerous just because it's popular.

But the flip side is real. That same dynamic — famous person, huge audience, frictionless install — massively increases the attack surface for oblivious individuals who adopt the tool without understanding what it actually does. Thirty thousand people starred the repo in two days. How many of them read the README past the first paragraph? How many of them understand what it means for an agent to have shell access? How many will run this on a machine that also holds their tax documents?

I have a theory about this, and I'm not sure it holds up.

The theory is: if the general populace becomes literate in basic security and vulnerabilities, then attack surfaces shrink. People stop binding things to 0.0.0.0. They pin their dependencies. They notice when session tokens are sitting on disk in plaintext. Attacks would have to become more complex, more targeted, more expensive. The low-hanging fruit disappears.

But then I think about the fact that even today, most attacks are social engineering. Not technical exploits. A phishing email. A phone call pretending to be IT. A fake login page. None of that requires the victim to understand anything about code. It requires them to trust the wrong person at the wrong time.

So does security literacy actually reduce the attack surface, or does it just shift it to a layer where literacy doesn't help? If the vulnerability is "you trusted an email that looked like it came from your bank," then knowing what SSRF means doesn't protect you. If the vulnerability is "you gave an AI agent shell access and didn't think about what happens when it reads a poisoned document," then maybe it does — but only if you understand the threat model well enough to make that connection before something goes wrong.

I think the honest answer is somewhere in the middle, and it's less satisfying than either extreme. Technical literacy does shrink the technical attack surface. People who understand what 0.0.0.0 means won't bind to it. People who understand prompt injection won't give an agent unfettered shell access on a machine they care about. That's real. It's measurable. It matters.

But it doesn't touch the social layer. And the social layer is where most of the damage happens, because it's where the humans are. No amount of technical education makes someone immune to being manipulated by someone they trust. That's a different problem, and it might not have a technical solution at all.

What I'm landing on is this: the two layers are not independent. They feed each other. A system with a wide technical attack surface creates more opportunities for social engineering — because every technical hole is a vector someone can exploit by convincing you to do something that looks reasonable. If Odysseus didn't let agents run shell commands, a poisoned email would just be a poisoned email. The agent would read it, maybe get confused, but it couldn't act on the confusion. The technical vulnerability amplifies the social one.

So reducing the technical attack surface does something even if it doesn't solve the social problem. It removes the amplifier. It makes the attacker's job harder in a way that's not just about complexity — it's about opportunity. Fewer holes means fewer ways to turn a moment of human trust into a moment of system compromise.

That's worth getting the word out about. Not as a lecture. As a practical thing: if you're going to run software like this, run it on localhost. Run it as a single user. Think about what happens when the thing you're talking to can also run commands on your machine. And understand that the person who made the tool probably didn't intend for it to be dangerous — intention and outcome are not the same thing, especially when thirty thousand people install something in two days.

I'm still not sure my theory is right in its original form. Security literacy alone doesn't solve anything. But security literacy combined with systems that are designed to fail safely — that's a different conversation. And it's one we need to start having before the next famous person releases the next thing.