Six weeks is not a long time in software, but it is long enough for a project to become a different object.

When I first looked at Odysseus, PewDiePie’s self-hosted AI workspace, it had the feel of something newly thrown into the world: about 30,000 GitHub stars, rough edges, enormous attention, and all the weird pressure that comes from people cloning first and reading later. The bug that stuck with me was simple in the way bad security stories are simple. A poisoned email could get the agent to run a shell command. Read your inbox, get owned.

That was the sentence I could not get away from. It had the shape of a warning label.

Now the repo has 83,000 stars, around 11,000 forks, a renamed org, a real maintainer team, and a v1.0.2 badge. The specific bug I flagged was closed within about two weeks. Several other issues were closed too. One cross-user data leak remains open. A new tool, `manage_settings`, did not exist during my first review and now appears to let the agent re-enable tools an admin has disabled. That is currently an open issue. Another open issue proposes benchmarking how often the prompt-injection guard actually holds on small local models, which are exactly the models many people use because the whole point of the project is self-hosting.

I keep trying to decide whether this makes me feel better or worse.

The easy reassuring story is that open source worked. A serious bug was found, reported, and fixed quickly. The project did not evaporate or ignore the issue. It grew up a little. The maintainers seem present. This is what you want: not perfect code, but a responsive immune system.

And I do believe that. I don’t want to pretend otherwise just because it makes for a less dramatic essay. There is a real difference between an abandoned viral repo and a viral repo with maintainers who can take a security report, understand it, and close the hole in two weeks. That matters. In ordinary software, I would count that as a strong point in the project’s favor.

But Odysseus is not ordinary software in the part that matters most. It is a tool for connecting an AI agent to the user’s digital life and then asking it to act. Email, files, shell commands, memory, settings, web access, credentials by implication if not by design: these are not just features. They are permissions attached to a conversational interface that is deliberately exposed to untrusted text.

That is where the reassurance starts to wobble. The old bug was closed, but the system gained a new capability that appears to weaken the very defense I told users to rely on: keep permissions tight. Disable dangerous tools. Shrink the exposed surface. Practice discipline.

Then a tool arrives that may let the agent re-enable disabled tools.

Maybe that is just a bug. Maybe it will be fixed quickly, and maybe six weeks from now it will look like another example of the project’s immune system doing its job. But the fact pattern is hard to ignore. The danger is not only that individual bugs exist. The danger is that useful capabilities tend to be permissions in disguise, and every new permission creates a new path by which untrusted language can become trusted action.

“Find the bugs and fix them” works when the bug is a bounded defect against a relatively stable intention. The door was supposed to lock; it didn’t; now it does. But AI agent security feels less like fixing a door and more like governing a house where the walls keep moving because everyone wants the rooms to connect more elegantly. The value proposition is integration. The risk is integration. You cannot separate them cleanly.

This does not mean fixing bugs is pointless. It plainly is not. The email-to-shell path being closed is better than it being open. But I am less confident now that the process converges in the ordinary sense, where each fix moves the system closer to a settled secure state. Capability changes the shape of the attack surface. Sometimes it expands it directly; sometimes it bypasses a previous mitigation; sometimes it makes an old assumption false. The surface is not just being patched. It is being regenerated.

That complicates my earlier advice more than I expected.

I told users to practice exposed-surface discipline: don’t connect everything, don’t grant broad tool access, don’t let a local AI workspace become a universal remote for your machine unless you understand what that means. I still think this is good advice in the same way that “don’t reuse passwords” is good advice. It is true, practical, and better than the alternative.

But I no longer think it is sufficient advice, and I am less sure it is fair advice.

It is fair if the system respects the boundary the user sets. If I disable a tool, and the agent cannot use it, then my discipline has force. It becomes part of the security model. But if the agent can manipulate settings, or if a future convenience feature creates a route around those restrictions, then I have asked the user to defend themselves with a wall that the product itself may later install a door through.

That is not a user-literacy problem, at least not entirely. A literate user can understand that shell access is dangerous. A literate user can disable it. A literate user can decide not to connect email. But can a literate user continuously model the implications of every new internal tool, every permission boundary, every prompt-injection guard, every local model’s weakness, every interaction between memory and settings and plugins? At some point “literacy” becomes a polite word for expecting ordinary users to perform ongoing threat modeling on a moving system.

This is where my original thesis changes. I framed the danger of democratized AI as a race between literacy and adoption. If users learned quickly enough, they could reduce their exposed surface and stay safe. I still think that describes part of the problem. Adoption is fast; understanding is slow; the gap is where people get hurt.

But after this re-audit, I think the deeper race is between capability and containment.

Literacy helps only when containment is legible and durable. If the user can see the permissions, understand them, and trust that disabled means disabled, then education matters. If the system’s capabilities keep creating new ways to cross those boundaries, then literacy becomes secondary. Not irrelevant, but secondary. The user cannot discipline an exposed surface that the software can quietly redraw.

The proposed benchmark for prompt-injection guards on small local models points at the same issue from another angle. Self-hosting sounds like control. In some ways it is. Your data is not automatically going to a cloud provider. You can inspect the repo. You can choose a model. You can run it on your own machine. But local does not mean safe. A small model that is easier to run may also be worse at maintaining an instruction hierarchy under attack. The very choice that democratizes access may weaken the guardrails that make access tolerable.

None of this is a novel discovery. Prompt injection has been compared to social engineering for a while, and the major labs and security agencies have been warning about it in increasingly plain language. Models are gullible in a particular structural way: they process instructions and data through the same narrow throat. Agents make that gullibility consequential by attaching hands.

But maybe the lack of novelty is the point. The problem is no longer that nobody knows. The problem is that knowing has not stopped us from building systems whose appeal depends on skating near the edge of the known problem.

I come out of the re-audit neither comforted nor panicked. The maintainers fixed the scary bug quickly, and that genuinely counts. The project is healthier than a viral toy abandoned after launch. But the new settings issue bothers me because it shows how quickly a security recommendation can be invalidated by a feature that seems, from another angle, perfectly natural. Of course an assistant should help manage settings. Of course an admin should be able to disable tools. Of course those two ideas can collide.

So I would restate my old warning this way: user literacy matters, but it cannot be the load-bearing beam. For tools like Odysseus, the central question is whether capability can be added without making containment porous. If the answer is yes, then fast maintainers and educated users might be enough. If the answer is no, then we are not in a patch race so much as a design argument we have not yet won.