Maker-Checker
An internal control principle originating in the financial industry that requires the initiator and the approver of a sensitive operation to be different parties. By separating duties, it prevents single points of failure and fraud. The principle has been adopted in AI agent governance as an authorization guardrail for high-risk actions, ensuring that consequential operations receive independent review before execution.
Timeline (last 90 days)
Maker-Checker (the four-eyes principle) requires that the person proposing an action and the person approving the action must be two different entities.
Specific G3 examples requiring an independent checker include: deleting production data, transferring funds above a value threshold, deploying to production, sending external communications on behalf of the organization, modifying access controls or credentials, and signing or submitting anything legally binding.
The checker needs four A's: authority, awareness, ability, and accountability; without them, separation of duties cannot function effectively.
When implementing Maker-Checker, approval must be enforced where the action is actually executed, not in the agent's own reasoning or in the client UI, and each approval must be bound to a specific action, a specific payload, and single use.
All Facts (4)
Maker-Checker (the four-eyes principle) requires that the person proposing an action and the person approving the action must be two different entities.
50%UnverifiedSpecific G3 examples requiring an independent checker include: deleting production data, transferring funds above a value threshold, deploying to production, sending external communications on behalf of the organization, modifying access controls or credentials, and signing or submitting anything legally binding.
50%UnverifiedThe checker needs four A's: authority, awareness, ability, and accountability; without them, separation of duties cannot function effectively.
50%UnverifiedWhen implementing Maker-Checker, approval must be enforced where the action is actually executed, not in the agent's own reasoning or in the client UI, and each approval must be bound to a specific action, a specific payload, and single use.
50%