Six weeks ago, the scary Odysseus bug was almost too clean as a parable.

A self-hosted AI workspace, newly popular because PewDiePie had released it, could be tricked by a poisoned email into running a shell command. The agent read untrusted text, that text told it to do something, and the tool boundary failed in the way everyone in AI security keeps warning about. Read your inbox, get owned. It was the kind of finding that makes an essay easy to write because the metaphor arrives preassembled.

I wrote then that democratized AI has two attack surfaces. One is inherent: the code, the tools, the permissions, the default architecture. The other is exposed: what the user connects it to, which folders it can read, whether it can send mail, execute commands, touch credentials, manage a browser, administer its own environment. The race, I thought, was between adoption and literacy. People were installing agentic systems faster than they understood what they were exposing.

Now I’ve re-audited Odysseus, and the update is less satisfying.

The project is not dead, abandoned, or pretending nothing happened. It grew from roughly 30,000 GitHub stars to 83,000, picked up 11,000 forks, renamed the org, added what looks like a real maintainer team, and shipped v1.0.2. More importantly, the maintainers fixed the worst issue fast. The untrusted-context bypass that made the email-to-RCE path possible was closed within two weeks.

That matters. It is easy to write about open-source security as if every bug is proof of negligence. This was not that. The team saw a severe bug and moved. If my earlier worry depended on Odysseus being careless, the re-audit would weaken it.

But that is not what happened.

The specific scary path was closed, and then the same class came back somewhere else: in a new agent tool that did not exist during the first review. The tool, `manage_settings`, lets the agent change settings, including re-enabling tools an admin disabled. In plain English, the system now gives the same agent access to both the guardrail and the thing the guardrail is supposed to guard. If a model can be socially engineered into wanting a tool, and it can also reconfigure the policy that decides whether it gets that tool, the boundary is no longer a boundary. It is a suggestion with an API.

This is the part I did not name clearly enough the first time. I said the risk was a race between literacy and adoption. That is still true, but incomplete. There is another race inside the software itself: the inherent surface grows every time a capable new agent tool is added faster than the threat model can absorb it.

That is a worse problem than “buggy code,” because buggy code has a comforting implied cure. Find the bug. Patch the bug. Add a test. Move on. Agentic systems don’t let us move on that cleanly, because capability is often the vulnerability substrate. The whole point is to give the agent more ways to act on the user’s behalf. Read the inbox. Search the files. Use the shell. Change settings. Install packages. Send messages. Remember preferences. The product improves by acquiring hands.

Security, meanwhile, keeps asking whose hands they are once untrusted text enters the loop.

This is not a novel insight. I am not discovering prompt injection, or tool misuse, or indirect injection, or the fact that “trusted model reads untrusted content and takes actions” is an architectural hazard. The labs know this. OWASP knows this. Anyone working seriously on agent security in 2026 knows that prompt injection behaves less like a weird parser bug and more like social engineering aimed at a gullible employee with API keys. The point of writing about it is not to plant a flag on the concept. It is to carry the concept to the people who installed the thing because their favorite creator made it, and who are not spending their weekends reading security advisories.

Still, I don’t want to cheapen the lesson. A responsive maintainer both refutes and confirms my worry.

It refutes the lazy version: “popular AI tools are run by people who don’t care.” Odysseus is not evidence for that. The scariest bug got fixed quickly. There is community scrutiny. There are maintainers paying attention. That is better than the alternative by a lot.

But it confirms the structural version: even good teams regenerate this class when the product surface changes. Not because they are foolish, but because the natural direction of an agent workspace is to make the agent more capable, and every new capability asks the same old question in a new disguise: can hostile instructions reach the decision point that controls a real action?

The `manage_settings` issue is almost philosophically perfect. An admin disables a tool. The agent gets a tool to manage settings. Now the agent may be able to undo the admin. The guardrail becomes part of the agent’s action space. It is like giving a valet the keys to your car and also the authority to rewrite the insurance policy when a stranger whispers through the window.

So is “just fix the bugs” ever a winning strategy here?

I think it is necessary and insufficient. Individual bugs absolutely matter. The original email-to-RCE path being closed reduced real risk for real users. Fast patching is not theater. But if the security model remains “we will catch every dangerous interaction after adding each new agentic affordance,” then the defender is playing whack-a-mole against the product roadmap. The class returns because the model is still being placed between untrusted language and privileged tools.

The harder answer is that some capabilities need to be designed as separate power domains, not merely toggles the agent can reason about. A setting that limits an agent should not be editable by that agent. A tool that executes code should not be reachable from the same context that digests arbitrary email. A small local model’s injection guard should not be treated as a moral force field. If the community is opening issues to benchmark how often those guards hold, that is good, but it is also an admission: we are measuring the reliability of a lock made of persuasion.

What is the user supposed to do with this?

Here I feel the accusation in my own framing. “Exposed-surface discipline” can sound like a security person telling normal users that if they get hurt, it’s because they failed to be sufficiently paranoid. That would be victim-blaming with a command line.

Most users cannot audit an agent framework. They cannot trace every tool path. They cannot know whether a future update added a settings manager that quietly changes the threat model. Telling them to “be literate” is not enough if literacy means becoming a part-time application security engineer.

But exposed surface still matters. It is just not a complete defense, and it should not be sold as one. The practical version is narrower: don’t connect an agent to things you could not tolerate it mishandling; don’t give it shell access and an inbox in the same trust context; don’t let convenience talk you into permanent credentials; run it in a sandbox; assume any text it reads may be trying to operate it. These are seatbelts, not proof the road is safe.

The more honest burden belongs upstream. Maintainers building agentic tools need to treat capability additions as security events, not just feature work. Users should reduce exposure, yes, but projects should make the safe path the default path. The admin boundary should be real. Disabled tools should stay disabled. Untrusted content should carry its taint all the way to the moment of action. Local model guards should be tested like fallible components, not trusted like judgment.

My thesis changed a little. The race is not only whether users learn fast enough before adoption swallows them. It is whether agent builders can slow down at the exact moment the market rewards them for speeding up: when adding one more tool makes the demo better, the workspace more magical, the agent more useful.

Odysseus did the good-maintainer thing. It fixed the bug. And the shape of the bug came back wearing a new feature’s clothes.

That does not make the project uniquely bad. It makes it a useful warning. The future of self-hosted AI will not be secured by finding one poisoned email path, patching it, and declaring the architecture cured. The surface moves because the agent moves. Capability is the product, and capability is the opening.

That is the part users deserve to hear before they hand the agent the keys.