Separation of duties is the control principle that no single person should be able to complete a sensitive task alone. The steps are split: one person sets up a supplier, another pays them; one person requests access, another grants it. With AI agents, the same rule applies to the agent, to the people around it, and between agents.
Why does it still matter when the worker is software?
Because the risk it addresses has not gone away. Separation of duties exists to stop error and fraud by making sure every sensitive action passes through more than one independent decision. If an agent can both create a new payee and pay them, the business has removed the split, even if no person is involved. A compromised instruction, a spoofed invoice or a flaw in the agent's sources could then carry through end to end.
The principle also applies to the people around the agent. The agent owner who changed its brief should not be the person who approves that change. The reviewer who requested a refund should not approve the agent's held version of it. The argument is made in full in separation of duties still applies when the worker is software.
How does it work with agents?
At three levels.
- Within one agent. Capabilities that would complete a sensitive chain alone are split: the agent may set up a payee at depth 3 but must hold any payment to a new payee for a person.
- Between agents. Where two agents work on the same process, their capabilities are designed so that neither can complete the sensitive chain by itself, and an orchestrator cannot override that. The method is in how to keep separation of duties between AI agents.
- Between people and agents. The person who prepares or requests an action is never the one who approves the agent's held version of it, and the platform enforces this rather than trusting habit.
The separation of duties matrix for AI agents gives a format for mapping these splits.
An example
Take a hypothetical manufacturer's accounts payable team. Its supplier agent updates supplier records; its payments agent drafts payment runs. During design, the deployment architect notices that the supplier agent could change bank details at depth 3 and the payments agent would then pay the new details on the next run. She splits the chain: any change to bank details is held for a named person who verifies it by call-back, and the payments agent holds any payment to details changed in the past thirty days for a second approver. Neither agent, and no single person, can now redirect a payment alone.
How is it different from a second approver?
A second approver is one way to achieve separation: two independent people sign off the same action. Separation of duties is the broader principle, which can also be met by splitting a task into stages owned by different people or agents. Not every separated task needs two approvers on each step; it needs the sensitive chain to be impossible to complete alone. Designing for that from the start is the subject of separation of duties survives AI agents, if you design for it.
Related terms
Second approver, red line, control owner and house rule all connect. The guide to AI agent skills by role shows which roles must be kept apart.
Where the Academy fits
Separation is a design decision first, which is why Pryme Intelligence Academy's Builder and Architect tracks give it most weight. Reviewers on the Operator track learn the reviewer's share: never approving what they prepared, and recognising when a held action would complete a chain that should have been split.
Questions people ask
Can a small team keep separation of duties?
Yes, with care. Even a team of three can split preparing from approving. Where the same person must sometimes do both, compensating checks after the fact help, such as a weekly review by the owner.
Is separation of duties a legal requirement?
In many regulated settings, it is expected as part of internal control. Its exact form varies by sector and market; confirm what applies with counsel.