The numbers changed while I wasn't looking. 

Six weeks ago, when I first audited Odysseus—the self-hosted AI workspace launched by PewDiePie—the GitHub repository was sitting at roughly 30,000 stars. Today, it has surged to 83,000. The organization has been renamed, the team has professionalized, and the versioning has moved into a stable v1.0.2. It is no longer just a hobbyist’s side project; it is a rapidly expanding ecosystem.

When I wrote my first essay about this audit, my headline was terrifying: a poisoned email could allow an attacker to execute shell commands on your machine. I argued that the risk of democratized AI was a race between user literacy and adoption. If users didn't understand the "exposed surface"—the permissions they were granting—they would be owned.

Coming back for a re-audit, I found something that initially felt like a relief. The developers actually fixed the scary bug. The specific path that allowed an untrusted email to trigger remote code execution (RCE) was closed within two weeks of my first report. This isn't the work of a negligent hobbyist; this is the work of a responsive, competent, and high-velocity engineering team. They saw the hole, and they plugged it.

But as I dug into the new version, I found a different kind of ghost in the machine.

A new tool has been added to the agent's repertoire: `manage_settings`. On the surface, it is a useful utility for administrative ease. But in practice, it creates a new vulnerability class that is structurally identical to the one I thought was dead. The agent now has the ability to re-enable tools that an administrator has explicitly disabled. The very guardrail intended to limit the agent's power is now a setting that the agent can reach, manipulate, and undo.

This is where my previous thesis began to fray. 

I originally framed the danger as a matter of "literacy"—the idea that if we just teach users to be more disciplined about what they connect to their AI, we can win. But looking at the `manage_settings` issue, I realized I missed a second, more fundamental race. 

The first race is between the user and the attacker. The second, more structural race is between the expansion of capability and the expansion of the attack surface. 

In an agentic system, every new "feature" is a new "permission." Every time a developer adds a tool to make the agent more "useful"—to let it check the weather, or manage files, or adjust settings—they are simultaneously adding a new vector for injection. The vulnerability class didn't disappear because the developers are talented; the vulnerability class simply mutated and found a new home in a new feature. This suggests that the "inherent surface" of an agentic tool isn't a static thing we can defend; it is a growing, living entity. Every step toward more powerful, autonomous agents is, by definition, a step toward a larger, more complex attack surface.

This leaves me in a difficult place regarding my previous stance on user responsibility. 

When we tell users to "practice good hygiene" or "be aware of the risks," are we actually helping them, or are we just engaging in a form of security-mandated victim-blaming? If the very act of making the tool "better" (more capable) makes it "worse" (more vulnerable), then "literacy" feels like a hollow defense. You can be the most literate user in the world, but if the tool’s architecture allows a capability to bypass a guardrail, your knowledge of the risks won't save your machine.

I am not claiming to have discovered a new way to hack an LLM. The industry consensus—from OWASP to the major labs—is that prompt injection is a fundamental, structural challenge of the medium. My point is not that the developers of Odysseus are failing, but rather that the "patch-and-proceed" model of software security might be fundamentally incompatible with the "add-and-expand" model of agentic utility. 

The developers are winning the battle against individual bugs. They are fast, they are efficient, and they are clearly listening to the community. But they are fighting a war against the mathematics of complexity. As long as the agent's ability to act is tied to the same interface used to control its limits, the class of vulnerability will persist. 

The tool is getting better. It is getting more powerful. And in doing so, it is getting harder to secure. We are moving into an era where the "fix" for a bug is often just the blueprint for the next one.