More approvals feel like more control. Most of the time, they are just more friction.
Teams reach for the familiar lever: put a person in front of the dangerous step. Every send, delete, or post waits for a yes. It stops some bad outcomes, and it makes the safe ones slower and the reviewer tired enough to stop reading closely.
The problem is that approval protects the moment of action. It does not change what the action does after it happens. A human can say yes to an irreversible step, and that yes is still a one-way door.
The control teams under-invest in is the undo path. Make the important actions detectable and undoable, and you can allow more of them, watch them, and recover from the ones that go wrong. That is the stronger position.
Prevention is the wrong axis for the undo path
Allow, deny, and approve are real, useful controls. But they classify an action by its risk at the moment it happens, and they assume the worst of that risk is the action being done at all.
Most agent work is not like that. A support email is usually wrong, not dangerous; the real exposure is how long it takes to find it after it leaves, and whether it can be taken back. That is an undo problem wearing the clothes of a gate problem.
If you only invest in approval, the agent stops at the door for the work that matters and moves freely on the work you forgot to gate. If you also invest in the undo path, the important work becomes detectable and recoverable, and you can safely let more of it through. How to give agents autonomy without losing control covers the other side of that same trade.
Reversibility is the stronger control
A reversible, observable action is cheaper to allow than an irreversible one. The cost of a mistake moves from preventing it to recovering from it, and recovery is usually a smaller bill than the review burden and the stalled work that prevention creates.
To compare two actions, run the same four questions.
Can you detect the effect without a human
Can a log, a receipt, or a monitor tell you the action happened and which value moved, before a customer does?
Can you reverse it, and with what
Is there a real undo, an idempotent write that overwrites cleanly, or a compensating action that repairs the effect?
How long does the window stay open
Some effects stay reversible for minutes, some for days, some never once. The width of that window is part of the risk you are carrying.
What does a mistake cost to recover
An email can be corrected. A deleted row may be in nobody's backup. A public comment is often gone before it is found.
Run a few of your own actions through the four:
- Send a support email. Detectable by the send log you own, reversible while the provider still permits a recall, a short window, and a modest recovery cost. This is the kind of action you want free-flowing.
- Delete a database row. Often detectable, usually irreversible once committed, no real window, and a recovery cost set by how fresh your backups are. This is where the gate belongs.
- Post a public comment. Detectable only if the action is logged by you, hard to remove, a fast-closing window, and a recovery cost measured in reputation rather than minutes.
For SDK tools and managed actions visible to the runtime, Punk uses a five-level side-effect model, and undeclared tools default to a conservative level. The point is the same: consequence is a first-class axis, not a footnote. Punk's governance documentation shows how that model is meant to be applied.
The reversibility ladder
Answer the four questions and the action lands in one of four lanes. Think of it as blast radius crossed with reversibility.
- Cheap and reversible. Allow it. Log it, and move on.
- Reversible but high-value. Allow it with logging and an audit trail you can actually read.
- Irreversible or expensive to recover. Require approval, or block it.
- Undetectable. Do not automate it at all.
Approval is not the default. It is the lane an action falls into when the undo path is thin. That is what gives review a real target instead of a tax on everything. The governance examples walk the same shape from the policy side.
Build the undo before you grant the power
The undo path is something you build, not something you hope for.
Give consequential writes an idempotency key so a retry overwrites instead of doubles. Pair destructive actions with a compensating action that can walk them back. Make the effect detectable by writing down what changed and for which subject. And rehearse it: a rollback you have run once in staging is a capability; a rollback you have only described is a claim.
That habit is the same budget the evidence budget argues for in a pilot. Spend on the proof and the recovery before you spend on the autonomy.
What this does not replace
Reversibility is not policy, and it is not identity. You still need to answer which agent acted, under which policy, for which subject. The routing receipt is one way to make that chain visible for a single response.
It also does not reach the work the runtime cannot see. An out-of-band tool, a script that bypasses the governed path, or a system that runs on its own rails still depends on its own controls. The enterprise security review guide keeps that boundary explicit instead of implying one runtime covers everything.
Start with the actions you cannot undo
Pick one agent you actually run. List its six to ten most consequential actions and score each on the four questions: detectable, reversible, how long the window is, and what a mistake costs. The actions that fail the undo test are exactly where approval and detection belong.
Control is not keeping an agent powerless. It is deciding which actions you can afford to undo, and building the undo before you grant the power.
Questions readers ask
Is more human approval the same as more control?
No. Approval protects the moment of action but does not change what the action does afterward. A reversible, detectable action is usually a better target for control than a one-way irreversible step.
What is the four-test for deciding whether to allow an agent action?
Ask whether you can detect the effect without a human, whether you can reverse it, how long the window stays open, and what a mistake costs to recover. Cheap and reversible work can be allowed; irreversible or expensive work needs approval or a block.
Does reversibility replace policy, identity, or audit?
No. Reversibility is one axis of control. You still need identity to say who acted, policy to say what was allowed, and an audit record to connect the decision. Reversibility decides where approval and detection should focus.
What should I do first if I run an agent in production?
List its six to ten most consequential actions and score each on the four tests: detectable, reversible, window length, and recovery cost. The actions that fail the undo test are where approval and your detection controls belong.
Find the work your agents repeat.
Punk safely reuses proven results and keeps uncertain work with your original model.