Draw up a separation of duties matrix for AI agents to show which duties must never sit with the same actor, then map every agent, every person and every agent configurator against them. It applies wherever agents act, from onboarding to claims, and closes the gaps that open when one agent quietly does three people's jobs.
Why does separation of duties apply to agents at all?
Separation exists so that no single actor can initiate, approve and conceal a transaction. Software does not change that logic; it makes it more urgent, because an agent can act at volume and its mistakes repeat. The argument is set out in separation of duties still applies when the worker is software. The principle itself is explained in what segregation of duties is.
There are two new kinds of conflict. An agent might combine incompatible duties directly. Or a person might combine them indirectly: by configuring the agent that initiates and then approving its output.
When should you use it?
When designing a process that will include agents, before any of them go live, and at each change in an agent's capabilities. Revisit it during periodic access reviews.
It is a cross-functional template. Finance teams have a version tailored to ledger duties, the segregation of duties matrix for finance agents. This general version suits onboarding, claims, lending operations, IT and anywhere else agents act.
How do you fill in each field?
- List duties by function. Use the four classic functions: initiate, approve, record, verify. Under each, list the concrete duties in the process.
- Mark conflicts. For each duty pair, mark whether the same actor may hold both. Most conflicts are between initiate and approve, and between record and verify.
- List actors. Every agent by name, every human role, and a "configurator" row for each agent.
- Assign and check. Mark each actor's duties and look for conflicts on any row.
- Record compensating controls where a conflict remains.
- Check agent-to-agent paths. If agent A can instruct agent B, treat them as one actor for conflicts unless B checks A's request against its own bounds. How to keep agents apart is covered in how to keep separation of duties between AI agents.
The template
Duty conflict grid
| Initiate | Approve | Record | Verify | |
|---|---|---|---|---|
| Initiate | Conflict | |||
| Approve | Conflict | |||
| Record | Conflict | |||
| Verify | Conflict |
Assignment
| Duty | Function | Agent | Depth | Human role | Configurator | Conflict? | Compensating control |
|---|---|---|---|---|---|---|---|
A worked sample
A hypothetical fintech's business account onboarding.
| Duty | Function | Agent | Depth | Human role | Configurator | Conflict? |
|---|---|---|---|---|---|---|
| Collect application and documents | Initiate | Onboarding agent | 3 | n/a | Ops engineer | No |
| Screen against sanctions lists | Verify | Screening agent | 3 | Screening analyst (matches) | Compliance engineer | No |
| Assess risk and draft recommendation | Initiate | Onboarding agent | 2 | n/a | Ops engineer | No |
| Approve account opening | Approve | None | n/a | Onboarding officer | n/a | No |
| Open account in core system | Record | Onboarding agent | 3 | n/a | Ops engineer | See below |
| Quality check of opened accounts | Verify | None | n/a | QA analyst | n/a | No |
The onboarding agent both initiates and records. That is acceptable only because a person approves between those steps and an independent QA analyst verifies afterwards. The screening agent is kept separate, with its own configurator, so the onboarding team cannot change screening rules.
One more check: the ops engineer who configures the onboarding agent must not also be an onboarding officer. That is the configurator conflict, and it is the one most often missed.
For mapping who is responsible and accountable for each activity, rather than who may not combine duties, use the RACI matrix for AI agent oversight.
Where Pryme fits
Pryme grants authority per capability, per agent, so incompatible duties can be kept on separate agents with separate identities. When one agent asks another to act, the receiving agent checks the request against its own bounds, so a request outside them is refused. See agent governance is a bound, not a model.
Questions people ask
Is one agent with many capabilities always a conflict?
No. Capabilities that sit in the same function, such as collecting documents and checking they are complete, can share an agent. The conflict arises across functions, especially initiate and approve.
How do auditors test separation for agents?
They compare the matrix with actual permissions and with the record of actions, looking for any transaction where one actor appears at two conflicting steps. Keep both easy to produce.
What about agents provided by a vendor?
Treat each vendor agent as an actor with its own row. If you cannot see or control its permissions, record that as a limitation and add a compensating control.