Human Approval for AI Agent Writes: Gating Changes to Systems of Record

Banks have a name for this control, and it is older than the software that enforces it. Maker-checker: the clerk who keys the wire is not the clerk who releases it. One person proposes the change, a second approves it, and the ledger keeps both names. The rule has outlasted every generation of banking software because it never depended on the clerk being right. Then an AI agent arrives with write access to the CRM, and the checker is a sentence in the system prompt asking it to be careful.

Gated writes are the third of the six AI operator security controls, and approval gates are the mechanism. The control, in the words of the post that named the series: reads can be free; writes to a system of record pause for a person. This guide is what that sentence means when you are the one signing. The first two controls, permissions and credentials, decide what the agent can reach. This one decides what it can change.

The series rests on one idea. AI operator security is being safe from the AI agents you operate. Most AI security protects you from someone else’s model. AI operator security protects you from your own agents. Read AI operator security for the argument; the AI agent security checklist has the six controls, each with the artifact that proves it.

Why Reads Can Be Free and Writes Cannot

A gated write is a tool call that changes a system of record and pauses, before it executes, for a named person to approve it, with the approval recorded next to the call. Three parts: the pause, the person, the record. Remove any one and what is left is not a gate. A pause with no person is a delay; a record with no pause is a receipt.

An agent that only reads is wrong the way a search result is wrong: a person reads the answer, finds it off, and discards it. The damage stops at the screen. An agent that writes is wrong on the record. The reminder goes to the wrong customer, the ticket closes with the problem open, two accounts become one with no way back. The record is what the business runs on, which is why the builder’s guide to MCP embedding types says ship read-only first and add actions when the safety story is real.

Both incidents behind this series are failures of this control. In July 2025 a Replit agent deleted a production database after its operator had told it not to make changes without explicit approval. The right rule, in the wrong place. In April 2026 a Cursor agent at PocketOS deleted a production volume and its backups in nine seconds; the founder said there was no confirmation step. Nine seconds is how long a write takes when nothing stands between the agent and the record.

Reads can be free. Writes wait. The rest of this guide is what the waiting has to look like.

Per Call, Not Per Session

At setup an administrator sees a screen that says the agent may update records, ticks the box, and from that moment the writes flow. That screen is a login. It establishes who the agent is and what it may attempt, and says nothing about any particular write, because none of the day’s writes existed when the box was ticked.

A control is per call. This write, with these arguments, to this record, now. The approver sees the tool and its arguments rendered the way a person would read them: the customer and the amount of the credit, the two accounts about to become one. They approve that write or they do not, and the next write asks again. Approving the agent once in the morning is a login, not a control.

Session approval fails twice. As a control, because the grant comes before there is anything to decide, and every write after it is the agent approving itself. As evidence, because the log shows a session approved at 9:02 and four hundred writes by noon, and cannot say which of them anyone looked at. The auditor will ask who approved the merge. The answer cannot be a session.

Per call does not mean a dialog per keystroke; a person can approve a screen of twelve specific changes at once. What they cannot approve is whatever the agent decides to do until five o’clock. The objection that this slows everything down is right about writes and wrong about the business. The approver was going to make the change by hand. Now they read it instead.

Which Calls to Gate

Gate every write to a system of record by default, then decide deliberately which to free. The allow-list from control 1 decides which writes exist for the agent at all; the gated list decides which of those execute without a person. Five classes stay apart from the rest: deletes, exports, merges, bulk sends, and money. Not because they are the most common writes. Because they are the hardest to take back. A delete removes the record, an export moves it beyond your reach, a merge destroys two histories to make one, a bulk send cannot be unsent, and money is money. These five never leave the gated column.

The table is for a collections agent working an accounts-receivable queue.

Gated at launch is the interesting row, because the gate is yours to loosen. After a quarter in which every add_invoice_note was approved and none denied, the approver is stamping, and a stamp is a gate in name only. Move the class from gated to free, deliberately: a named person decides, the decision is recorded with the date and the approval history it rested on, and the change to the gated list is itself a logged event. Loosen per class of write, never per agent, so that trust earned on notes does not leak into credits. And never loosen the five.

The vendor never loosens a gate. A release that moves send_reminder from gated to free without your decision is a tool change without notice, which is control 4. Trust is extended per class of write, by a person on your side, and the record shows who extended it.

Where Approval Gates Live

A pause can sit in one of three places: in the prompt, as a sentence asking the model to check with a person first, which is the Replit rule; in the client, as the confirmation dialog Claude or Cursor shows before a tool runs; or on the server, where the MCP server or a gateway in front of it holds the call until an approver with an identity of their own says yes. Only the third is the operator’s.

The MCP specification (current revision, 2026-07-28) wants the pause. It says “there SHOULD always be a human in the loop with the ability to deny tool invocations,” that applications SHOULD “present confirmation prompts to the user for operations, to ensure a human is in the loop,” and that clients SHOULD “prompt for user confirmation on sensitive operations.” Read the verbs. For clients, SHOULD. For servers, MUST: servers must “implement proper access controls.” The courtesy is on the client. The obligation is on the server.

The client’s prompt belongs to the client’s vendor and the user. It can be switched off or clicked through, and it runs on hints from the server; the schema says a tool marked destructive “may perform destructive updates to its environment,” and the specification tells clients to treat annotations as untrusted unless the server is. A hint about a tool is not a hold on a call. And the dialog asks the user of the agent, who usually wants the write to go through. The maker is asking the maker. The checker is somebody else, on the server.

OWASP arrives at the same place. Its entry on excessive agency names excessive autonomy as a root cause, an application that “fails to independently verify and approve high-impact actions,” and asks for a human “to approve high-impact actions before they are taken” and for authorization “in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” Downstream of the model is the server.

The server-side gate is also the only kind that can wait. A dialog nobody answers vanishes with the chat session. A pending call on the server sits in a queue with a name on it, can route to a named backup approver, and expires to deny when its timeout runs out. If the approver is away, the write waits. If the approver is the agent’s vendor, the maker and the checker are the same party, and there was never a gate. The same hold works when the agent has been fooled by something it read, which is control 5: the injection asks to export the table, and the person at the gate says no.

Where the Approval Is Recorded

Next to the call. One line in the audit log carries the agent’s identity, the client it ran in, the tool, the arguments, the approver’s identity, the decision, the time, and the result. The full field list and the ownership bar are control 6; the approver is the field this control adds.

The identity is the part vendors drop. Approved, true, with no name is a checkbox. Approved by admin is a shared login, which is control 2 failing and taking this one with it. The approver is a person from your directory, named as you would name them to the auditor. Record the denials too: they are proof the gate held, and the evidence for what to loosen.

Three artifacts prove the control: the list of gated calls, exported as configuration from where it is enforced; the approval interface, a screen a named person uses; and the log line for one approval, with the approver’s identity on it, exported rather than screenshotted. The approval is not a feeling the approver had. It is a row.

How to Verify the Control

Four steps turn the vendor’s sentence into evidence, and they take an afternoon.

First, ask for the gated list as configuration, exported from where it is enforced, and lay it beside the allow-list from control 1: every write on the allow-list is either gated or freed by a named person on a date. Second, have the agent attempt send_reminder in a client with confirmations switched off, or in a second client, and watch the call sit pending on the server while the record stays unchanged. Third, approve it as a named person and read the line: agent, tool, arguments, approver, time, result. Then deny one and read that line too. Fourth, walk away. Leave a gated write pending past the vendor’s timeout and come back. The right answer is nothing: the write is still waiting or has expired to deny, and the record is as you left it. A write that executed while nobody was looking is the finding.

A vendor who can demonstrate the control only from the client’s dialog has it in the wrong place. One who can do all four in front of you has the third of the six controls, and the line from step three is the start of the sixth. Keep the exported list, the two log lines, and a capture of the pending queue, dated: the auditor’s artifact, and the baseline for every loosening decision.

Failure Modes

The tell is the same in every case. Ask who said yes to a specific write, and when, and the answer is not a person’s name next to that call.

The Contract Term and the RFP Question

The checklist makes the case for putting the six controls in the contract; the term for this one is short: approval gates are yours to loosen as trust is earned, and the vendor cannot loosen them for you. The gated list is configuration you control, and a change to it is a logged event with a named person on it. The five classes that stay gated are named. A gate that expires does so to deny. The approval record is part of the audit log you own. It belongs with the security terms in SaaS vendor security due diligence.

Conclusion

Maker-checker never depended on the clerk being right. It depended on a second person and a ledger. The agent is a faster maker than any clerk and no more trustworthy, and the gate is how it gets a checker: a server that holds the write, a person who says yes or no, and a line in the log that says which, and who.

Reads can be free. Writes wait. The ledger keeps both names.

Related Guides

• AI Agent Security Checklist – The six AI operator security controls and the artifact for each
• AI Agent Permissions – Control 1: the allow-list that decides which writes exist
• AI Agent Credentials – Control 2: the agent’s own identity, and why the approver needs one
• AI Agent Audit Log Requirements – Control 6: the field list and ownership bar for the log
• MCP Embedding Types – The builder’s view: read-only first, then actions with a safety story
• MCP Auth and Security – Scope design per resource, verb, and sensitivity, and the audit-log bar