Separation of duties does not die because an AI agent can do several steps at once. It dies when nobody designs for it. Split capabilities so no agent prepares, executes and checks the same work; keep those who set an agent's limits apart from those who approve its held actions; give each agent only the tools it needs.
Why do agents threaten separation of duties?
Separation of duties exists so that no one person can both commit and conceal an error or a fraud. In accounts payable, the person who sets up a supplier is not the person who approves payment to them. In treasury, the person who initiates a transfer is not the person who releases it.
Agents threaten this in two ways. First, an agent can be given many capabilities at once. If the same agent can create a supplier, match its invoices and release payment, the separation that used to exist between three people collapses into one piece of software. Second, a small team runs the agent. If the same person writes the agent's brief, sets its limits and approves its held payments, the separation collapses on the human side too.
Neither is inevitable. Both are design choices.
How do you keep separation between agents?
By scoping each agent to one side of each duty. In a governed system, authority is granted per capability, so this is a matter of deciding which capabilities belong together.
A finance deployment might use one agent to onboard suppliers and verify bank details, and a different agent to match invoices and prepare payment runs. The second agent can read supplier records but cannot change them. Releasing payment is a depth 4 capability that, in most deployments, is held for a person. No single agent spans the whole chain.
The guide on how to keep separation of duties between agents covers patterns for this. A separation of duties matrix for agents is a practical way to lay out which agent and which person holds each duty.
Tools matter here too. An agent can only do what its tools let it do. If the payment agent is given a general-purpose tool that can also edit supplier records, the separation exists on paper but not in practice. Designing narrow tools for each capability, as described in how to design tools for agents, keeps it real.
How do you keep separation between people?
By separating the roles around each agent. Four are worth keeping apart:
| Role | What they do | Should not also |
|---|---|---|
| Agent owner | Writes and changes the brief and sources | Approve the agent's held payments |
| Person who sets limits | Decides thresholds the agent works within | Approve changes to their own limits |
| Reviewer | Approves held actions | Change the limits that decide what is held |
| Second approver | Approves depth 4 actions alongside the reviewer | Be the same person as the first |
In a large organisation this is easy. In a small one, it takes care: the same person may need to wear two hats, in which case a third person should periodically review what they did in each.
Why is this a design decision rather than a policy?
Because the workspace enforces what it is configured to enforce. A policy that says "the agent owner shall not approve held payments" means little if the owner has approval rights in the system. Separation must be built into who holds which rights, and which agent holds which capabilities, from the start.
That is the broader point made in who answers for an agent is a design decision: accountability, and the separation that supports it, comes from how the system is set up, not from what the policy document says.
What is the trade-off?
Separation costs efficiency. More agents with narrower scopes mean more coordination, more handoffs and more places for work to wait. More people in separate roles mean more headcount or more hats per person. A single broad agent and a single capable owner is simpler and faster.
There is also a design burden. Someone has to work out which duties to separate, configure the agents and rights accordingly, and keep it that way as the deployment grows.
The trade-off is the same one finance teams have always made. Separation slows things down slightly and prevents a category of failure that is otherwise very hard to detect. With agents, the speed loss is smaller than it was with people, because handoffs between agents are fast. The protection is just as valuable.
What should you do differently?
Draw a separation of duties matrix before you configure any agent that touches money, records or approvals. Give each agent the narrowest set of capabilities and tools that does its job. Separate the agent owner, the person who sets limits and the reviewers. Require two certified people for depth 4 actions. And review the matrix whenever an agent gains a capability. The guide to AI agent skills by role sets out what each role needs to know.
Where the Academy fits
Designing agents with separated capabilities and narrow tools is Builder work, and Pryme Intelligence Academy's Builder track is for whoever designs, trains and certifies agents. Leading a regulated deployment where several agents share a process, and separation must hold across all of them, is the focus of the Architect track, which ends in a board review with two Pryme assessors.
Questions people ask
Can one agent ever handle a whole process end to end?
For low-risk processes with no money or irreversible actions, perhaps. Where duties would be separated between people, they should be separated between agents, or the final step held for a person.
Does the platform enforce separation on its own?
The platform enforces the bounds you configure and withholds certain actions for every agent. Which capabilities each agent holds, and which rights each person holds, are your design decisions.
How do auditors test separation in an agent deployment?
They compare the matrix with actual configuration and the record, checking that no agent or person performed both sides of a separated duty.