For CFOs, controllers and heads of finance at companies of 50 to 500 people who put AI agents on invoices, bank lines or payment runs, and must now tell their auditor who controls the agent.
An AI agent enforces segregation of duties by checking every transaction, whoever entered it, which no human reviewer can do at volume. Segregation of duties means no single actor can authorize, record and pay for the same transaction. The agent keeps that rule only if it is bound by it too: it checks and flags, but it cannot approve its own findings, release payments, change supplier bank details or edit its own rules.
Need only the definition? See our segregation of duties entry.
Key takeaways
- An AI agent enforces segregation of duties at the transaction level: it checks every invoice or bank line against the rules, whoever keyed it, where a human checker samples.
- NIST SP 800-53 applies least privilege to "processes acting on behalf of users", so an AI agent needs its own set of permissions, as narrow as a person's.
- Authorization belongs in the ERP or the bank, not in the agent's judgment: OWASP's 2025 guidance on AI applications says to enforce it in downstream systems.
- Approving exceptions, releasing payments, changing supplier bank details and changing the agent's own rules stay with named people who do not review their own work.
- Phacet's fake IBAN agent blocks a suspicious bank detail change until an approver you name, such as the CFO or treasurer, validates it, and records the decision in the audit trail.
Last updated: September 27, 2026
Can an AI agent enforce segregation of duties?
Yes, on the checking side of the process. An agent can compare every invoice with its purchase order and receipt, every bank line with the ledger and every bank detail change with the supplier's history, then route what fails to a person. What it cannot do is hold the decision. The question is now asked in exactly those words: a thread on Reddit is titled "How to Apply Segregation of Duties to AI Agents in Finance".
The principle has not moved. The US Government Accountability Office's Green Book, revised in May 2025, asks management to "separate control activities related to authority, custody, and accounting of operations" (GAO-25-107721, paragraph 10.22). One person approves, another holds the asset or the payment, a third records. The weak point has not moved either. It is the checker. Phacet's own definition of the maker-checker control puts it plainly: under volume and time pressure, "the checker often confirms that something was entered, not whether it is correct."
That is the part an agent changes. A second person approving 400 invoices on a Thursday afternoon looks at totals. An agent applies the same price, quantity and matching rules to every line, and it has no reason to trust the colleague who keyed the invoice. The segregation stays between people. The check between them stops depending on how much time is left.
This is also where agents actually run in production. Nicolas Marchais, CEO of Phacet, wrote in July 2026 that 62% of the agents Phacet deploys "are systematic control agents, on every flow" (translated from French). Control, not automation of the decision, is the dominant use.
Access rights or transactions: where segregation of duties actually breaks
Segregation of duties breaks in two places: in who is allowed to do what, and in what was actually done. Most guides only look at one of them, and they disagree on which.
Numeric's guide to segregation of duties in accounting states that "Automated systems can enforce role-based access controls, ensuring compliance without creating slowdowns." Eye2Scan argues the opposite: beyond access profile audits, which detect a theoretical risk, compensating controls show whether conflicts were actually exploited (translated from French). One treats access rights as the proof, the other treats them as a hypothesis.
Primary sources give each side half the answer. NIST's control catalog says separation of duties "is enforced through the account management activities in AC-2, access control mechanisms in AC-3, and identity management activities" (NIST SP 800-53 Rev. 5, control AC-5). So access rights are the enforcement mechanism, not a detail. The GAO adds the other half: "Where such segregation is not practical, management designs alternative control activities to mitigate the risk" (paragraph 10.21). Access prevents. Transaction review proves, and catches what access design missed.
An AI agent sits on both sides at once. It reviews transactions, which is its value. It also holds access rights, which is its risk. The guides that rank for this topic have not caught up with that. On September 27, 2026, across ten editorial pages ranking in Google's top 10 for it in English and French (16,003 words), the words for AI, agent, bot or service account do not appear once, while fraud and its derivatives appear 78 times. Every actor in their matrices is a person.
The agent is an actor in your SoD matrix too
An AI agent reads documents, writes to tables and sometimes calls other systems. That makes it a user of your finance stack, and the rules for users apply. NIST's least privilege control is explicit about it: "Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks" (AC-6). An agent is a process acting on behalf of users.
The OWASP Top 10 for LLM Applications 2025 names the risk "excessive agency" and traces its root cause to three excesses. Each has a direct equivalent in a finance team.
- Excessive functionality. The agent can do more than its job. An invoice-checking agent that can also edit the supplier master file combines two duties the matrix keeps apart.
- Excessive permissions. The agent's connection has more rights than it needs. OWASP's own example is an extension meant to read data that connects with an identity holding "not only has SELECT permissions, but also UPDATE, INSERT and DELETE permissions". In finance terms: read access to the ledger, not posting rights.
- Excessive autonomy. The agent acts without a human step where the stakes call for one. OWASP's answer is to "require a human to approve high-impact actions before they are taken." A payment release is a high-impact action.
OWASP adds a line every finance leader should keep: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not." In practice, the agent cannot release a payment because its account in the bank portal has no release right, not because its instructions tell it not to. Segregation that lives only in a prompt is not segregation.
An SoD matrix for an AI agent
Take the classic duties and add the agent as a column. For each duty, the agent gets the checking work, a named person keeps the decision, and the evidence shows who did which.
| Duty | What the agent does | What stays with a person | Evidence the auditor can check |
|---|---|---|---|
| Authorization: approving an invoice | Checks price, quantity and the match with purchase order and receipt on every line, and flags each gap | Approving the invoice, and deciding on every invoice that fails a check | Check result per line, approver name and time |
| Recording: posting the entry | Proposes coding and the entry from the checked invoice | Validating and posting under an accounting user in the ERP | Proposal, validation and posting user, kept apart |
| Custody: releasing the payment run | Checks the batch against approved invoices, duplicates and recently changed bank details | Releasing the file in the bank portal, with the agent holding no release right | Batch check report dated before the release |
| Reconciliation: bank reconciliation | Matches bank lines to entries and lists unmatched items with their age | Clearing unmatched items and booking adjustments | Unmatched list, who cleared each item and when |
| Vendor master: bank detail change | Scores each change request against the supplier's history and blocks suspicious ones | Approving the change, by a named approver who does not pay the supplier | Decision and approver recorded in the audit trail |
| Agent configuration: rules and tolerances | Applies the same rules to every row | Changing a rule or a tolerance, by someone who does not clear the agent's exceptions | Rule version applied to each decision, change log |
Two rows deserve attention because the human matrices never had them. The vendor master row existed, but nobody checked every change request. The configuration row is new: before agents, the rules lived in people's heads and in a procedure manual. Now they live in a system, and whoever edits them decides what the next thousand invoices will be judged against.
Read the table column by column and the split is clear: the checking columns go to the agent, the decision columns stay with people, and the evidence column is what makes the split auditable. These are the checks Phacet's internal controls agents run, from contract terms and expense reports to fake IBAN detection, each leaving the decision with the approver you name.
Is it safe to let an AI agent near payments?
It is safe when the agent can stop a payment but cannot start one. A thread on r/automation, "Safety about AI agents accessing financial data", lands on the same split as the matrix above: "Agent handles matching/coding, humans handle release." The risk is not the agent reading vendor payment data. The risk is an agent that can act on it alone.
The bank detail change is the clearest test, because it is where invoice fraud concentrates and where one person often both receives the request and updates the file. Phacet's agent that detects fake IBAN fraud is built on that separation. It scores every change request, and "suspicious changes trigger a validation workflow before any payment." The change "is only applied after approval". Who approves? The agent page answers: "You define the approvers (CFO, treasurer)." Every decision, accepted, rejected or pending, is recorded in the audit trail.
That design follows OWASP to the letter: a human approves the high-impact action, and the authorization sits outside the model. It also follows the matrix. The agent never holds two of the incompatible duties. It checks, a named person decides, the trail shows both.
Who controls the agent?
The person who sets the agent's rules should not be the person who clears its exceptions. Otherwise one person can loosen a tolerance on Monday and approve the invoices it lets through on Tuesday, and the matrix has a hole shaped exactly like the old one.
NIST states the same principle for security teams: separation of duties includes "ensuring that security personnel who administer access control functions do not also administer audit functions" (AC-5). Applied to an agent, the configuration of rules and tolerances is an administration function, and the review of what the agent flagged is an audit function. They belong to different people, or at least to different roles with a log of who switched between them.
This is where the platform matters more than the agent. Phacet's security page lists "Role-based access controls", "Every agent under human control" and "Audit trail traces every action". The pricing page adds SSO and roles on advanced plans. Roles are what let you give one person the right to edit a control and another the right to clear its exceptions.
What the auditor will ask to see
- The agent's permissions. Which systems it reads, which it writes to, and confirmation that it holds no approval, posting or payment release right it does not need.
- The rule in force at each decision. For a flagged or passed invoice, which version of the rule and which tolerance applied that day.
- The change log. Who changed a rule, when, and who approved the change.
- The exception trail. For each exception, who cleared it, when and with what justification, and proof that this person did not configure the rule.
- Completeness. Evidence that the agent ran on the whole population, not on a sample, for the period under review.
None of this is new to an auditor. It is what they already ask of an ERP. The difference is that the agent's evidence is structured by default, one row per decision, where a manual review leaves initials on a printout.
Where to start
Start where the checker is weakest today: supplier invoices against negotiated prices, bank detail changes, and the payment run before release. On each of them a person currently signs off without looking at every line. Astotel, a group of 18 hotels in Paris, found what that costs on price checks. On a single supplier, the agent surfaced up to €400 of billing errors a month, nearly €5,000 a year. Valérie, Purchasing Director, summed it up on Astotel's customer page: "AI has helped me become more efficient by quickly identifying price discrepancies, and even catching some errors I wouldn't have noticed on my own."
Then write the agent into your matrix before it goes live: what it reads, what it may write, which decisions it routes and to whom, and who owns its rules. Phacet's page for financial control teams covers the checks usually worth handing over first. The agent does the checking at full volume. Your team keeps the approvals, the releases and the rules, and can finally show that every line was looked at.
FAQ
What are the four major functions of segregation of duties?
The four functions usually kept apart are authorization, custody of assets, recordkeeping and reconciliation. The GAO Green Book groups them as authority, custody and accounting. In practice, the person who approves a payment should not also release it, record it or reconcile the bank account it leaves from, so that one error or fraud needs two people to go unnoticed.
What is the difference between separation of duties and segregation of duties?
There is no difference in substance: both describe splitting a sensitive process so that no single person controls it from start to finish. Segregation of duties is the usual term in accounting and audit, separation of duties the usual term in IT security, as in NIST control AC-5. Both are abbreviated SoD and sometimes called division of duties.
Who is responsible for segregation of duties?
Management is responsible for segregation of duties. The GAO Green Book states that management considers it when designing control activities and designs alternative controls where it is not practical. In a finance team, the CFO or head of finance owns the design, auditors test it, and an AI agent can perform checks without taking over that responsibility.
What does GAAP say about segregation of duties?
GAAP says nothing specific about segregation of duties, because it sets rules for recognizing, measuring and disclosing transactions, not for internal control. It comes from internal control over financial reporting: frameworks such as COSO, the assessment that section 404 of the Sarbanes-Oxley Act requires from US listed companies, and the GAO Green Book for federal entities.
What are some examples of segregation of duties?
Classic examples are that the person who creates a supplier does not pay it, the person who approves a purchase does not receive the goods, and the person who releases payments does not reconcile the bank account. With AI agents, a new one appears: Phacet's fake IBAN agent flags a bank detail change, and a named approver validates it.
