Should coding agents need permission at every irreversible boundary?

I use coding agents for the boring, asynchronous work, and I like not having to watch every file edit. But I think an agent should be required to state its uncertainty and request explicit approval before crossing an irreversible or high-blast-radius boundary: a database migration, dependency upgrade, permission change, or production deployment. A confident-looking plan can still rest on a weak assumption about data, compatibility, or environment.

The practical compromise seems straightforward: sandboxed work, bounded permissions, dry runs, readable action logs, and human checkpoints before applying the change. Rollback helps, but it is not guaranteed for every kind of change. At the same time, prompting for approval on every small action would just turn asynchronous work back into manual supervision. Do developers prefer stricter approval gates, or more autonomy paired with better rollback mechanisms?

The boundary should be based on blast radius, not whether the command looks scary. A migration in a disposable database can be asynchronous; changing production permissions cannot. I want the agent to show exactly what it intends to do, what it could not verify, and which credential or environment it will touch.

Approval is not a security control if the reviewer is shown a wall of generated text and clicks through it. The log needs to be readable and tied to bounded permissions. Otherwise we are just adding ceremony around an overprivileged process.

For a small project, a prompt before every dependency change would kill the useful part of the tool. I would rather let it work on a branch, run the dry run, and ask once when it wants to merge or deploy.

I would separate uncertainty disclosure from approval. The first should happen whenever the agent has material ambiguity; approval is appropriate when consequences are difficult to reverse. Treating them as the same event may create too many interruptions.

The awkward cases are operational, not dramatic. A permission change may technically be reversible but still strand a support team for an hour. Checkpoints should account for recovery time and ownership, not just whether a command has an undo option.

There is a product tradeoff here: users say they want control, then abandon tools that ask them to supervise every step. Approval should be earned by risk classification, with a useful default path for low-risk work.

Rollback is often discussed as if it restores the previous state. It may restore code while leaving data, external effects, or permissions changed. I favor approval before writes whose effects are not captured in a versioned, testable state.

“Declare uncertainty” sounds good, but an agent can be uncertain in ways it cannot quantify meaningfully. I would prioritize concrete evidence: failed tests, uninspected files, ambiguous schema assumptions, and missing environment access. Those are reviewable signals.

In larger organizations, the checkpoint is also about accountability. A protected deployment environment with required reviewers is more useful than an informal promise that someone will glance at the agent log later.

The wording of the prompt matters. “Proceed?” is nearly meaningless. “This will alter 12 tables, has no generated undo script, and targets production” gives a human a real decision to make.

I would accept a strong gate for production and identity-related changes, then make everything else policy-driven. Small teams cannot afford a human checkpoint for every routine edit, but they also cannot afford a mysterious deployment.

Logs should record the decision context, not just the command history: requested scope, granted scope, assumptions, and approval. That makes later review possible without pretending the approval itself proves the change was safe.

The old rule still works: automate the reversible parts, review the dangerous parts. Calling it an agent does not make an irreversible action less irreversible.