Glossary entry

What is maker-checker for AI?

Maker-checker is the banking control where one entity originates a transaction and a separate entity authorizes it. Applied to AI agents, the agent is the maker and a human (or an independent system) is the checker. Two distinct identities have to agree before the action executes. It is the principle behind most pre-action approval flows for agents.

Key facts

  • Borrowed from banking and accounting, where it is also called the four-eyes principle.
  • Used by teams running agents that move money, change identity, modify schemas, or send outbound communications.
  • Without it, the agent can become both originator and authorizer for sensitive actions: the antithesis of segregation of duties.
  • Veto encodes maker-checker as a policy outcome with a separate approver identity captured on governed decisions.

In plain English

Imagine a wire transfer at a bank. The teller can prepare the transfer, fill in the recipient and amount, attach the documentation. The teller cannot send it. A second employee, the checker, reviews and authorizes. The split exists because one person who can both originate and send a transfer is one person away from emptying the account.

Agents are tellers that do not go home. They can originate actions faster than the review loop, and they make mistakes nobody is going to catch by hand. Maker-checker for AI keeps the originator role with the agent, which is what agents are good at, and gives the checker role to a human or an independent verification service. Two identities, two logs, one decision.

How it works

In a Veto stack, maker-checker is a policy outcome. A rule says require_approval for actions over a threshold. When the rule fires, the call is held; the agent's request is sent to the configured checker channel; the checker's response, approve or deny, is recorded with their identity, time, and the policy snapshot. The two log entries (maker and checker) are the decision records.

The pattern works for agent-to-agent flows too. The maker is one agent; the checker is a second agent with a different identity, a different policy, and ideally a different model. The independence between the two is what makes the control meaningful: the same model approving its own output is not maker-checker, it is rubber-stamping.

# YAML: maker-checker on outbound payments
- name: payments_require_separate_approver
  match:
    tool: payment.send
  rules:
    - if: args.amount_cents >= 100000
      then: require_approval
      approvers:
        roles: ["finance_approver"]
        deny_self: true  # the maker cannot approve their own action

Operational consequence

Maker-checker is one of the oldest controls in finance, and it works because it does not depend on either party being honest or correct. It depends on two parties having to agree. For AI agents, where any single agent can be jailbroken or hallucinate, that property is exactly what you want. The control survives the agent being wrong.

Regulators have already imported the principle into AI guidance. EU AI Act Article 14 requires "effective human oversight" for high-risk systems and lists the ability to refuse or override an output as a core property. NIST AI RMF's MANAGE function expects organizations to identify which decisions need human authorization. SOC 2 CC6 and SOX expect segregation of duties for sensitive operations. Maker-checker can support those reviews.

Related terms

Human Veto Button

The control that makes maker-checker workable in real time.

Pre-Action Approval

The implementation pattern for maker-checker on agents.

Financial agents

Where maker-checker is most directly required.

SOC 2 evidence

CC6 expects segregation of duties; maker-checker creates the evidence record.

FAQ

Where does maker-checker come from?⌄

Banking and accounting, where it is also called the four-eyes principle or segregation of duties. The rule is older than computers: one person initiates a transaction, a different person approves it. The point is not redundancy. It is that two separate entities have to agree before money moves.

Is the AI the maker, the checker, or both?⌄

Default to the agent as the maker. It proposes the action. A human is the checker. Some workflows reverse the roles for low-stakes decisions, the human writes a draft and the agent reviews it for policy violations. The pattern works in either direction as long as the two entities are independent.

Does not every approval queue do this?⌄

Yes, that is the implementation. Maker-checker is the principle; pre-action approval queues are how you do it for AI agents. The principle adds two extras: a clear separation between the maker identity and the checker identity, and a reviewable log of both sides.

How does this support compliance evidence?⌄

SOC 2 CC6 expects segregation of duties for sensitive operations. SOX requires it for financial controls. HIPAA expects it for PHI changes. Maker-checker is the standard pattern for that evidence, and it ports cleanly to AI agents once you treat the agent as one of the two entities.

Bring a banking-grade control to your agent stack.

Sign upInstall the SDK