Segregation of Duties When the Agent Is Both Maker and Checker

Most writing about controlling AI agents invents new vocabulary for the problem. This note does the opposite. An autonomous agent with tool access breaks a control that has existed in accounting and banking for longer than computing has: segregation of duties. The party that authorises an action must not be the party that performs it. An agent decides and then acts, so it is maker and checker in the same process. That is not a new category of risk requiring a new discipline. It is an old control failing in a new place — which is fortunate, because it means the people who already test that control have the vocabulary, the mandate and the budget to test this one. This note sets out what they ask for, why an audit log usually does not answer it, and what a refused step has to leave behind to count as evidence.

1. Scope

This is a controls note, not legal or audit advice, and not a compliance claim. It takes no position on whether any particular process should be automated. It describes a structural gap between what autonomous software does and what control frameworks assume, and it identifies what would close that gap. Where a regime is named it is named as an example of an existing duty, not as a claim that any product satisfies it. Throughout, one distinction is held: a record is something a system writes about itself; evidence is a contemporaneous record that a party outside the operating system can verify without trusting that system. The gap described here is in the second.

2. The Control That Predates the Technology

Segregation of duties (SoD) is the requirement that no single actor controls an entire transaction from initiation to completion. In banking it is usually called maker-checker; in European practice, the four-eyes principle. The control appears in every serious framework of IT general controls (ITGC) and application controls, and it is one of the first things an internal or external auditor tests, because almost every fraud and most large operational errors involve one party holding both roles.

It survives because it does not depend on anyone being trustworthy or competent. It is structural. The checker does not need to be smarter than the maker, or even to understand the transaction fully. The checker only needs to be separate, and to be unable to be overruled by the maker.

Where SoD genuinely cannot be achieved — a small team, an unavoidable single administrator — audit practice does not simply waive it. It requires a compensating control: something else that constrains the actor, plus evidence that the something else actually operated. The compensating control is accepted only when it produces its own record.

It is worth noting exactly what the standards list as acceptable compensating controls. ISACA's guidance names audit trails, management review and exception reports [6]. The PCAOB's integrated-audit standard names supervisory review of detailed activities, reconciliation of accounts, and review of exception reports [7]. The IIA's guidance on segregation of duties names transaction-level audit trails, independent reconciliation and supervisory review of exception reports [8].

Every item on those lists is detective rather than preventive, and every one of them is performed after the transaction has already occurred. That is a reasonable design when the thing being constrained is a person, because a person can be disciplined, retrained or dismissed, and the loss can often be reversed. It is a weaker design when the thing being constrained is software that can repeat the same action several thousand times before the exception report is read.

3. The Failure Shape — an agent occupies both roles

Give an autonomous agent a set of tools and the authority to call them, and the architecture looks like this: the agent interprets a goal, selects an action, and issues the call. Nothing between the selection and the call is separate from the thing doing the selecting. The agent is maker and checker in one process.

The usual mitigations do not restore separation:

• A confirmation prompt in the system prompt asks the model to seek approval. The model may comply. It is an instruction to the maker, not a separate checker, and it is not enforced anywhere outside the model's own reasoning.
• Human-in-the-loop approval does restore separation, and it is the right answer for high-value actions. It also removes the throughput that motivated automation, so it tends to be applied narrowly and then quietly widened.
• Application-level conditionals written by the same team that ships the agent are real controls, but the auditor's question is not whether they exist. It is whether they were in force at the moment of action and could not be bypassed.
• Post-hoc logging records what the agent did. It cannot record what the agent was prevented from doing, because nothing prevented anything.

There is a more precise way to state the problem, and the guidance states it without meaning to. The IIA's segregation-of-duties guidance contemplates the case where a single system module performs both authorisation and execution, and offers supervisory review of exception reports as the remedy — where the supervisory review is understood to be performed by a person holding independent authority, not by a second algorithm [8]. The assumption is reasonable and almost invisible, because until recently there was no other kind of checker available.

That assumption is the thing an autonomous agent breaks. Not the rule. The rule survives intact. What fails is the unstated premise that somewhere in the loop there is a party with independent authority who is not the party being checked.

The liability position is not ambiguous while this is unresolved. In Moffatt v. Air Canada (2024 BCCRT 149) the airline argued that its website chatbot was a separate legal entity responsible for its own statements. The tribunal rejected the argument and held the company to what its software said [1]. Platform and model providers disclaim execution liability in their standard enterprise terms. The deploying organisation carries the exposure, and currently carries it without an insurance backstop.

4. What the Auditor Actually Asks For

The question that decides an ITGC or application-controls test is narrower than it first appears, and it is not "is there a log?" It is closer to this:

Show me that the control was in force at the time of the transaction, that this specific transaction passed through it, that it could not have been bypassed, and that the record you are showing me was not produced by the thing the control was constraining.

That sentence contains four distinct requirements, and conventional agent tooling usually satisfies only the first two:

1. Existence. The control is documented and configured. Easy to evidence; usually a screenshot or a policy file.
2. Coverage. This transaction went through it. Evidenced by sampling a population of records.
3. Non-bypassability. There was no path around it. The IIA's application-controls guidance puts this as verifying that the control is in the production path and cannot be circumvented [9]. Hard to evidence with application code, because the same team can deploy a change; hard to evidence with a system prompt, because the model can decline to follow it.
4. Independence of the record. The evidence was not written by the party being examined. ISACA's guidance is direct about this: where the log is stored in the same system that performed the control, the auditor must assess whether the log could have been manipulated, and must therefore test the integrity of the logging mechanism itself [6]. This is the requirement that separates a log from a record with non-repudiation properties, and it is the one most often skipped.

The gap between requirement 1 and requirement 4 is the whole subject of this note. It is the difference between evidence that a control was configured and evidence that a control operated — a distinction that ISACA's audit guidance already draws explicitly, requiring a system-generated entry showing the control executed at the moment of the transaction, with an outcome [6]. Auditors already have this vocabulary. It is not something the AI industry needs to invent, and the industry would do better to adopt it than to replace it.

The same standards also allow an auditor to test an automated control's operating effectiveness by examining system-generated data, while still requiring that the evidence be sufficient and appropriate to support the opinion [7]. Where the automated control is the only check on an autonomous agent's action, evidence produced by that agent about itself does not meet the independence the test assumes.

5. Three States of a Control

It is useful to grade a control on what it leaves behind, because the three states look identical in a design document and behave completely differently under examination.

Documented. The rule is written down. Policy says the agent must not issue a payment above a threshold without approval. Nothing technically prevents it. Evidence available: the policy. This satisfies requirement 1 only.

Enforced. The rule is executed by software that sits between the decision and the action, and the action does not occur when the rule refuses. Evidence available: the code, plus whatever the system chose to log. This satisfies requirements 1 to 3, and fails 4 when the enforcing system is operated by, and its records are writable by, the party being examined.

Evidenced. The rule is enforced, and each decision — permission and refusal alike — produces a record that a third party can verify without access to the operating system, and which cannot be silently altered afterwards without the alteration being detectable. This is the state that answers all four requirements, and it is the state that continuous controls monitoring and chain of custody vocabulary is reaching for.

Note what changes between the second and third states. Nothing about the agent improves. What changes is that the control's operation becomes examinable by someone who was not present and does not have to take anyone's word for it.

6. Who Already Owes This Duty

Sectors that keep records of automated actions are not doing so voluntarily, and the duty predates autonomous agents by decades. Financial services record-keeping and algorithmic-trading control rules require firms to be able to reconstruct the order of decisions and to demonstrate that pre-trade controls were not bypassed [2][3]. Model risk management guidance in banking requires documented boundaries and effective challenge for models used in decisions [4]. Regulated manufacturing and clinical records rules require that automated system steps follow a predetermined sequence, with audit trails that the operator cannot quietly rewrite [5].

None of those rules mention AI agents, and none of them need to. They are drafted in terms of automated systems and records, and an agent is an automated system. The obligation already applies; what has changed is that the systems now being deployed under it cannot produce the evidence it assumes.

This is also why the buyer for this problem is often not the team that deployed the agent. It is the person who has to sign that the controls operated: an internal audit lead, a risk officer, a controls owner preparing for an external audit.

7. The Instrument, and a Test Anyone Can Run

AgenticRail is one implementation of the third state. It sits in front of the agent as a separate service. Each step is submitted before it runs and returns ALLOW or DENY. A denied step does not execute. Both outcomes produce a receipt signed with Ed25519, and each receipt carries the content hash of its predecessor, so removing or altering one leaves a detectable break in the chain. A sequence is sealed at its final step and cannot afterwards be reopened without that break becoming visible.

The part that matters for requirement 4 is that verification does not require us. Each receipt is published with the exact byte string that was signed, so anyone holding the public key can verify it offline, with no call back to our infrastructure. The public keys are at /spec/receipt-public-keys.json.

The five-minute test. Take any system that claims to control an AI agent, including this one, and ask for three things: a record of a step that was refused, not merely one that succeeded; the exact bytes that were signed, so the signature can be checked independently; and a demonstration that removing one record from the middle of a sequence is detectable. A system that cannot produce the first has logging rather than enforcement. A system that cannot produce the second is asking to be trusted rather than verified. Our verification tool is at report.agenticrail.nz/report and the specification is at /spec/.

8. A Deliberate Boundary — what this does not do

This section exists because a controls note that only lists strengths is marketing. Every limit below is a real one.

• It is not a compliance certification and does not make anyone compliant with anything. No rule named in §6 is satisfied by installing software. They are satisfied by an organisation's controls, of which a gate is at most one.
• We hold no SOC 2 Type II report and no ISO 27001 or ISO 42001 certification, and we claim none anywhere. For procurement in many regulated environments that is a genuine barrier, and we would rather state it here than have it discovered later.
• A receipt does not prove the decision was right. It establishes that a step was permitted, in a declared order, at a known position in a chain. If the rule itself was wrong, the receipt faithfully records a wrong thing being permitted. What it does is narrow a dispute from what happened to whether the rule was correct.
• The timestamp is signed but self-asserted, and the remedy is known and not built. The signature covers the time value, so it cannot be altered afterwards without breaking verification. It does not establish that the value is true, because we generate it: it is a record of when, not proof of when. The established answer is a timestamp token from an independent Time Stamping Authority under RFC 3161, which anchors the record in time against a party with no stake in it. We have not implemented that. Anyone weighing this record as evidence should treat the time as unattested until we do.
• The service is hosted, and we hold the signing keys. This is the limit that matters most and it deserves stating without softening. A signature proves that a record has not been altered since signing, and that it came from the holder of the key. It does not prove that an independent party witnessed the event. Where the key is held by the party relying on the record, the honest description is that the record is strong on integrity and weak on independence — a motivated insider with key access could in principle produce a consistent but false history. Separately held copies of sealed receipts narrow that; hardware-held keys with logged signing operations would narrow it further. Neither eliminates it. Take "cryptographically signed" as the beginning of the question rather than the end of it.
• A gate constrains order and permission, not reasoning. The agent still decides what to do within a step. It cannot skip a step, reorder steps, or replay one. If your process genuinely has no order worth enforcing, this is not the tool for it.

9. References

1. Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal). Published decision; includes the transcript of the exchange.
2. US Securities and Exchange Commission, Rule 17a-4 — records to be preserved by certain exchange members, brokers and dealers.
3. MiFID II Regulatory Technical Standard 6 (Commission Delegated Regulation (EU) 2017/589) — organisational requirements for investment firms engaged in algorithmic trading, including records of orders and pre-trade controls.
4. Board of Governors of the Federal Reserve System / OCC, Supervisory Letter SR 11-7 — Guidance on Model Risk Management.
5. US Food and Drug Administration, 21 CFR Part 11 — Electronic Records; Electronic Signatures.
6. ISACA — COBIT governance and management objectives, and the CISA Review Manual, on testing automated controls: configuration versus operation, compensating controls where segregation of duties cannot be fully achieved, and assessing the integrity of a log held in the system that performed the control.
7. Public Company Accounting Oversight Board, AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements — compensating controls for a lack of segregation of duties, and the use of system-generated data as evidence of operating effectiveness.
8. Institute of Internal Auditors, Global Technology Audit Guide 13, Auditing for Segregation of Duties — segregation-of-duties conflicts arising where a single system module performs both authorisation and execution, and the compensating controls contemplated.
9. Institute of Internal Auditors, Global Technology Audit Guide 8, Auditing Application Controls — verifying that an application control sits in the production path and cannot be bypassed.
10. IETF RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol — trusted timestamp tokens from an independent Time Stamping Authority.
11. AgenticRail enforcement specification and receipt schema — agenticrail.nz/spec/.