process · irreversible-action-gate TEC-0014 · ratchet: gate

Gate irreversible actions outside the model

Require an out-of-band approval for deletes, payments, sends, and other irreversible tool calls.

Classify tools by reversibility and have the harness, not the model, block irreversible calls until a human or a policy check approves. The model can request but cannot execute. This makes skipping a safety step impossible rather than merely discouraged.

Requires: Adds latency to every gated call, and requires classifying tools by reversibility up front.

Addresses: Prioritizing safety under conflicting goals

Contexts: Autonomous agent, Coding agent, Customer support

Does it work?

supported so far1 supporting · 0 contesting source · last moved 2026-09-04

Efficacy claims — what this technique actually moves, under which conditions, and whether that has been contested.

Needs: a harness that sees every side effect

Fails when:

The harness suspends only the branch awaiting approval while a sibling's side effect executes. Shipped frameworks have this gap, so the gate reads as a barrier and is not one. (helps, narrowly)

mechanismsingle paper
Gating irreversible actions works only if the harness mediates every side effect, not only the branch awaiting approval. Where a gate suspends its own branch while a sibling's effect still executes, the control reads as a barrier and is not one — and the shipped implementations in widely used agent frameworks have this gap rather than it being a misconfiguration.
- supports Stop Means Stop: Measuring and Repairing the Enforcement Gap in Agent-Framework Control Primitives (2026)

Code

No repository linked yet. Contribute one.

Sources

Either way, bring evidence: a link, or what you saw.

Whether a technique works is a claim. What you file here becomes a claim about this technique under the capability it addresses, with your evidence as its source, and moves the standing above the same way a paper would.