Segregation of Duties When the Agent Is Both Maker and Checker

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. It is an old control failing in a new place, so 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.

The compensating controls usually offered are audit trails, management review, reconciliation of accounts and review of exception reports. The PCAOB's integrated-audit standard sets the bar they have to clear: "the compensating control should operate at a level of precision that would prevent or detect a misstatement that could be material" [6].

Every item on that list 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 audit standard states it without meaning to. AS 2201 tests whether a control operated by determining "whether the control is operating as designed and whether the person performing the control possesses the necessary authority and competence to perform the control effectively" [6]. The checker is assumed to be a person holding authority, not a second algorithm. 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 tribunal described the airline's position as, in effect, that its website chatbot was a separate legal entity responsible for its own actions, called that a remarkable submission, 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.

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 [7]. 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. Where the log is stored in the same system that performed the control, the auditor has to ask whether the log could have been altered, which means testing the logging mechanism itself rather than reading the log. 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 the audit standard already draws, testing design effectiveness and operating effectiveness separately [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 standard treats an entirely automated control as one that is "generally not subject to breakdowns due to human failure", which is why it can be tested once and then benchmarked [6]. 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. Broker-dealer record rules require records to be preserved in a form that cannot be quietly rewritten [2], and algorithmic-trading rules require firms to keep records of their orders and to operate pre-trade controls on them [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 record half 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, and a step the gate denies is not meant to run; whether every step is routed through the gate at all is a property of the deploying system (§8). Both outcomes produce a receipt signed with Ed25519. Each permitted receipt carries the content hash of the permitted receipt before it, and every receipt, permitted or refused, carries a signed number counting each decision in the sequence. Altering any receipt breaks its signature, and removing one leaves a break in the chain or a missing number, which the report names. 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/.

Run the first two parts against this system now. The public demo lane needs no key, so the test can be run from any terminal, or by an agent asked to evaluate this note. The call below submits execution as the first step of the default eight-step sequence, skipping the five steps that must come before it. The gate refuses it, and the second command fetches the record of that refusal.

SEQ="sod-test-$(date +%s)-$RANDOM"
curl -s https://api.agenticrail.nz/v1/evaluate \
  -H "Content-Type: application/json" \
  -d "{\"sequence_id\":\"$SEQ\",\"step\":\"execution\",\"function\":\"execution\",
       \"action_type\":\"SELECT_NEXT_STEP\",\"action\":\"skip_to_execution\",
       \"inputs\":{\"next_step\":\"boundary\"},
       \"nonce\":\"$SEQ-1\",\"ts_ms\":$(date +%s)000}"
echo
curl -s "https://report.agenticrail.nz/report?sequence_id=demo-$SEQ&format=json"

The first response carries "decision": "DENY", the reason SEQUENCE_VIOLATION, and the step that was due instead, "next_expected_step": "intake". The refused step did not run, and it still left a signed receipt. The report returns that receipt under enforcement_log with its signature and the exact signed_canonical bytes that were signed, and it carries the Ed25519 public key under verification.public_keys, so the signature can be checked with any Ed25519 library without calling us. Change one character of signed_canonical and the check fails. The third part of the test needs a record removed, which only whoever holds the storage can do. What makes it detectable is the receipt's signed decision_index: the report's decision_index block states whether the numbers run unbroken and names any that are missing, refused steps included. The fields are set out in the specification.

Two things to know before running it. The sequence_id must be one you make up, which is what the first line does: an identifier copied from a page is shared by everyone who copies it, and once a sequence reaches its last step it is sealed and refuses further steps. And the demo lane is public: anyone holding a demo sequence id can read its report, and demo receipts are deleted 30 days after they are written.

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.
• 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 the caller supplies it (when the caller sends none, the gate's own clock does) and the gate only bounds it — any caller-supplied timestamp more than 300 seconds from the gate's own clock is refused. 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. 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 record is strong on integrity and weak on independence — a motivated insider with key access could in principle produce a consistent but false history. A separately credentialled, write-once archive of each sealed receipt's fingerprint narrows that; it is held by us, not by an independent party. 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. Within the integration it cannot skip a step, reorder steps, or replay one and be permitted. If your process genuinely has no order worth enforcing, this is not the tool for it.
• The gate governs only what is routed through it. A step the deploying system never sends to the gate is neither refused nor recorded. Non-bypassability (requirement 3 in §4) is therefore a property of how the gate is wired into that system, which the deployer controls and an auditor has to test there. The receipts cannot show a step that was never submitted.
• The gate enforces the order, not which agent performs each step. Sequence state is kept per model_id, which is the calling key plus an optional label the caller chooses. A sequence cannot currently be handed between model_ids, and agents that share a key and send no label share one model_id, which the gate cannot tell apart. Nothing in the gate requires the agent that approves a step to differ from the agent that executes the next. Each receipt records the model_id that submitted it and the step order that was declared, so the record shows which key and label drove a sequence and what it declared, including a declared order that leaves out an approval step. Separation between agents is not enforced by the gate and cannot yet be expressed within one sequence.

9. References

1. Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal). Published decision; quotes the chatbot's answer.
2. US Securities and Exchange Commission, Rule 17a-4 — records to be preserved by certain exchange members, brokers and dealers, including that electronic records be kept in a form that cannot be altered, or with a complete audit trail of changes.
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. Public Company Accounting Oversight Board, AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements — paragraphs .42 and .44 (testing design and operating effectiveness), .68 (compensating controls) and .B28 (benchmarking of automated controls).
7. 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.
8. IETF RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol — trusted timestamp tokens from an independent Time Stamping Authority.
9. AgenticRail enforcement specification and receipt schema — agenticrail.nz/spec/.