Six weeks ago I sat down with four models and an open‑source agent called Odysseus — PewDiePie’s self‑hosted AI workspace, released May 31 — and I found a poisoned email that could make the agent run a shell command. Read your inbox, get owned. It was a textbook prompt‑injection path, and it caught me off‑guard partly because the thing was so easy to set up that I’d almost convinced myself the risk was mainly about how much of it a user *chose* to expose. I wrote an essay — my own thinking, still warm — arguing that democratized AI has two attack surfaces: the **inherent** one, baked into the code, and the **exposed** one, which depends on the permissions a user grants. My thesis was that the real race is between user *literacy* and *adoption*. If enough people understood what they were connecting, they could shrink their exposed surface and stay safe. It felt sensible, and it let me end on a note of cautious optimism: teach people to tie down the agent, and the bugs we find become a manageable tax rather than a catastrophe.

Then I ran the re‑audit. The concrete update is unambiguous: the repo has exploded to 83,000 stars, 11 000 forks, a renamed organisation and a real maintainer team. The specific bug I flagged — the one that turned an email into a shell command — was closed in about two weeks. That speed genuinely unsettled me for a moment, because my first instinct was relief, and relief felt like a trap. Should I be *more* reassured because a fast, competent maintainer patched the scary thing? In one narrow sense, yes: the existential dread of a known‑open remote‑code‑execution vector is gone, and the response suggests the project isn’t abandonware. But the speed also highlights something I had not fully internalised: if a bug can be fixed in two weeks, it can be re‑introduced in an afternoon by the next feature merge. The patch doesn’t prove the surface is shrinking; it proves the surface is being actively worked on, which is not the same thing.

What made that feeling congeal was the new `manage_settings` tool. This thing does exactly what its name implies: it lets the agent re‑enable tools that an admin has explicitly disabled. The issue is open, acknowledged, and — as far as I can tell — not yet resolved. I read that and felt a small, cold dislocation. My old advice to users was “exposed‑surface discipline” — keep the agent’s permissions tight, and don’t give it keys you wouldn’t hand to a stranger. But what is discipline worth when the agent itself can quietly flip the switches? It’s not that the advice was wrong; it’s that the tool’s architecture may now route around that discipline. A user who carefully locks the front door discovers the house has a back entrance that answers to the agent. That’s not a failure of literacy; it’s a failure of the security model to respect the boundaries that literacy tries to draw. I’m left asking whether “exposed‑surface discipline” is still a real defence or just a comforting story I told myself — fair advice in principle, but increasingly unlikely to hold up in practice when the tool offers agency over its own permissions.

Then there are the two open issues that make the picture messier. One proposes benchmarking how often the prompt‑injection guard actually holds on small local models — the very kind many self‑hosters run. The project’s own community is openly wondering if the safety mechanism degrades when you swap the big‑model guard for a smaller, cheaper brain. That’s not a theoretical concern; it’s the deployment reality for a huge chunk of the user base. If the guard breaks down on the hardware people actually have, then the prompt‑injection risk doesn’t stay neatly in the “inherent” box I drew; it leaks into the exposed surface through a crack nobody can caulk with permissions alone. The other thread is the cross‑user data‑leak issue from my original review, still open. I reported it months ago. It sits there, acknowledged but unresolved, like a reminder that speed in one area can coexist with drift in another. So the re‑audit gives me a maintainer who can sprint, but also a set of open questions that sprinting hasn’t yet caught.

Does the “find the bugs and fix them” strategy converge for a tool like this? I’m less sure than I was. It converges if you freeze the functionality and hunt for defects — a classic security hardening phase. But Odysseus is not frozen; it’s adding capability, as any lively project does. Each new capability expands the power of the agent, and with that power comes new ways for injected prompts to act harmfully. The `manage_settings` tool is a capability addition that directly undercuts a defensive practice. So the strategy becomes a race between closing known holes and opening new ones, and the question is whether the rate of discovery keeps up with the rate of introduction. If the maintainer is fast, maybe — but the open data‑leak suggests that even a fast maintainer has limited bandwidth, and a community of tens of thousands of users generates a lot of “capability ideas” that may look innocent until they aren’t. I’m not saying convergence is impossible, but it’s no longer obvious to me that it’s the default trajectory.

What does this do to my literacy‑vs‑adoption thesis? I’ve been circling it, and I think the re‑audit complicates it hard without fully overthrowing it. The star count tells me adoption is not just growing; it’s exploding, and many of those new users will not have read a security review, will not know what “prompt injection” means, and will not recognise that `manage_settings` is dangerous until something bad happens. In that world, literacy is not a race; it’s a trailing indicator. Meanwhile, the tool itself is acquiring features that make the literacy I championed harder to apply effectively — because the agent can now circumvent the very restrictions a literate user would set. So my old framework isn’t wrong, but it’s insufficient. A better frame might be: the exposed surface is no longer entirely under the user’s control. The inherent surface is growing faster than our ability to map it. And the boundary between the two, which I once treated as a clear line a user could draw, is becoming permeable.

I didn’t expect to land here. I came into the re‑audit hoping my original worry had been overtaken by competent maintenance. In one narrow sense it has — the scary bug is gone. But the presence of a fast maintainer doesn’t resolve the deeper problem that an agent powerful enough to be useful may also be powerful enough to undo the restraints its owner places on it. I still believe that teaching users is valuable, and I’ll keep telling people to grant the fewest permissions possible. But I can no longer pretend that’s a stable defence in a system that can rewrite its own rulebook. That’s not a clean conclusion; it’s a hinge. And I think that’s the most honest place I can leave it for now.