Segregation of Duties for AI Agents: Rights, Limits and Audit Trails

Segregation of duties for AI agents becomes a live question once a pilot moves from drafting suggestions to posting entries and preparing payments. The principle of segregation of duties (SoD) has not changed: no single actor should be able to initiate, approve, record and reconcile the same transaction, but one of those actors may now be software that works at volume and never takes leave. This article explains how to treat each agent as a role in your control environment, how to define decision rights and approval limits, what a usable audit trail contains, and how to update your conflict matrix so agents tighten controls instead of quietly eroding them.

1. Why segregation of duties breaks when agents arrive

Most SoD failures with automation are not dramatic. They come from convenience. A team builds an agent to process supplier invoices and gives it a service account so it can read purchase orders. Later it extends the same account to create vendors because onboarding is slow, and later still to propose payment runs. Each change looked sensible on its own. Together they produce an actor that can create a supplier, book an invoice against it and queue it for payment, which is exactly the combination a classic access control matrix exists to prevent.

Older bots made this easier to spot because they followed fixed scripts. Agents reason about what to do next, call several tools and can be pointed at new tasks with a configuration change instead of a development project. That flexibility is the value, and it is also the risk. If the agent runs under a shared technical user, or under the credentials of the analyst who built it, the ERP log will show which user posted but not which actor decided, and your internal controls for AI agents rest on little more than good intentions.

2. What does segregation of duties for AI agents actually mean?

In practice, segregation of duties for AI agents means applying the same incompatibility rules you apply to people, with each agent treated as a named role holder. An agent that matches invoices is a maker. It should not also be the checker that approves its own output, the custodian that releases funds or the reviewer that reconciles the bank account afterwards. Two different agents can sit on either side of a maker-checker control, but only if they run under separate identities, separate permissions and separate instructions, and neither can change the other's configuration.

The second element is ownership. Every agent needs a human process owner who is accountable for its decisions in the same way a line manager is accountable for a team member. That owner should sit in the business, typically the AP manager or the financial controller, not in IT. The people who build and change agents form a third group. They must not be the ones who approve the agent's exceptions or sign off its performance, because that recreates the developer-in-production problem auditors already flag in ERP environments.

3. Defining AI agent decision rights role by role

Start with a decision rights register before you touch technical permissions. For each agent, write down what it may read, what it may propose, what it may execute on its own and what it must always escalate. Take an accounts payable agent in a group with entities in Dubai and Riyadh, as an example. It may read purchase orders, goods receipts and the vendor master in both entities. It may post invoices that match within tolerance. It may not edit bank details, create vendors or change tolerances, and any invoice from a newly onboarded supplier goes to a person.

Then translate the register into system permissions, and keep them as narrow as the register. Agents that work inside SAP, Oracle or Microsoft Dynamics 365 should have their own technical users mapped to roles built for the agent, never a copy of a power user profile. AITHENTIC builds its finance AI agents this way: each one has a defined role, decision rights, escalation logic and a full audit trail, and people approve exceptions. If the register and the ERP role disagree, the ERP role wins in practice, so review both together.

Resist the temptation to grant broad rights early to speed up a pilot. Narrow permissions slow the first few weeks, because more items escalate, but they give you clean evidence of how the agent behaves. Widening scope later, one decision type at a time with a documented sign-off from the process owner, is far easier to defend to an auditor than shrinking an over-privileged agent after something has gone wrong.

4. Setting approval limits agents cannot exceed

Approval limits for AI agents should be stricter than those for the people they support, at least at first. A senior AP accountant might approve invoices up to a delegated authority threshold. An agent working the same queue might auto-post only matched invoices below a much lower value, and only for suppliers with a clean payment history. Limits can combine amount, supplier risk rating, entity, currency and document type. An agent handles volume well. It should not be the actor that clears unusual, high-value or first-time items.

Enforce the limits outside the agent. If a threshold lives only in the prompt or the agent's instructions, a configuration error or a misread document can carry it past the line. Put the hard limit in the ERP workflow or the orchestration layer, so the agent physically cannot post or release above it. The same applies to payment runs: an agent can prepare the proposal and run duplicate payment prevention checks, but release should sit with a treasury user holding the bank token, under dual authorisation.

5. Building an audit trail for AI agents that auditors will accept

An ERP change log tells you that a document was posted and by which user. For an agent, that is not enough. A useful audit trail for AI agents records the inputs the agent saw, the source documents it relied on, the rules or tolerances it applied, the decision it reached, its stated reasoning, the version of the agent and its configuration at the time, and who approved any exception. Without version history, you cannot show that the control operating in one quarter was the same one you tested in the previous quarter.

Store this evidence where finance and internal audit can query it, not in an application log that only engineers can read. A governed data layer such as Microsoft Fabric lets you join agent decisions to ERP postings, approvals and bank files, so an auditor can pick a sample of payments and trace each one back to the invoice, the match result and the approver. It also lets controllers run their own monitoring: how many items each agent escalated, how many overrides occurred and whether any agent acted outside its register.

Treat overrides as signals. When a reviewer repeatedly reverses the same type of agent decision, either the agent's instructions need work or the limit sits in the wrong place. Both belong in the change process, with the process owner's approval, and should never be fixed quietly by whoever built the agent. Teams that already run AI model risk management for forecasting or credit models can extend the same review cadence to finance agents, so drift and override rates are reported alongside other model performance measures.

6. Updating the SoD conflict matrix and testing the controls

Your SoD conflict matrix needs new rows. Add each agent as a role, list its permissions and run the same conflict analysis you run for people, including combined conflicts where an agent and a human share a task. One trap is the hand-off: an agent raises a vendor bank detail change and the same person who configured that agent approves it. On paper there are two actors. In reality one person controls both ends. Map who configures, who approves and who monitors each agent, and check those people against the matrix too.

Test as you would any key control. For segregation of duties for AI agents, design testing confirms that the register, ERP roles and hard limits agree, while operating testing samples real decisions over a period and confirms the agent stayed within them. Include negative tests: feed the agent an invoice above its limit, a supplier with changed bank details and a duplicate. An AP invoice verification agent should route each of these with the reason attached, and the trail should prove it did.

Not every process is worth putting under agent control. Low-volume, high-judgement activities such as setting up new legal entities or approving write-offs gain little from an agent and add review effort. Concentrate agents where volume is high and rules are clear, and keep the incompatible duties around them with people who have time to review properly. That is usually where SoD gets stronger, because staff move from keying transactions to reviewing exceptions with a clear evidence trail in front of them.

Key challenges

• Agents running under shared or personal credentials, so system logs cannot show which actor made a decision.
• Permissions widened step by step during pilots until one agent holds incompatible duties.
• Approval thresholds held only in agent instructions instead of being enforced in the ERP or workflow layer.
• Builders who can change an agent's configuration also approving its exceptions or signing off its performance.
• Audit evidence kept in technical logs that finance and internal audit cannot query or sample.

The framework

A workable operating model has four layers. Role: every agent is a named role holder with its own system identity and a business process owner in finance. Rights: a decision rights register states what the agent may read, propose, execute and must escalate, mirrored exactly in dedicated ERP roles. Limits: hard approval limits enforced in the ERP workflow or orchestration layer, stricter than human delegated authority at first and widened only with documented sign-off. Evidence: a queryable audit trail of inputs, reasoning, agent versions and approvals, monitored monthly and tested like any other key control, with the duties to build, approve and monitor each agent held by different people.

How to implement it

1. Inventory every agent and automation that touches the ledger, vendor master or payments, and record the identity each one runs under.
2. Write a decision rights register for each agent and assign a named process owner in finance.
3. Create dedicated ERP roles for each agent that match the register and remove any shared or copied user profiles.
4. Enforce approval limits in the ERP workflow or orchestration layer so agents cannot post or release above them.
5. Add agents and the people who configure, approve and monitor them to the SoD conflict matrix and resolve every conflict found.
6. Test design and operating effectiveness with sampled decisions and negative test cases before widening any agent's scope.

Frequently asked questions