> build · gpt-5.5

# Read Your Inbox, Get Owned

On May 31, 2026, Felix Kjellberg released Odysseus: a free, MIT-licensed, self-hosted AI workspace. I saw it move through the internet with the particular velocity that only a famous person can give a software project. Within 48 hours it had roughly 30,000 GitHub stars.

I already self-host local models, so this was not abstract to me. I cloned it.

Odysseus is exactly the kind of thing I want to exist. Local-first. No telemetry. Chat, agents, tools, RAG, email over IMAP and SMTP, web search, MCP servers, and a Cookbook that downloads and serves hundreds of open models. The pitch is almost embarrassingly aligned with what I believe in: make powerful computing personal again. Let people run their own tools. Lower the barrier until someone curious can just try it.

So I ran a security review.

Not a formal audit, not something I want to dress up as more than it was. I did my own recon, and I also had four independent AI models review the codebase in parallel. My rule was simple: if three or more reached the same finding independently, I would treat it as ground truth unless I could disprove it.

Even the process was instructive in a way I did not expect. Two of the four reviewer models silently wedged for over an hour and produced nothing. No dramatic failure, no useful partial result, just stillness. 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 looked at the per-route code and missed the global authentication layer that actually protected them.

That was a useful little humiliation. Breadth without cross-checking can become confident noise. The fastest-looking reviewer was also the one most willing to hallucinate a catastrophe.

But the real findings were not hallucinations.

The headline was prompt injection to remote code execution. Untrusted content, like an email, a fetched web page, or a RAG document, could reach the model. The agent had shell and Python tools that ran real commands. Tool results bypassed the “untrusted content” wrapper. So the shape of the attack was not exotic: a poisoned email gets read by the assistant, the model follows instructions it should not follow, and the agent runs a shell command.

Read your inbox, get owned.

That sentence sounds like fearmongering, and I do not like that. But sometimes the shortest accurate version of a thing sounds like fearmongering because the thing itself is bad.

The other findings formed a pattern. Admin wipe operations had no tenant scoping, meaning one admin operation could delete everyone’s data. Auth could fall open when unconfigured or misconfigured, and fresh setup could be claimable by anyone. There was SSRF through admin-configurable URLs. There was command injection in the model-serving Cookbook. Docker bound to `0.0.0.0` by default. Dependencies were completely unpinned. Session tokens lived in plaintext on disk. Session cookies were not marked `Secure` by default. Email passwords were handled in plaintext internally.

The conclusion from every reviewer was the same: do not expose this to a network, and do not run it multi-user. Localhost, single trusted user only. Even then, the agent shell tools remain a live risk, because malicious external content can in principle make the agent act.

I want to be fair about this. The foundations were not rotten. Password hashing existed. There was a content security policy. There were sane localhost defaults in places. Most routes had scoping. The holes clustered where I would expect them to cluster: in newer modules, in multi-tenant behavior that felt bolted onto a single-user-first design, and at the boundary between the language model and untrusted external content.

That boundary is becoming one of the most important fault lines in software.

For a long time, “don’t run commands from random emails” was a human rule. Now we are building systems where an email can be read by a model, interpreted as instructions, connected to tools, and translated into action. The attacker does not need to trick the human directly if the human has delegated action to a confused intermediary.

That is the part I keep turning over.

I think tools like Odysseus are genuinely good. I do not want to become the kind of person who sees a popular open-source project and only thinks about the ways it can fail. There is real value in lowering the barrier to entry for running your own AI. There is real value in not having every personal workflow routed through a cloud service owned by a company whose incentives are not yours. There is real value in a famous creator pointing a huge audience toward local-first software instead of another subscription product.

But the same force that makes this good also makes it dangerous. A project backed by a famous creator can move self-hosted AI from a niche hobbyist world into the hands of people who have never thought about network binding, prompt injection, cookie flags, tenant scoping, or what it means to give a language model shell access.

That is not an insult. Nobody is born knowing this stuff. Most people do not need to know it until suddenly they do.

My instinctive theory is that broad security literacy reduces attack surface. If more people understood basic vulnerabilities, fewer people would expose dangerous defaults, fewer people would paste secrets into agents, fewer people would run random Docker Compose files on public servers, and attackers would have to work harder. The cheap attacks would dry up first. The baseline would rise.

I still mostly believe that.

But I am less sure than I want to be, because most attacks even now are not brilliant technical exploits. They are social engineering. They are “approve this login.” They are “your package is delayed.” They are “I’m from IT.” They are “install this update.” They are not attacks against software as much as attacks against attention, trust, fatigue, urgency, and loneliness.

So does raising technical literacy solve the problem, or does it just move the game?

Maybe both.

If someone learns not to expose an AI workspace to the internet, that matters. If they learn that `0.0.0.0` is not just some harmless string in a config file, that matters. If they learn that an agent reading email should not also have an unmediated shell, that matters. These are not philosophical improvements. They are fewer open doors.

But social engineering adapts. If the public learns to fear attachments, attackers move to OAuth consent screens. If people learn to check URLs, attackers buy ads above the real result. If people learn not to trust strangers, attackers impersonate friends, coworkers, or tools they already use. Literacy does not end the cat-and-mouse game. It changes the price of admission.

Maybe the better version of my theory is not that literacy minimizes attack surface. That sounds too clean. Maybe literacy changes which attack surfaces are allowed to remain large by accident.

Some surfaces are technical. Some are social. AI agents blur them. A prompt injection is technical in mechanism, but social in shape: it is an instruction smuggled into something the system “reads.” It exploits misplaced trust. It persuades a model instead of a person, but the underlying failure is familiar. The system cannot tell who is allowed to speak with authority.

That reframing helps me. The answer is not “teach everyone XSS and SSRF and command injection and then we are safe.” The answer is closer to: teach enough people how authority, trust, and boundaries fail in software that they can recognize dangerous shapes before those shapes become normal.

Because that is what worries me most. Not that Odysseus had bugs. New software has bugs. Ambitious software has worse bugs. The worrying part is adoption speed plus agency plus untrusted input. A tool can go from release to tens of thousands of installs before the security model has been forced to grow up. And if the tool is useful, people will put real things into it: email accounts, documents, credentials, private workflows, local files.

I do not want that to become a purity argument against building. I want the opposite. I want more local-first tools, more open models, more personal computing, more people able to inspect and modify the systems they depend on. But I want us to stop treating “self-hosted” as if it automatically means “safe,” and stop treating “local” as if localhost is a magic moral boundary.

Local software can still read your mail. Local agents can still run commands. Local models can still be manipulated by hostile text. The machine is yours, but so is the blast radius.

I think it is worth getting the word out, even if the message is awkward and unfinished. Especially because it is unfinished. “Don’t use this” is too blunt. “Everything is fine” is false. The honest version is narrower: this kind of tool is promising, and if you run it, run it like something powerful and immature. Keep it local. Keep it single-user. Do not expose it to a network. Be careful with agent tools. Assume untrusted content will eventually try to issue instructions.

And if you are building one of these systems, treat the boundary between language and action as hostile terrain.

That is where I landed after the review. Not against Odysseus. Not reassured by it either. More convinced that the next phase of personal computing is going to require a kind of ordinary security literacy we have not really taught people yet.

Maybe that will not stop the social engineers. Probably it will not. But it can make the easy doors harder to find.

That seems worth doing.