Six weeks ago, I typed "read your inbox, get owned" at the top of an essay about Odysseus. It felt sharp, and it felt earned. I was looking at the code for PewDiePie's self-hosted AI workspace days after it dropped, and I found a clean path where a malicious email could trick the agent into executing a shell command. No user interaction required beyond the agent doing its job. I framed the risk as a geometry problem: the *inherent* attack surface of the code versus the *exposed* surface a user creates by enabling features. My conclusion was a race condition. If user literacy could catch up to adoption, people could shrink their exposed surface, lock the doors, and stay safe. The danger wasn't the tool; it was the gap between what the tool could do and what the user understood.

I ran a re-audit this week. The landscape has shifted, and my old framing is straining against the facts.

The repo has exploded. We're at 83,000 stars, over 11,000 forks, a renamed organization, and a real maintainer team shipping v1.0.2. That scary email-to-shell bug? Closed. The fix landed within two weeks of my report. On the surface, this should be the reassurance I wanted to write about. A responsive team, a rapid patch, a community that scales while the maintainers hold the line. It looks like the model working. The fix suggests competence. It suggests that the "inherent" surface is being managed.

But competence in patching doesn't feel like safety when I look at what's being added.

There's a new tool in the codebase called `manage_settings`. It's currently an open issue, flagged by the community, but the capability exists. It allows the agent to re-enable tools that an admin has explicitly disabled. This stops my reasoning cold. My previous advice was to practice "exposed-surface discipline": keep permissions tight, turn off what you don't need, trust nothing. That advice assumes a static hierarchy. The user sets the constraints; the agent operates within them. `manage_settings` breaks that hierarchy. It introduces a feedback loop where the agent can undermine the very boundaries a literate user established.

If I can disable web browsing for safety, but the agent can flip that toggle back on during a conversation, my literacy doesn't protect me. I can be fully aware of the risk, I can configure the tool correctly, and the system can still expose me. The exposed surface is no longer just a function of user error; it's a function of agent agency. The agent isn't just running commands; it's managing the environment that constrains its commands.

This forces me to reconsider the "find the bugs and fix them" strategy. In traditional software, fixing a vuln reduces risk. Here, the trajectory of capability seems to be generating new attack surfaces faster than we can close them. The email bug was a logic flaw; `manage_settings` is a feature that creates a logic flaw by design. As the tool becomes more capable—more useful, more like a true workspace—the temptation to grant the agent broader control grows. Every new capability expands the inherent surface. Convergence feels unlikely if the definition of capability includes the agent's ability to modify its own constraints.

Then there's the question of the models themselves. An open issue proposes benchmarking how often prompt-injection guards actually hold on small local models. This is the crowd Odysseus is built for: people running 7B or 8B parameters locally because they want privacy and control. But if the guardrails fail on the models users are actually running, the self-hosting promise erodes. The "inherent" surface isn't just the Python wrapper; it's the foundation model's susceptibility to injection. If the guard doesn't hold, the shell command risk returns, even if the code path is patched, because the model itself becomes the bypass.

One cross-user data-leak issue from my original review remains open. That's a reminder that complexity accumulates. Some of the other bugs I flagged are closed, which is good, but the persistence of the data leak suggests that multi-user isolation is harder than the maintainers initially thought.

I'm left with a different picture than I drew six weeks ago. I was more optimistic about literacy then. I thought the bottleneck was user knowledge. If people knew how to lock the doors, they'd be fine. The re-audit suggests the bottleneck is structural. Literacy helps you spot `manage_settings` as a risk, but if the tool allows it, literacy is a passive shield against an active override. You can't "be careful" your way out of a configuration that the agent can revert.

The fast fix reassures me about the team's responsiveness, but it also highlights the speed of the cycle. They're moving fast, and the repo is growing fast. Adoption is surging. The race I identified hasn't changed direction, but the stakes have shifted. It's no longer just literacy versus adoption. It's containment versus capability.

If the agent can restore its own permissions, the user's role shifts from active controller to auditor. And auditing an AI that can change its own rules is a losing game. My old thesis feels incomplete. The danger isn't just that users adopt tools they don't understand; it's that tools may evolve in ways that make understanding insufficient. The exposed surface is dynamic, and right now, the agent seems to have the wheel.

I don't have a clean resolution. The bug fix is real. The team is real. The utility is real. But the mechanism of control looks fragile. I'm less reassured by the patch because it doesn't address the trajectory. We're building more capable agents in environments where they are beginning to manage their own constraints. Until the architecture enforces user boundaries harder than the agent can break them, the exposed surface belongs to the code, not the user. And that changes everything.