Preventive vs Reactive AI Agent Governance
The difference is when control acts. Preventive governance holds an AI agent’s write before it commits — approve, then it lands. Reactive governance lets the write land and observes it after — log, audit, undo. For writes that are irreversible or high-blast-radius, only prevention is a real control; reactive tooling is incident documentation.
Preventive AI agent governance holds an agent’s action before it takes effect: the agent proposes a write, the write is held as a durable PENDING proposal, and it commits to the real system of record only after a human (or a policy) approves — fail-closed, so an unapproved or conflicting write never lands.
Reactive AI agent governance lets the write happen and then observes it: logging, alerting, auditing, or undoing / rolling back after the change is already in production.
The same split is often written proactive vs reactive. Preventive / proactive stops the bad write; reactive documents it. Put plainly: reactive governance answers “what did the agent do?” — preventive governance answers “may the agent do this?”, before it’s done.
The two postures, side by side
| Preventive — approve before commit | Reactive — audit / undo after | |
|---|---|---|
| When it acts | Before the write commits | After the write has landed |
| Failure mode | Fails closed — nothing ships unapproved | Fails open — the bad write already shipped; you clean up |
| What it produces | A held proposal + a recorded approval decision | A log entry, an alert, or an undo |
| Question answered | “May this write land?” | “What did the agent change?” |
| Accountability | A named human approved before publish | Reconstructed after the fact |
| Best for | Irreversible, high-blast-radius, low-frequency writes | High-volume, reversible, low-stakes actions |
| Typical form | Approval gates, human-in-the-loop, propose-then-commit, fail-closed writes, MCP elicitation | Audit logs, change history, undo / revert, rollback, observability |
What counts as preventive
Preventive control is any mechanism that can stop an agent’s action in the execution path, not just record it: pre-execution guardrails, human-in-the-loop approval, propose-then-commit (a.k.a. draft → approve → execute), fail-closed writes, and framework hooks such as MCP elicitation, LangGraph’s interrupt(), or the OpenAI Agents SDK’s needs_approval.
Where you gate matters
Most framework human-in-the-loop pauses the tool call inside the agent’s runtime — LangGraph’s interrupt(), the OpenAI Agents SDK’s needs_approval, MCP elicitation. That is genuinely preventive, and often enough. But the pause lives in the orchestrator’s memory: it is tied to one framework, and if the process dies the pending action can die with it.
A write-gate moves the checkpoint to the write boundary of the system of record itself. The proposed write is persisted as a durable PENDING record — independent of which framework, or which agent, produced it — and it commits to the real database only on approval: surviving restarts, reviewable by a non-engineer, and recorded in a tamper-evident log. The one-liner: gate the write, not just the orchestrator.
Why reactive isn’t enough for writes
In a widely-reported 2025 incident, an AI coding agent deleted a company’s production database during what was supposed to be a change freeze — the controls in place logged and lamented the damage but did not prevent it, because nothing in the execution path could hold the write. That is the failure mode reactive governance cannot fix.
An audit log tells you the agent dropped the table; it does not stop it. Undo assumes the damage is reversible and that no one downstream has already acted on the bad data. You cannot un-send a number an auditor already saw, un-charge a customer, or un-leak a record. Least-privilege and read-only replicas help, but the moment an agent legitimately needs to write, access control alone has nothing left to say about which write is safe. For irreversible or high-blast-radius writes, prevention is the only real control.
The write-gate pattern
The defining preventive primitive for agent writes to a system of record — walked through in full, with the July 2025 Replit production-database deletion as the worked example, in The Write-Gate Pattern:
- Intercept the agent’s write to a protected table, row, or range.
- Hold it as a durable PENDING proposal — persisted, not applied.
- Surface it to a named human in a review console (with the current value and the proposed change).
- 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.
- Record the proposal, the decision, and the commit in a tamper-evident (append-only, hash-chained) provenance log an auditor can verify.
Scope it. A human gating every write defeats the reason you deployed an agent — it becomes either a bottleneck or rubber-stamp theater. Gate the narrow set of high-blast-radius writes; let low-stakes, reversible actions run reactively. Governance that survives contact with real throughput is tiered by blast radius, not applied uniformly.
Preventive is not just a confirmation dialog
A yes/no prompt is the cheap part — it ships free in the agent frameworks. The durable value of a write-gate is what the frameworks don’t give you: the proposal is persistent (it survives a crash or a restart), it is bound to the system of record (the gate is at the commit, not a step in one orchestrator), it is framework-agnostic (any agent, any stack, one review surface), it commits fail-closed on conflict, and every decision is tamper-evident. That combination — not the prompt — is the governance.
When to use which
- Preventive — writes to a system of record that are irreversible, high-blast-radius, or compliance-relevant (customer data, financial records, production tables, anything an auditor or regulator asks about).
- Reactive — high-volume, reversible, low-stakes actions where an approval queue would only create fatigue and rubber-stamping.
- Both, tiered — most real systems need reactive observability everywhere and a preventive gate on the thin set of writes that must not ship unheld.
FAQ
What is preventive vs reactive AI agent governance?
Preventive governance holds an AI agent’s write before it commits — it lands only after a human or policy approves, fail-closed. Reactive governance lets the write land and then logs, audits, or undoes it. Preventive stops a bad write; reactive documents it.
Is LangGraph interrupt() preventive or reactive?
Preventive — it pauses a tool call before it runs. The caveat is scope: it gates inside the agent’s runtime and lives in the orchestrator’s memory, tied to one framework and lost if the process dies. A write-gate moves the same preventive checkpoint to the durable write boundary of the system of record.
How do I let an AI agent write to my production database safely?
Combine least-privilege access with a preventive write-gate: route the agent’s writes to protected tables through a hold-then-commit step where a proposed write lands PENDING, a human approves, and it commits fail-closed — recorded in a tamper-evident log. Access control decides whether the agent may write; the gate decides which write is safe.
Isn’t a write-gate just a confirmation dialog?
The prompt is free in the frameworks. The governance is the rest: a persistent proposal that survives a crash, gated at the system-of-record commit rather than a step in one orchestrator, framework-agnostic across any agent, fail-closed on conflict, and tamper-evident.
What is a tamper-evident provenance log?
An append-only, hash-chained record of every proposed write, the human who approved or rejected it, and the resulting commit — structured so any after-the-fact edit to the record is detectable. It turns “we have logs” into “we can prove what was approved, by whom, and that the record wasn’t altered.”
When should I not gate a write?
When the writes are high-volume, reversible, and low-stakes. Forcing a human to approve every one produces approval fatigue and rubber-stamping — which is worse than no gate. Gate the narrow band of high-blast-radius writes; leave the rest to reactive observability.
How Penholder implements this
Penholder is a preventive write-gate for AI agents: it holds an agent’s writes to your Postgres — or to a governed spreadsheet — as PENDING until a human approves, then commits fail-closed with a tamper-evident provenance log. Framework-agnostic, at the write boundary, reviewable by a non-engineer. See how it works at penholder.ai.