The first version of your agent asks permission for everything. Users approve, approve, approve, and within a week they are clicking the button without reading, because forty consecutive requests were fine and the forty-first looks like the others. The gate is still there. It stopped working days ago.
The second version asks for nothing, runs fast, and one afternoon deletes a production table because a document it was summarising contained an instruction it followed.
Neither extreme works, and the good answer is not "somewhere in between" — it is a specific rule about which actions get a gate.
What changed in 2026
- Agents started taking consequential actions. Read-only assistants became agents that write files, send messages, and move money, which turned oversight from a nice-to-have into a design requirement.
- Approval fatigue got recognised as the failure it is. Teams stopped counting gates as safety and started measuring whether anyone was actually reading them.
- Confirmation moved into the runtime. Rather than each application inventing its own pause-and-ask flow, agent platforms began supporting confirmation round-trips directly.
- Plan approval displaced step approval. Reviewing a proposed sequence once, before execution, turned out to work far better than interrupting after every step.
Gate on reversibility
The useful question is not "is this important?" It is "if this is wrong, can we undo it?"
| Action |
Reversible? |
Gate |
| Read a file, search, query |
Yes |
No |
| Write to a scratch branch |
Yes |
No |
| Edit a document with version history |
Yes |
Rarely |
| Send an email |
No |
Yes |
| Delete data without backup |
No |
Yes |
| Move money |
No |
Yes |
| Post publicly |
Effectively no |
Yes |
| Merge to main |
Mostly |
Depends on your pipeline |
Importance is the wrong axis because it tracks how people feel rather than what recovery costs. Reading a sensitive document feels important and is trivially recoverable. Sending an email feels routine and cannot be taken back.
The corollary is more useful than the rule: make actions reversible instead of gating them. An agent writing to a branch rather than main needs no approval, because review already exists downstream. An agent moving files to a trash folder rather than deleting needs no approval. Engineering reversibility removes gates permanently, and every gate removed makes the remaining ones more likely to be read.
Approval fatigue is the real threat
A gate is only protection if a human evaluates what is behind it. After enough routine approvals, people stop evaluating — not through carelessness but because pattern-matching is what humans do, and the pattern says these are all fine.
This means each unnecessary gate actively degrades the gates that matter. A system asking permission for reads is training its users to approve without reading, and the one request that deserved scrutiny arrives into that habit.
Practical consequences:
Fewer gates, better placed. Three meaningful approvals a day get read. Forty do not.
Make consequential requests look different. If the irreversible prompt looks like the routine one, it will be treated like the routine one. Different presentation, different colour, an explicit statement of what cannot be undone.
Measure approval latency. If the median time between showing a request and approving it is under two seconds, nobody is reading. That number is worth tracking, and it is a more honest safety metric than counting how many gates you have.
Present something reviewable
The most common design failure is asking a human to approve an intention rather than an action.
"I'm going to update the deployment configuration" is not reviewable. There is nothing to evaluate — you either trust the agent or you do not, and if you trusted it you would not have a gate.
"Change replicas: 3 to replicas: 30 in prod/values.yaml" is reviewable. A human can see that the intended 3 became 30 and stop it in a second.
The rule: show the exact change, the exact recipient, the exact amount. For a message, the full text and the address. For a payment, the sum and the destination. For a file edit, the diff. Summaries hide precisely the details that make review possible, and an agent's summary of its own action is generated by the same process that produced the action.
Batching helps here too. Presenting a full plan — every step the agent intends, with specifics — lets a human evaluate the shape of the work once, at the point where the most context is available. That beats twenty interruptions, each with too little context to judge. AI agent observability covers capturing the trace that makes after-the-fact review possible too.
Common mistakes
- Gating reads. Trains click-through and protects nothing.
- Approving intentions. Nothing concrete to evaluate.
- Identical presentation for routine and irreversible actions. The dangerous one gets the routine response.
- No timeout behaviour. An agent waiting forever on an unanswered gate hangs; decide whether it cancels or escalates.
- Gating instead of scoping permissions. An agent that cannot perform an action needs no approval for it — see AI agent permissions.
- Not measuring whether approvals are read. Latency tells you; the gate count does not.
- Same gates for every user. A finance lead and a new hire warrant different thresholds.
FAQ
Does adding approvals defeat the point of an agent?
Only if placed badly. An agent doing thirty reversible steps and pausing once before an irreversible one is still doing thirty steps you did not. The productivity loss comes from gating everything, not from gating the right things.
What about fully autonomous agents?
They exist and are appropriate where every action is reversible, the scope is tightly bounded, or the cost of error is genuinely low. The design question is the same: what happens when it is wrong, and can you undo it?
How does this interact with prompt injection?
It is one of the more effective mitigations. An injection that makes an agent attempt an irreversible action still hits the gate, and a human sees a request that does not match what they asked for. That only works if the gate shows specifics and is not being clicked through — see prompt injection defense.
Should the agent explain why it wants to do something?
Briefly, alongside the concrete action rather than instead of it. Reasoning helps a reviewer understand context; it is generated by the same process as the action, so it cannot be the thing you verify.
Where to go next
For bounding what an agent can do before any gate is involved, read AI agent permissions and agent identity and auth. For the attack these gates help contain, prompt injection defense.