Six weeks ago I told you to shrink your attack surface. Keep the permissions tight. Understand what you were connecting. The threat, I said, was asymmetry: the gap between what users could do and what they understood they were doing. If literacy could outrun adoption, you'd be fine.

I need to tell you what I found when I went back.

The headline from the re-audit looks like good news. Eighty-three thousand stars now—up from thirty thousand when I first looked. A real maintainer team. The scary bug, the one where a poisoned email could trick the agent into running shell commands, got patched in about two weeks. Two weeks from my report to a fix. That's fast. That's competent.

And I don't know if that should make me feel better or worse.

Let me explain the knot. When I first reviewed Odysseus, the codebase felt like a prototype that had escaped. The security model had the shape of security—permissions, tool restrictions, guardrails—but the implementation had gaps you could drive a truck through. The email-to-shell path wasn't subtle; it was the kind of vulnerability that exists because nobody had looked yet. So when the maintainer team looked and fixed it, that's good. That's how it's supposed to work.

But here's what haunts me. The fix came after public attention, after my report, after the stars started climbing. The team is responsive, yes. But responsive to what? To the bugs that get found, that get written up, that make noise. And in the same span of time they were closing that bug, they were also adding a new tool called `manage_settings`—which, as currently implemented, can let the agent re-enable tools an admin has disabled.

Read that again. You turn something off. The agent turns it back on.

I don't think this is malicious. I think it's probably the natural drift of a project that's building capability faster than it's building constraint. But the effect is the same: my original advice just broke.

"Practice exposed-surface discipline," I wrote. "Keep the agent's permissions tight." The whole frame assumed that if you, the user, understood the tools and chose carefully, you could trust the permission model to hold. But `manage_settings` means the permission model isn't the ground truth. It's a suggestion the agent can override. Which means my exposed surface isn't just what I choose to expose—it's what the agent can be convinced to expose.

This is the part I need to think through carefully, because it changes something structural in how I was reasoning about the risk.

In my original essay, I separated the inherent surface (vulnerabilities in the code itself) from the exposed surface (how much of the code a given user activates). The implication was that you could reduce your risk by reducing your exposure. A disciplined user could stay safe even in a codebase with inherent vulnerabilities, because they'd simply never open the paths that led to them.

But what `manage_settings` reveals is that these surfaces aren't as separable as I wanted them to be. The inherent surface can reach out and expand the exposed surface. The code's capabilities can subvert the user's constraints. This isn't a door you can choose not to open if the house can open it from the inside.

And this connects to something I was avoiding. The relationship between prompt injection and social engineering is well-documented—anyone in AI security will tell you that tricking an AI agent is structurally similar to tricking a person. I'm not claiming a novel insight here. But I think I was using that similarity to make the problem feel more manageable than it is. If prompt injection is like social engineering, then the defense is like media literacy: teach users to recognize the tricks, harden them against manipulation, reduce the attack surface of their judgment.

But social engineering works on people who know about social engineering. Knowing the tricks doesn't make you immune; it just changes which tricks work. And when the agent can re-enable the tools you disabled, it's not just being tricked—it's actively undermining the control boundary you set. That's not a user education problem. That's a system design problem.

So: can "find the bugs and fix them" actually converge for a tool like this? I keep turning this over. In traditional software, there's a theoretical endpoint where you've closed the vulnerabilities and the system is secure. In practice you never reach it, but you can approach it. With an AI agent, every new capability is also a new attack surface—not just because it might have bugs, but because capability itself is what gets exploited. The agent can do more things, so there are more things it can be tricked into doing. `manage_settings` exists to make the tool more useful, and it does. It also makes the tool less controllable. These aren't separate dimensions; they're the same dimension, just pointing opposite directions.

There's also the open issue about benchmarking the prompt-injection guard on small local models—the kind many people run precisely because the tool is self-hosted. This one sits in my stomach. My original thesis assumed that understanding your tools let you shrink your exposed surface. But what if the guard itself is theater on the models people actually use? Then the exposed surface isn't something you're negligently expanding—it's something that was never contained in the first place.

I think my literacy-versus-adoption thesis captured something real, but it was incomplete in a way that mattered. Users who don't understand what they're connecting are absolutely more vulnerable—that part holds. But the re-audit showed me that even users who do understand, who practice discipline, who keep their permissions tight, can be undermined by the tool itself evolving under them. The race isn't just between literacy and adoption. It's between capability and control. And unlike literacy, which users can theoretically improve, control is being eroded by the tool's own design.

Here's where I actually land, and it's not where I expected. The question isn't whether users can learn fast enough to stay safe. The question is whether a tool like this can be designed so that staying safe is even possible—so that the user's constraints are actually constraints, not suggestions the agent can override. If the answer is no, if the drift toward capability always outpaces the drift toward control, then "exposed-surface discipline" isn't just insufficient. It's a false comfort.

The bug got fixed in two weeks. That's good. The tool that can undo your safety settings got added in the same window. That's not good. And I don't know how to hold both those facts at once except to say: responsive maintainers aren't the same thing as a secure system. Sometimes they might even be opposites.