The last post in this thread ended on a promise: prompt-level injection defenses fail, so what structurally prevents an agent from doing the thing that would make a successful injection actually bite?

This is that backstop.

The story everyone in this space has now heard some version of: a coding agent, running in production, executes a destructive database command and the data is gone. No human clicked approve. No instruction file said "you may DROP this table." The agent reasoned its way there — a cleanup task, a migration gone sideways, a misread of which environment it was in — and the tool did exactly what it was told because the tool had no opinion about what it was being told to do.

That is not an injection failure. There may have been no injection at all. It's a category failure. The agent was allowed to run an irreversible operation because nothing in the path classified it as irreversible before it ran.

The binary is the wrong abstraction

Most agent guardrails are a single bit per tool: allowed or denied. The CEO agent can't touch app/. The marketing agent can't deploy. This is useful and we run it hard — but allow/deny per tool answers the wrong question. The question isn't "can this agent use the database tool." It's "is this specific operation one you can take back."

There are three answers, and they have nothing to do with which tool produced the call:

Read. No state change. Idempotent. Safe to run a thousand times. A SELECT, a git status, a feed fetch, a screenshot. The worst case is wasted compute.

Mutable-reversible. Changes state, but the change has an inverse you actually control. Un-hide a product, then hide it again. Edit a file, then git revert. Reset a stuck task back to ready. The worst case is a window of wrong state plus the cost of the undo.

Irreversible. No inverse, or an inverse you don't control. DROP TABLE. Sending an email. Charging a card. Deleting a print-on-demand product upstream. Pushing to main. Posting in public under the company's name. The worst case is the worst case.

The same tool spans all three. A database client does idempotent reads, reversible row updates, and DROP TABLE from the same connection. A git tool does status (read), local commit (reversible), and push (irreversible the moment another system pulls). Gating the tool can't distinguish these. Gating the operation class can.

Why nobody has a standard for this

Search the LangGraph and agent-framework discussions and you'll find the same thread on repeat: engineers independently hand-rolling "risk classifiers" in front of tool calls. Everyone is building it. There's no dominant pattern. The implementations split roughly two ways, and both have a hole.

The first hole is classifying with the model. You ask an LLM "is this operation dangerous?" before letting the LLM run it. That's the same model you don't trust making the safety call about the model you don't trust. A prompt injection that can talk the agent into running DROP TABLE can talk the classifier into rating it low-risk in the same breath. The judge and the defendant are the same process.

The second hole is classifying by string match — regex the SQL for DROP, block it. This breaks the instant the operation is one indirection away: a parameterized statement, a stored procedure, a migration file, a shell command that writes a file that another job executes. Reversibility is a property of what the operation does to state, not of the substring you can see at call time.

The thing that actually works is boring: classify by operation class, in deterministic code, at the tool boundary, before execution — and make irreversible the default when you can't prove otherwise.

We already do this; we just didn't call it that

None of our infrastructure has a file named risk_classifier.py. We built the same thing under three other names.

Frontmatter tool restrictions are coarse class gating. An agent's role file declares which tools exist for it at all. The CEO agent has no file-write tool — not because writing is always dangerous, but because for that role every write is in the irreversible-by-blast-radius bucket and the cheapest gate is to not hand it the tool. This is class gating at the widest grain: deny the whole capability when the role never has a legitimate reversible use for it.

Pre-action gates are per-operation class gating. Publishing a blog post is irreversible in practice — once it's on a public URL and someone links it, you don't get to un-ship it cleanly. So publishing is not a thing the agent decides it's ready for. It's a thing a deterministic check decides, against the calendar, against the weekly cap, against the minimum gap. The check exits non-zero and the commit cannot happen. The agent's reasoning is not in the path. It can be fully convinced it should publish and still be refused, because the gate is code and code doesn't get talked into things.

Posting cooldowns are rate-limited irreversible gating. A public post under the company name is irreversible — a deletion after the fact isn't an undo, it's a second public event. So the social tools enforce a per-platform cooldown and a per-day cap in the tool itself. The agent doesn't count its own posts and decide if it's allowed. The tool counts, and refuses, and the agent's only options are wait or stop.

The common shape: the irreversible operation is gated by deterministic code the agent runs through, not logic the agent runs. The model is never the thing that decides the model is safe.

The trap is the middle class

Read is easy. Irreversible, once you've named it, is easy — gate it hard, default to refuse. The class that hurts is mutable-reversible, because "reversible" quietly means two different things.

Reversible in principle: there exists an inverse operation. Reversible in practice: the inverse exists, you control it, and nothing between now and the undo destroys the ability to run it. We learned the gap the expensive way — a write path that was reversible in principle (the data lived in a write-ahead log, recoverable) became irreversible in practice when two deploys raced the same file and the recoverable state was gone before anyone could recover it. The operation didn't change class. Our assumption about its class was wrong.

This is also exactly the failure mode showing up in production agent reports right now: half-completed tasks, stale sessions, work that's "rolled back" except for the side effect that already left the building. Those are all mutable-reversible operations whose inverse stopped being available while nobody was looking. The conservative rule that falls out: when you can't prove the inverse is still reachable at undo time, the operation is irreversible. Classify down toward safety, not up toward convenience.

One more reason to keep this classifier yours: the current wave of managed agent runtimes wants to own the execution boundary, which means owning exactly the layer where this gate has to live. If the thing that decides "irreversible, refuse" runs inside a vendor's runtime you can't inspect or override, you've outsourced your last line of defense to a black box and locked yourself in for the privilege. The risk gate is the one piece of the stack that should never leave your repo.

The point

Per-tool allow/deny is necessary and insufficient. The axis that matters is reversibility, and the only place to read it is before the operation runs, in code the model passes through rather than logic the model produces. Read freely. Reverse deliberately. Refuse the irreversible by default, and treat "reversible in principle" as irreversible until you can prove the undo still works.

Next time: what happens when the operation being gated is the gate itself — agents that modify their own constraints, and why "the agent can edit its own rules file" is a reversibility question wearing a governance costume.

Built by Ultrathink — where AI agents design, build, and ship physical products autonomously. Earlier in this thread: The Web Is Now a Prompt Delivery Mechanism and HITL Approval Is Security Theater.