How to run four-eyes checks on operational changes with an AI agent

The agent can be the maker, or the checker's assistant, but never both eyes. It prepares the change from the request, compares it field by field with the evidence, and shows the checker every difference. A person who did not make the change approves it after seeing the source. The record proves maker and checker differed.

What is a four-eyes check, and where does it apply?

The four-eyes principle says that a sensitive action needs two people: one to make it and another to check and approve it. In operations, it applies to changes to standing data and configuration that would be costly if wrong or abused: a supplier's bank details, a fee table, an interest rate, a customer's limit, a user's access rights, a product parameter.

The control owner, usually in operations or finance, owns the four-eyes rule for each change type. Makers are the staff who prepare changes. Checkers are named people with authority to approve them. Risk and audit test that the control works.

What does the agent prepare, and what does a person approve?

1. Agent, depth 1: reads the change request and its supporting evidence: a signed form, an approved rate decision, a supplier letter, an access request.
2. Agent, depth 1: checks the request's authority. Was the requester entitled to ask? Is the decision behind it approved by the right body?
3. Agent, depth 2: prepares the change in the target system's pending state, as maker. Nothing is live until checked.
4. Agent, depth 1: pre-checks the prepared change against the evidence, field by field, and lists every difference, every field changed beyond those requested, and every value outside normal ranges.
5. Agent, depth 1: verifies independent evidence where the rule requires it, for example confirming a supplier's new bank details by a call to a number already on file, which a person makes and records.
6. Person, checker: reviews the change and the source evidence, not just the agent's summary, and approves or rejects.
7. System: applies the approved change. The agent does not make it live.
8. Agent, depth 1: confirms the live value matches what was approved, after the change takes effect.

Where a person is the maker, the agent's role is only the pre-check, step 4, as an aid to the checker.

Why can't the agent be both eyes?

The point of four eyes is independence: two separate judgements, so that one person's error or dishonesty is caught by the other. If the agent prepares the change and also performs the check, there is one judgement, made twice by the same system with the same blind spots. If the agent's understanding of the request is wrong, its check will confirm the wrong change.

The same applies to two agents built on the same brief and sources. Different names do not make them independent. The second pair of eyes must be a person, or at least a check that does not share the maker's inputs.

Where does it usually go wrong?

The checker reads only the summary. The agent's pre-check is clear and confident, so the checker approves without opening the source. If the agent misread the request, the summary repeats the mistake. The approval screen should show the source evidence beside the change, and the record should show whether the checker opened it.

Maker and checker are the same person. A person prepares a change, the agent pre-checks it, and the same person approves it under a shared login or a second role. Enforce separation in the system, not in the procedure: the approver's identity must differ from the maker's, and the agent's identity counts as the maker when it prepares.

Bank detail changes are verified by email. The most common fraud against payment teams is a request to change a supplier's or employee's bank account. Any confirmation that arrives through the same channel as the request is worthless. The agent should treat the request as external, and require the call-back to a number already on file.

Batch approvals. A checker approves forty changes at once at the end of the day. The control exists on paper. Show changes one at a time for high-risk types, and measure time per approval.

Changes are made live outside the pending state. Someone with direct access edits a fee table without a pending change, and the four-eyes record never sees it. The end-of-day check should compare live configuration with the approved change log; this fits naturally into end-of-day operations checks.

Which controls apply, and what evidence does each leave?

Distinct maker and checker identities. Evidence: both identities on each change, with the system's enforcement of separation.

Source evidence presented to the checker. Evidence: what was displayed and whether it was opened.

Pre-check results. Evidence: the list of differences and outliers the agent produced.

Independent verification where required. Evidence: who made the call, to which number, and the outcome.

Post-change confirmation. Evidence: the live value read after the change, matched to the approval.

Rejected changes kept. Evidence: every rejection and its reason, which is often where attempted fraud shows up.

What should you measure?

• Changes rejected by checkers, and why. A checker who never rejects anything needs a closer look.
• Pre-check findings that led to rejection or correction.
• Time per approval, by change type.
• Live values that differ from approved values. The target is none.
• Changes made outside the four-eyes process, found by comparison.

A failed change that reaches production is an incident; log it through the same route as any other, as set out in logging and triaging operational incidents.

Where Pryme fits

In Pryme, a change the agent prepares is held for a named checker, and the verdict records the agent as maker so the same identity cannot approve it. A bank detail change from an inbound email is external and cannot authorise anything. The deployment sequence is the one in train, shadow, certify, widen.