Auto-execute modes remove the only gate that was working

The confirmation dialog in a coding agent is not a safety feature anyone designed carefully. It is an artefact of uncertainty about what the agent might do — and it happens to be the only thing standing between a hallucinated migration and a dropped table.

Part of Software supply chain authorization

Why the setting gets turned on

An agent working through a non-trivial task issues dozens of commands. Confirming each one is slower than doing the work manually, which defeats the purpose of the tool.

So the developer enables auto-execute. This is a rational response to a badly posed choice, and blaming the developer misses where the design failed.

The deeper issue is that even with prompts enabled, the control is weak. A developer confirming their fortieth command of the session is not evaluating the fortieth command.

Three failures in the prompt itself

The third is the most consequential. DROP TABLE sessions is a short string. Whether it destroys four million rows in production with no recent snapshot is not visible in that string.

Moving the gate to the endpoint

The client cannot be the control, because the client is configured by the person it is meant to constrain. The control has to sit where the effect happens.

# The database proxy, not the IDE, enforces this.

PROTECTED = ("DROP", "TRUNCATE", "ALTER TABLE ... DROP",
             "DELETE without WHERE", "UPDATE without WHERE")

def execute(conn, sql, auth=None):
    op = classify(sql)
    if conn.environment == "production" and op in PROTECTED:
        effect = render_effect(conn, sql)   # rows, tables, recoverability
        if auth is None:
            raise Refused("authorisation required", effect)
        verify(auth.signature, credential_for(conn.principal))
        require(auth.digest == sha256(canonical(effect)))
        require(auth.single_use and not consumed(auth.nonce))
        consume(auth.nonce)
    return run(sql)

An agent with auto-execute enabled hits this and stops. So does a script, a misconfigured job, or a developer pasting the wrong thing into the wrong terminal. The control does not care what the caller is.

Rendering the effect rather than the command

When the prompt does appear, it should carry the facts that change the answer.

  Authorisation required — production

    Statement:    DROP TABLE user_sessions
    Database:     prod-primary (eu-west-1)
    Rows:         4,182,996
    Size:         2.1 GB
    Dependencies: 3 foreign keys will be dropped
    Last backup:  19 hours ago (partial recovery only)
    Requested by: coding agent, session started 14:02

  Touch your security key to authorise this one statement.

Because this appears rarely — only for protected operations in production — it gets read. That is the whole argument for narrowing the gate: a prompt that fires constantly is noise, and a prompt that fires monthly is a decision.

The environment-boundary question

A common objection: developers should not have production database access at all, so this is solving the wrong problem.

Correct in principle and incomplete in practice. Someone has production access, because incidents require it. Agents increasingly run in environments that hold production credentials for legitimate reasons. Narrowing who has access is worth doing and does not reach zero.

This control is what applies to whoever is left.

Where else the pattern applies

• Cloud infrastructure teardown — delete cluster, delete bucket, delete snapshot
• Identity operations — create credential, grant role, disable logging
• Payment operations — release, cancel, redirect
• Communication — sending to customer lists
• Anything altering backups or retention

Each is a small, enumerable set of operations at a specific endpoint. That is what makes this tractable: you are not gating everything, you are gating the operations whose consequences cannot be undone from inside the system.

A worked example: the same command, two gates

An agent runs a migration that happens to resolve against the production database because an environment variable was inherited from a previous shell.

The third row is the point. A control inside the tool is disabled by a setting inside the tool; a control at the endpoint is not reachable from there at all.

Objections and honest limits

“Developers will just get a different kind of fatigue.” Only if the gate is placed badly. Irreversible production effects are rare in a normal week — if the prompt volume is high, the boundary is drawn in the wrong place.

“The environment boundary is the real bug.” It is, and fixing it is worth doing. It also keeps happening, in every organisation, for a decade now. Gate the effect as well as fixing the boundary.

Moving the gate to where it survives

1. List the irreversible production effects. Schema change, data deletion, deploy, key rotation.
2. Put the gate at the endpoint, not the client. So a client setting cannot disable it.
3. Render the effect, not the command. Target, scope, row counts.
4. Grant by class where it is safe to. So the prompt stays rare and therefore read.
5. Keep the signature with the change record. So the question of who approved has an answer.

Terms used here

Auto-execute mode

A setting that runs agent-proposed commands without asking, usually enabled to escape prompt fatigue.

Rendered effect

The consequence of a command shown in terms a person can judge, rather than the command string.

Endpoint gate

A control enforced where the effect occurs, which a client-side setting cannot reach.

Frequently asked questions

Should developers just not use auto-execute? Per-command confirmation is unusable for real work, so the setting will be enabled. Designing around that is more productive than asking people not to.

Why not fix the prompts in the tool? The tool is configured by the person being constrained. A control that the constrained party can disable is a preference, not a control.

Isn't the real answer removing production access? Narrowing it is worth doing and never reaches zero — incidents require access, and agents increasingly run where production credentials live.

Won't the prompt become reflexive too? Only if it fires often. Gating a handful of irreversible operations means it appears rarely enough to be read.

Is auto-execute mode the problem? It is the symptom. The prompt was a bad control — too frequent, showing the wrong thing, with no middle setting.

Why gate at the endpoint? A control inside the tool is disabled from inside the tool. One at the endpoint is not reachable from the client at all.

Does this reintroduce fatigue? Only if the gate is on the wrong actions. Irreversible production effects should be rare in a normal week.

Sources and further reading

• CISA — known exploited vulnerabilities and incident reporting
• Anthropic — Claude Code security and permissions
• Database operational guidance on irreversible schema changes and recovery windows.
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls
• OWASP — Top 10 for LLM Applications