A bank teller can enter a wire transfer. The teller cannot release it. A second, more senior person has to look at the same transfer and approve it before the money moves. That separation — one person prepares, a different person approves — is the maker-checker control. It is one of the oldest and most durable ideas in regulated work, and it exists for a single reason: the person doing the work is the worst-placed person to catch their own mistake or hide their own fraud.
The control goes by several names. In finance it is maker-checker or dual control. In quality and manufacturing it is segregation of duties. In many European frameworks it is the four-eyes principle — no consequential action proceeds on a single pair of eyes. The labels differ; the mechanic is identical. Authority is split so that no one actor can both originate and authorize the same consequential act.
Why splitting the work is the whole point
The instinct, on first encounter, is that maker-checker is about competence — a second person who is better at the job double-checking the first. It is not, mostly. It is about incentive and blind spots.
The maker is committed to their own work. They have already decided it is correct; that is why they finished it. They are also the one person with the motive to push a bad transaction through quietly. Handing the approval to someone with no stake in the original work breaks both problems at once. The checker has fresh eyes and no reason to wave it through.
That is why a real maker-checker control is structural, not advisory. It is not "please have a colleague glance at this." It is a rule the system enforces: the same identity that prepared a transaction is physically barred from approving it. The honest maker and the dishonest maker are treated the same way, because the control does not depend on knowing which one you have.
Where the rule already lives
This is not a best practice somebody invented for software. Regulators built maker-checker into the rules that govern people, and those rules predate AI entirely.
| Domain | The control, codified |
|---|---|
| Pharma manufacturing | 21 CFR 211.22 — the quality unit approves or rejects; it does not also produce the batch |
| Batch release (EU) | EU GMP Annex 16 — a Qualified Person, separate from production, certifies release |
| AML / sanctions | The Wolfsberg Group names four-eye review as the control standard; a BSA suspicious-activity-report filing is a mandated human decision |
| Electronic records | 21 CFR Part 11 — signatures carry recorded meaning (11.50) and bind to the record (11.70) |
The thread through all of them is the same: a consequential, one-way action — a batch released to patients, a transaction monitored and reported, a record signed — must pass through two separated hands. One prepares. A different, authorized person approves. And the approval is recorded so it can be examined later.
What changes when the maker is a machine
For decades the maker and the checker were both people, so the separation was enforced socially and by access controls: different logins, different permissions, a manager who would notice. The moment an AI agent becomes the maker — drafting the wire, triaging the alert, preparing the batch record — those informal safeguards quietly stop working.
An agent does not have a separate login by instinct. It does not pause to find a colleague. Worse, the most common way teams "govern" agents today is to put the rule in the prompt: prepare the transaction, then have it approved. That is a suggestion, and an agent can be re-prompted, jailbroken, or simply confused into ignoring it. Nothing physically stops the same agent from preparing a payment and then, on the next step, approving it.
The fix is to apply the old rule the old way: make the separation structural, enforced by something the agent cannot edit. That is what MakerChecker does. The same agent provably cannot be both maker and checker on a single run — not "should not," but cannot, refused at runtime and written to the log. We go deeper on the underlying control in segregation of duties for AI agents.
Maker-checker, applied to an agent
In practice the control becomes a few enforced rules around the agent rather than instructions inside it.
- The maker is a named identity. The agent acts as something specific, not as an anonymous process. You cannot separate two actors you cannot name.
- The approval is a real step, not a checkbox. A consequential action parks the run and waits for a checker. The work does not proceed on the maker's word alone.
- The requester cannot approve their own request. The agent that prepared the work is barred from the approval, the same way a teller is barred from releasing their own wire. Where the stakes warrant it, the gate can require several named approvers — an n-of-m quorum — none of whom may be the requester.
- Every step is recorded. Who prepared, who approved, what they were permitted to do, and the reason they gave. The record is tamper-evident, so a later reviewer can trust that it was not edited after the fact.
The checker, in this model, can be a human signing off, or in lower-stakes cases a second, differently-scoped agent — but never the same actor wearing two hats. The point is the separation, not whether the second pair of eyes is carbon or silicon. For workflows where the four-eyes framing maps most cleanly, see the four-eyes principle for AI workflows.
A concrete example
Take an AML alert. An agent reviews a flagged transaction, gathers the supporting context, and drafts a recommendation: close the alert, or escalate it. That is maker work, and an agent is well suited to it — it is fast and it does not get tired on alert number four hundred.
What the agent must not do is act on its own recommendation. Closing the alert, or filing the suspicious-activity report, is the checker's decision, reserved for a different, authorized actor. The maker-checker control draws the line exactly there: the agent can prepare the case all day, but a separated party signs the outcome. We walk through that flow in AML alert triage with AI agents.
Why the framing matters now
It would be convenient to wait for a regulator to publish a template for "agent controls." None exists. In April 2026 agentic AI was scoped out of the main US model-risk guidance, and no replacement template has arrived. But the predicate rules — the ones that already require a separated approver for a batch release, a reported transaction, or a signed record — never moved. They govern the action regardless of whether a human or an agent prepared it.
So the question an examiner or an opposing lawyer will ask is not "did you follow the agent rulebook." It is the same question maker-checker has always answered: who prepared this, who approved it, were they actually separate, and can you prove the record is intact. An agent that approves its own work has no answer to give.
MakerChecker enforces maker-checker structurally, so the same agent cannot prepare and approve one run. See how it works, or book a demo to watch an agent get blocked from approving its own work — live.