Maker-Checker Dual-Review Control Mechanism for AI Agents

When AI agents start deciding on their own to delete production data, transfer money, or deploy code, a critical question surfaces: who approves their actions? Maker-Checker (the four-eyes principle) provides a structural answer—the party proposing the action and the party approving it must be two distinct entities.

What Maker-Checker Is: From Financial Controls to AI Guardrails

The four-eyes principle is nothing new. The financial industry has used it for decades: payments above a threshold, wire transfers, and accounting vouchers require a second pair of eyes to review before they go through. The same idea appears in high-stakes scenarios as the "two-person rule"—no single individual can complete a critical operation alone. Both are concrete forms of separation of duties: splitting sensitive operations so that initiation and authorization become distinct responsibilities borne by different people.

This control works because it doesn't depend on any one person staying careful, honest, or clear-headed. It assumes that both errors and malice are possible, and through structural design it ensures a single point of failure isn't enough to cause harm. When AI agents are involved, that assumption is exactly what you need most.

In LoopRails terminology, Maker-Checker is a named pattern—the concrete form the Authorized guardrail takes for the highest-risk actions: whoever proposes cannot approve.

Separation of Duties (SoD) is a core principle in internal controls and information security. It means splitting a sensitive task into multiple steps handled by different parties, so that no single individual can complete the entire critical process alone. It originated in accounting and auditing practice to prevent fraud and error: for example, bookkeeping and review, initiation and authorization, execution and reconciliation are typically assigned to different roles. In information security, SoD evolved further into access control policies ensuring that high-privilege operations require multiple people to collaborate—such as key escrow, code signing, and production environment changes. The assumption behind it matches the four-eyes principle: don't rely on individual virtue or care, but use structural constraints so that a single point of failure or malicious act cannot cause complete damage. For AI agents, SoD means stripping roles like "propose," "approve," and "execute" away from the model itself and assigning them to independent parties, transforming uncontrollable autonomous behavior into an auditable, interceptable collaborative process.

Why "Proposer ≠ Approver" Matters Especially for AI Agents

For human employees, separation of duties guards against error and fraud. For AI agents, it guards against more. Agents have no skin in the game, no fear of consequences, and a well-documented tendency—to be confidently wrong. An agent that can both propose and execute its own actions is a single point of failure with superhuman speed.

The core question is simple: can a human realistically catch the error within the time window? When an agent both decides and acts, the answer for fast, irreversible operations is no. There is no window at all. Maker-Checker creates that window—it forces the agent to stop at "here's what I want to do," hands the decision to an independent checker, and only then can the action become reality.

This is also why the checker must be independent of the proposer. If the same model, with the same context and the same prompt, both produces and reviews the action, you haven't added a pair of eyes—you've added a mirror. Independence means different identities, ideally different reasoning approaches, and in the highest-risk scenarios, a human with authority in the loop.

Which Agent Actions Require Maker-Checker

You don't put four eyes on everything. That just trains people to click "Approve" without reading. Maker-Checker is for the highest-risk actions.

Use the LoopRails scorer to rate each action by reversibility, blast radius, and stakes:

• G0 to G1: Low risk, reversible, small blast radius. Let the agent run on its own; no checker needed.
• G2: Meaningful but recoverable. Usually handled with guardrails, logging, and after-the-fact review rather than blocking secondary approval.
• G3: Irreversible, large blast radius, or high stakes. This is the tier where Maker-Checker is recommended.

Concrete G3 examples requiring an independent checker: deleting production data, fund transfers above a value threshold, deploying to production, sending external communications on behalf of the organization, modifying access controls or credentials, signing or submitting anything legally binding.

Value thresholds make this operational. You don't need a human to approve a $2 refund, but you do need a human to approve a $20,000 wire transfer. Set explicit thresholds per action type so the control triggers exactly when "the cost of getting it wrong exceeds the cost of a second pair of eyes."

Value Threshold is a common mechanism in risk-tiered controls. It sets a quantity or monetary limit for a type of operation, and only when that limit is exceeded does it trigger additional approval. Its purpose is to concentrate limited human attention on transactions that would truly cause major losses, avoiding reviewing every low-value operation, which leads to approval fatigue and rubber-stamping. In finance, thresholds are typically tied to regulatory requirements and internal risk control policies—for example, wire transfers above a certain amount must be double-reviewed. In AI agent scenarios, thresholds can be set separately by action type: fund transfers by amount, data deletion by number of records or sensitivity level, deployments by scope of affected services. Thresholds aren't fixed; they should be adjusted periodically based on business risk appetite, historical incidents, and regulatory changes. Reasonable thresholds let Maker-Checker activate only when "the cost of getting it wrong exceeds the cost of a second pair of eyes," striking a balance between safety and efficiency.

How to Implement Maker-Checker for Agents

Getting the intent right is half the work; the implementation is where most Maker-Checker controls quietly fail.

Identity separation. The proposer and the checker must be distinct, authenticated parties. The agent acts under its own identity, with permission to propose but not to commit G3-level actions. Approval is granted by an independent human or system identity. If the agent holds the credentials to finalize the action, you've only done separation in name.

Server-side bound approvals, unforgeable and non-replayable. Approvals must be enforced where the action actually executes, not in the agent's own reasoning or in a client-side UI. An agent that can convince itself it has been approved, or that can reuse an expired approval token for a new action, has already defeated the control. Bind each approval to a specific action, a specific payload, and a single use. Tie it to a signed server-side record so it cannot be replayed for a different request.

Show the real diff, not a summary. The checker must approve what will actually happen, not the agent's description of what will happen. If the agent both executes the action and writes the action summary for the approver, the agent controls both ends of the conversation. Show the literal diff: the exact data rows to be deleted, the exact payee and amount, the exact files to be changed. If the second pair of eyes only sees the proposer's own marketing copy, the full value of those eyes evaporates.

Replay Attack refers to an attacker intercepting and reusing a legitimate authentication credential or approval token to perform unauthorized operations. In traditional Maker-Checker processes, if the approval token isn't bound to a specific action, payload, and single use, the agent or a third party could copy one approval onto another request, bypassing the checker. Key designs to prevent replay include: each approval token containing a unique nonce, being bound to a specific action ID and payload hash, having a short validity period, and recording used status server-side. For AI agents, server-side bound approvals are especially important, because agents may forge an "approved" state through prompt injection, context manipulation, or their own reasoning errors. Only by placing approval logic on the server that actually executes the action, and ensuring tokens are unforgeable and non-reusable, can the four-eyes principle truly take effect—rather than degrading into agent self-authorization.

Failure Modes: When Four Eyes See Nothing

Maker-Checker is easy to implement badly. Here's how it degrades into a single-person rubber stamp.

Both sides rubber-stamping. Automation bias means a lone approver tends to approve. When the proposer is a fluent, fast, usually-correct AI, the checker's default state drifts toward "looks fine, approve." Over time, the human becomes a clicker. Separation of duties only helps when the checker has real authority, awareness, capability, and accountability—the four A's—and doesn't just click "yes."

Checker lacks real authority: the moral crumple zone. If the human can technically refuse but is measured on throughput, has no time to genuinely review, or gets blamed when they block a deployment and never praised when they catch a problem, you've built a moral crumple zone. The human absorbs accountability for decisions the system never truly let them make. This is worse than having no checker, because it launders the agent's actions through someone who cannot meaningfully refuse. A checker without real authority is a liability shield, not a control.

AI-checking-AI collusion. Using a second AI as the checker is tempting and sometimes suitable for lower tiers, but it's fragile at G3. Two models from similar training, given similar context, tend to make correlated errors and miss the same things. They can also be jointly manipulated by the same carefully crafted input. AI-checking-AI gives you two instances of the same failure mode, not independence. For irreversible actions, the checker should be a human with authority, or at least a genuinely independent system with different inputs and assumptions.

None of this is hypothetical. Research on AI coding agents found that a plan-approval step reduced attacks, but human intervention success rates remained only 9% to 26%. In other words, even with a human in the loop, their chance of catching a bad action is only a fraction. That's the gap Maker-Checker must close through real authority and real diffs—not through the mere presence of an approve button.

Key Takeaways

• Maker-Checker (four-eyes) for AI agents means the agent proposes an action and an independent party approves before it takes effect. Proposer ≠ approver is the whole point.
• It derives from the four-eyes principle, the two-person rule, and separation of duties. It works because it doesn't rely on any single party staying careful.
• Apply to G3-level actions: irreversible, large blast radius, or high stakes, plus value thresholds for funds. Skip G0 to G1, use lighter controls for G2.
• Implement with identity separation, server-side single-use bound approvals, and real diffs shown to the checker.
• Watch for failure modes: automation-bias-driven mutual rubber-stamping, checkers without real authority (moral crumple zone), and AI-checking-AI that looks independent but colludes.
• Checkers need the four A's: authority, awareness, capability, accountability. Without them, four eyes see nothing.

One-line Summary

Maker-Checker (the four-eyes principle) requires AI agents only to propose high-risk actions, which execute only after an independent checker approves, guarding against irreversible errors.

Paragraph Summary

The article systematically explains applying the financial industry's four-eyes principle to AI agents as the Maker-Checker pattern. The core is proposer ≠ approver: the agent can only propose G3-level high-risk actions (such as deleting production data, large transfers, deploying to production), approved by an independent human or system before the action takes effect. Implementation essentials include identity separation, server-side single-use bound approvals, and showing the checker real diffs rather than agent summaries. The article also dissects failure modes: automation bias leading to mutual rubber-stamping, the "moral crumple zone" when checkers lack real authority, and collusion risk in AI-checking-AI. Research shows human in-the-loop intervention success rates are only 9% to 26%, so checkers must possess the four A's—authority, awareness, capability, and accountability—or four eyes will see nothing.