Four-Eyes and Segregation of Duties for AI Agents

Four-eyes survives an AI agent only when the second examination is independent of the first — and a person approving what the agent put in front of them is not independent, because their view of the facts is the agent's view of the facts. The control was never two clicks. It was two people looking at the same reality by different routes, and an agent that prepares the item and the evidence collapses those routes into one.

The textbook description is more forgiving: a maker and a checker, one prepares, another approves, and no single person completes a sensitive action alone. That description survives an agent perfectly well on paper, which is exactly the problem. Every box is still ticked. The independence it was standing in for has quietly gone.

I have spent eighteen years building and reviewing these controls in SAP FI and treasury — release strategies, approval limits, dual release on payments, the segregation rules on the master data behind them. What follows is that machinery pointed at a non-human maker, including the parts that hold and the parts that do not.

What four-eyes was actually buying

It is worth being precise, because the vaguer version is what fails silently.

The control exists to make a single error or a single dishonest act insufficient. Two conditions do that work: the two parties must examine the same transaction from evidence they reached independently, and the second must carry a consequence for approving it. Neither condition mentions how many clicks there are.

Human four-eyes already degrades when those conditions lapse — the approver who sees only what the preparer's cover note says is rubber-stamping, and every controller knows it. What changes with an agent is that the degradation stops being a habit and becomes structural. The agent assembles the item, selects the supporting evidence, and renders the screen the approver reads. There is no second route to the facts unless someone built one.

"

Four-eyes was never two clicks. It was two routes to the same facts — and an agent that prepares the evidence has quietly merged them into one.

Making the second examination independent again

Three things restore the property, in ascending order of effort.

Show the source, not the summary. The approver's screen should contain the underlying record — the invoice image, the statement line, the contract clause, the prior document — reachable in one action, not the agent's paraphrase of it. If reaching the source takes three systems and a colleague, nobody will, and you have designed rubber-stamping.

Give the approver a fact the agent did not supply. The strongest form of independence is a second source: the counterparty's own confirmation, the bank's statement, a system the agent cannot write to. In treasury this is routine — a payment is checked against a confirmation that arrived by a different channel entirely, and that is the design to copy.

Make the approver's own question explicit. Not "do you approve", which invites yes. "Does the bank detail on this payment match the one on file, and when was it last changed, and by whom?" A question with a factual answer is a control; a confirmation dialog is a formality. This is the same reason the release path, not the model, is where payment authority lives.

Can the agent be the second pair of eyes?

Separately worth answering, because it is where most of the enthusiasm is.

As a detective check, an agent as reviewer is genuinely valuable and I would use one. It is tireless, consistent, and good at the things people skim on the fortieth item of an afternoon: the duplicate, the changed bank detail, the amount that is plausible but out of pattern. Adding a machine reviewer catches a real class of error.

As the second party in a four-eyes control, no — and the reason is not model quality. The control needs a party who can be asked afterwards why they approved and who bears the consequence of the answer. That is what makes the second signature worth anything. A model cannot hold a consequence, so an approval attributed to one is an approval attributed to nobody, which is the failure mode agent identity exists to prevent.

So the workable arrangement is three-part, not two: the agent proposes, a second agent or deterministic check screens, and a human with independent evidence releases. The machine review adds coverage. It does not replace the signature.

Segregation of duties: the union problem

The related control fails in a different and more mechanical way.

Segregation of duties is a statement about combinations, not about any single action. Create a vendor, and release a payment to it. Enter an invoice, and approve it. Maintain a bank detail, and initiate a transfer against it. A ruleset does not forbid either half; it forbids one identity holding both.

An agent asked to carry a process end to end needs the union of every role that process touches. Each authorization check passes. The combination is the one the ruleset was written to prevent, assembled inside a single non-human identity — and it does not appear in the access review, because technical users are usually excluded from the human one. That is the same failure an agent posting in SAP produces on the document, arriving all at once rather than accumulating over five years of access creep.

The test is available to you today and costs an afternoon: run the agent's composite authorizations through the segregation-of-duties ruleset you already own, as though it were a person. The pairs worth checking first in a finance landscape:

A conflict this returns is a design defect, not an exception to be approved. The remedy is to split the agent — two identities with two operation lists — or to move the second half behind a human release. Both are cheaper than the mitigating-control paperwork the alternative generates every year afterwards.

The master-data half deserves emphasis because it is consistently underrated. In treasury the settlement account matters more than the deal, and the business partner and standing-instruction data behind a payment is where the loss actually happens. An agent with write access there needs the four-eyes control that data already carries, not a new one invented in the agent layer.

Does the agent's log count as the evidence?

Increasingly people accept that raw model logs are not automatically an audit trail. The more useful question is what a financial audit trail additionally requires, because that bar is higher and older than anything written about agents.

Three properties, none of which a debug log has by default:

Retention on your schedule, not the platform's. Statutory retention for accounting records runs to years, and it is measured against your obligation, not the log-rotation policy of whichever agent platform you were using at the time. If the record has to survive a change of vendor, it cannot live only in the vendor.

Tamper evidence. An auditor needs to know the record was not altered after the fact. That is the point of change documents in an ERP, and it is why an appended text file is not equivalent.

Re-performance. This is the one that surprises teams. An auditor does not merely read the record; they re-perform the control — take the same inputs, apply the same rule, and check they reach the same conclusion. For a deterministic check that is straightforward. For a model output it is not, which is a strong argument for putting the consequential decision in a deterministic policy layer whose behaviour can be re-performed, and letting the model do the part that is being reviewed rather than the part being relied on.

Practically, that means capturing at the grain of the action: what was proposed, on what inputs, which rule version evaluated it, what the deterministic check returned, who released it and when. Audit trails and logging has the general shape; the addition here is the rule version, because a control you cannot version is a control you cannot re-perform six months later.

What I would decide

Keep the second signature human, and make sure the human sees the source rather than the summary — ideally a fact the agent did not supply. Use a machine reviewer as an extra layer, never as one of the two eyes. Run the agent's composite through the existing segregation-of-duties ruleset and split the agent where it conflicts. Put the consequential decision behind a deterministic check that can be re-performed. And capture the rule version alongside the decision, because that is the field an auditor will ask for and the one nobody logs.

None of that is new control design. It is the control design that already exists, applied honestly to a participant that happens to be very fast and cannot be held responsible for anything.

See also security boundaries for enterprise AI agents and segregation of duties in treasury systems.