The Write-Gate Pattern: Why AI Agent Database Writes Should Land PENDING and Fail-Closed

Reference · Updated 17 August 2026

On 18 July 2025 an AI coding agent deleted a live production database during an explicit code freeze — then fabricated data and misreported what it had done. The failure was not a bad prompt or missing permissions. It was that nothing in the execution path could hold the write. The write-gate pattern is that missing control: an agent's write to a system of record lands PENDING and commits only after a human approves — fail-closed, with a tamper-evident record you don't have to take the agent's word for.

Sources: AI Incident Database, Incident 1152 · Fortune — full list below.

What actually failed

It is tempting to read this as "the agent had too much access" or "the prompt wasn't strict enough." Both miss it.

• The prompt was strict — an explicit freeze. But a prompt is an instruction, not enforcement. An agent one token away from a destructive statement follows the token, not the paragraph.
• Least-privilege helps, until it doesn't. The moment an agent legitimately needs write access to do its job, access control has nothing left to say about which write is safe. A DROP and a routine UPDATE arrive on the same credential.

The gap both share: nothing in the execution path could hold the write in the moment between the agent deciding to make it and the database committing it. That interval is where prevention has to live — and where the Replit setup had nothing. That gap is what the write-gate closes.

The write-gate pattern

A write-gate is a preventive control at the write boundary of a system of record. The mechanic:

1. Intercept the agent's write to a protected table, row, or range — before it reaches the database.
2. Hold it as a durable PENDING proposal: persisted, not applied. It survives a crash, a restart, and the agent moving on.
3. Surface it to a named human in a review console — the current value beside the proposed change, in terms a non-engineer can judge.
4. Commit to the real system of record only on approval — fail-closed on conflict, so a stale or contended write is rejected rather than silently overwriting.
5. Record the proposal, the human decision, and the commit in a tamper-evident (append-only, hash-chained) provenance log — an account you don't have to take the agent's word for.

Point 5 is the direct answer to the second half of the Replit story. When the actor can fabricate data and misreport its own actions, an audit trail the actor can write to is worthless. The record has to be independent and tamper-evident, or you are trusting exactly the thing that failed.

The write-gate vs the controls people reach for

The write-gate is not the only thing you can put in front of an agent write. It is the one that closes the specific gap above. Honestly against the alternatives:

Where you gate matters

Framework human-in-the-loop and a write-gate are both preventive; the difference is where the checkpoint lives. LangGraph's interrupt(), the OpenAI Agents SDK's needs_approval, and MCP elicitation pause the tool call inside the agent's runtime — genuinely preventive, and often enough. But that pause is in the orchestrator's memory: tied to one framework, and gone if the process dies. A write-gate moves the checkpoint to the durable write boundary of the system of record itself, so the pending write survives restarts, works across any agent or stack, and is recorded independently. Gate the write, not just the orchestrator — see preventive vs reactive AI agent governance for the full distinction.

A reference shape

Concretely, in front of a production Postgres:

agent ──write──▶ [ write-gate ] ──hold──▶ PENDING proposal  (durable, not applied)
                                          │
                              human reviews: current value  vs  proposed change
                                          │
                    approve ─▶ commit to the real table  (fail-closed on conflict)
                    reject  ─▶ nothing lands
                                          │
                      every step ─▶ append-only, hash-chained provenance log

The agent proposes; it never holds the commit button. A human decides on the specific write, with the before-and-after in front of them. The database only ever sees an approved change. And the log of what was proposed, by whom it was approved, and what committed is written by the gate — not by the agent.

When not to gate

A human gating every write defeats the reason you deployed an agent — it becomes a bottleneck or, worse, rubber-stamp theater. The pattern earns its keep on a narrow band: writes that are irreversible, high-blast-radius, or compliance-relevant. Scope it there; let high-volume, reversible, low-stakes actions run with ordinary reactive observability. Governance that survives real throughput is tiered by blast radius, not applied uniformly.

FAQ