How do I require two independent human approvals (four-eyes / maker-checker) before an AI agent takes a high-impact action?

What should I check, step by step?

1. List the action classes that need four-eyes: spend over a threshold, permission or scope changes, production writes, credential or key issuance, irreversible deletes. Everything else can stay single-approver or auto.

2. Build one action object the agent cannot edit after the request: tool name, RFC 8785 (JCS) canonical args (then sha256), target or environment, amount and currency if any, policy_id and policy_version, and a requester_id that is not eligible to approve.
3. Open two approval requests bound to that same action hash (or one request that requires n-of-m with n=2). Reject any decision where approver_id equals requester_id or equals the other approver.
4. Show the second approver the first decision (who, when, note) and the same preview the first person saw. Independent eyes means a second look at the same facts, not a rubber stamp on a different summary.
5. Expire the pending request (for example 15–60 minutes). After expiry, deny execution and require a fresh dual approval; never let an old first-yes pair with a new second-yes on a changed action.
6. At execution, recompute the action hash and verify both receipts with verify_human_approval against that hash. Fail closed if either receipt is missing, expired, for a different hash, or from the same person.
7. Write both decisions (approve or deny), plus expiries, to an append-only ledger outside the agent's credentials. Denials and abandoned requests matter as much as approvals.
8. Drill it: attempt self-approval, attempt two approvals from one person with two accounts, change args between the two yeses, and confirm the gate blocks every case.

Why is one human approval not enough for high-impact AI agent actions?

A single approver is a single point of failure: stolen session, rushed click, social engineering, or the same person who asked the agent to act approving their own request. Banks and payment firms already treat that as unacceptable for money movement; agents that can spend, change access or write production deserve the same bar.

• NIST SP 800-53 Rev. 5 AC-5 (separation of duties) and AC-3(2) (dual authorization) are the control language for this: divide duties so one person cannot complete a sensitive operation alone, and require two authorizations for designated actions. Maker-checker / four-eyes is the operational pattern.
• How to require human approval before an AI agent spends money and how to require human confirmation before MCP write tools run cover the single-approver gate. This page is the dual-control layer on top for the actions where one person is not enough.

How do I bind two independent approvals to the same agent action hash?

Independence is worthless if the two people approved different things. Canonicalize the tool arguments (RFC 8785 JCS), hash them, and put tool, args_sha256, target, amount and policy_version into the action object both receipts must match.

• The second approver must see the first receipt (approver_id, decided_at, note) and the same evidence_ref / preview. If the first person approved a $500 refund and the agent quietly changes the amount, the second look and the hash check both catch it.
• request_human_approval on Rightshold hashes the action you send; decide_human_approval (owner account key) returns a signed, timestamped decision receipt; verify_human_approval is free and fails when the tool, args or other bound fields no longer match. For four-eyes, require two distinct receipts for the same action before the tool runs.

How do I record dual control for an AI agent outside the agent?

Keep both receipts, the requester_id, the policy version and the final execution decision in a store the agent's API key cannot UPDATE or DELETE. An agent that can edit its own approval history can invent a second yes.

• Rightshold's ledger is hash-chained and signed; ledger_verify recomputes every payload, leaf and block hash without a key. record_ai_run can seal what the model produced for the same call so the dual-approval trail and the model output stay linked.
• How to record a named approver and policy version in a tamper-evident entry for every agent approval covers the per-approval entry shape; this page requires two of those entries, from different people, on one action hash.