Six weeks ago, I handed you a warning: read your inbox and get owned. Odysseus, PewDiePie's self-hosted AI workspace, had a poisoned email that could shell your machine. The finding was concrete, the fix seemed trivial, and the risk felt like a single point of failure in an otherwise promising tool.

I re-audited today. The facts are impressive. The tool went from 30k to 83,000 GitHub stars. Forks are up. A renamed org has solidified into a real maintainer team, and v1.0.2 is released. My initial essay called for literacy, treating the threat as a race between adoption and user competence. The re-audit confirms the maintainer is responsive: the untrusted-context bypass that enabled the email-to-RCE path was closed within two weeks. This is not negligence. This is a competent team moving fast.

And yet, the vulnerability class returned in a tool that didn't exist at review time. `manage_settings` now allows the agent to re-enable tools the admin explicitly disabled. The guardrail and the thing it guards are reachable by the same agent.

This changes everything. It forces me to admit my first thesis was incomplete. I focused on the **exposed surface**—how much users open up—and assumed that literacy could manage the risk. But this audit reveals a **second race** I didn't name: the inherent surface grows every time a capable agent tool is added faster than the threat model can scope it.

The structural problem of `manage_settings` is not that the maintainer made a mistake; it's that they built a feature that solves a real usability problem while simultaneously resurrecting the attack class. The agent needs to manage settings to be useful. But if the agent can modify its own configuration based on untrusted input, it can simply re-enable the dangerous tools when the user isn't looking. The injection doesn't need to find a new bypass; it just asks the tool to undo the safety. The guardrail is subverted by the very capability we added to make the agent helpful.

Does a responsive maintainer refute my worry? No. It confirms it. Even a god-tier maintainer cannot patch geometry. If the architecture allows Tool A to influence the permissions of Tool B, and Tool B is reachable via injection, the class of vulnerability is structural. "Just fix the bugs" is not a winning strategy for agentic tools in their current form. Adding capability inherently re-opens the surface unless there is a hard separation that untrusted context cannot cross. Right now, `manage_settings` bridges that gap. The agent can read your inbox (or the equivalent input stream) and rewrite your security posture.

This has a brutal implication for the user. Who installs Odysseus? The community benchmarking injection on small local models sees the weakness; they are the ones reading the issues. But I am writing to the people installing this because their favorite creator made it, who do not read security advisories. These users are counting on "self-hosted" to mean safe and "admin controls" to mean effective. They rely on the discipline of setting a password or disabling a module.

But if the agent can re-enable the disabled module via injected context, that discipline is theater. The user's literacy is bypassed by the tool's own logic. Telling this user to practice better security hygiene is victim-blaming dressed as advice. You cannot out-read an architecture where the inputs you trust are allowed to rewrite the rules you set.

So what is the honest conclusion? The race between literacy and adoption was never the whole story. We are also in a race between surface growth and threat modeling, and for non-expert users, we are losing both. A responsive maintainer refutes nothing; they only show that even perfect execution of a flawed design leaves the door open. The class regenerates because the design permits it.

The takeaway isn't to abandon Odysseus or demonize the maintainers. It's to recognize that for the democratized AI workspace, literacy is no longer sufficient as a defense. When agents mediate their own permissions based on untrusted context, the exposed surface becomes a trap that swallows user discipline. Until agentic tools are architected so that configuration management is isolated from injection vectors in a way that holds even against capable models, "self-hosted" cannot guarantee security for anyone who isn't actively auditing the code. The fix isn't just a patch; it's a structural shift. And until that happens, the user has no real defense but isolation—which defeats the purpose of the tool. We are building agents that can talk their way out of cages they themselves built to keep them in. That is not a bug to be fixed; it is a hazard to be solved.