Controls · role design
Separation of Duties for AI Agents
Automation is attractive precisely because it collapses steps. Segregation of duties exists precisely because some steps must not collapse. That tension is the whole subject.
The short answer
Separation of duties for AI agents means ensuring that no single agent, and no single human configuring agents, holds every role in a consequential process. Five roles must stay separate: who initiates, who approves, who executes, who configures the agent, and who reviews the record. Agent estates collapse these faster than human organisations because efficiency is the stated goal of automation and role boundaries are invisible in a config file. Five roles, four agent-specific collusion paths, and compensating controls for when separation is genuinely impossible.
Key takeaways
- 01The point of automation is to collapse steps. The point of separation of duties is that some steps must not collapse. Decide deliberately which.
- 02Five roles: initiate, approve, execute, configure, review. Any two in one place is a finding worth a written justification.
- 03The boundary that fails first is configure and approve — the engineer who set the threshold waving through the action that crossed it.
- 04One agent completing an entire consequential process end to end is not efficiency; it is an unreviewed process.
- 05Agents introduce collusion paths humans do not have: shared context, shared identity, and a configurer who can change the rules.
- 06Where separation is impossible, compensating controls must be stated explicitly rather than assumed.
The tension, stated honestly
Segregation of duties predates computing. Its logic is simple: if one person can raise an invoice, approve it and pay it, a single act of error or dishonesty is sufficient. Splitting the roles means two things must go wrong.
Automation exists to remove handoffs. An agent that can complete a whole process without waiting for anyone is faster, cheaper and more consistent, and that is what it was bought for. So the technology and the control are pulling in opposite directions, and pretending otherwise produces either theatre or paralysis.
The resolution is not to apply separation everywhere. It is to decide deliberately which boundaries must survive automation, accept the cost on those, and automate freely everywhere else. Most processes have exactly one or two boundaries that matter, and identifying them is a shorter exercise than teams expect.
What is not defensible is collapsing a boundary by accident, in a config file, because nobody was looking at the process as a whole. That is the common case, and it is what this article is about.
Key facts
- ▸Automation removes handoffs; separation of duties preserves specific ones. Both are legitimate.
- ▸Most processes have one or two boundaries that genuinely matter.
- ▸The failure is not choosing to collapse a boundary — it is collapsing one without noticing.
Five roles
In a process an agent participates in, these five must be assignable to distinguishable parties. Any two held by one party is a finding — not automatically wrong, but requiring a written justification.
| Role | Who holds it | Collapses with | Consequence if collapsed |
|---|---|---|---|
| Initiate | The agent, or the human who tasked it | Approve | Self-approval — the classic failure |
| Approve | A human with standing above the threshold | Initiate, Configure | Oversight becomes formality |
| Execute | The tool and its credential | Approve | Approval is advisory if execution can bypass it |
| Configure | Whoever sets entitlements, bounds and thresholds | Approve | The person who set the limit waves through the breach |
| Review | Whoever reads the audit record | Configure, Execute | Nobody independent examines what happened |
Configure and approve is the boundary that fails first, and it is the one least likely to appear in a control matrix. The engineer who set the £5,000 threshold is frequently the person the approval request routes to at 4pm on a Friday, and they know exactly why the threshold exists — which feels like qualification and is actually the conflict.
How agents collapse roles faster
Human organisations drift into role collapse over years, and audits catch it. Agent estates get there in weeks, for reasons specific to how they are built.
One agent, whole process
The agent reads the request, decides it is valid, executes it and writes the record. Initiate, execute and — through the absence of any gate — approve, all in one identity. This looks like a well-designed automation and is an unreviewed process.
The diagnostic question: could this agent complete a consequential outcome without any other party acting? If yes, the roles have collapsed regardless of how the code is structured.
Configurer as approver
The platform engineer who owns the agent is also the person approvals route to, because they understand the system best. Understanding it best is exactly what makes them the wrong approver.
Shared identity across roles
Two agents nominally doing different jobs share a service account. The audit record cannot distinguish them, so the separation exists in the architecture diagram and nowhere else.
This is why per-agent identity is a prerequisite for separation of duties, not merely good practice — without it, no role boundary is evidenced.
Shared context
Two agents in one session, or one agent handling both sides of a process in a single conversation. The second decision is made with full knowledge of the first, in the same reasoning pass, which is not independence in any useful sense.
The subtlest route, and the one with no human equivalent. Two people reviewing sequentially have separate minds; one model reviewing its own earlier output in the same context does not.
Designing the boundary
Four decisions, in order. The first is the one people skip and the one that makes the rest tractable.
- Which boundary actually matters here?
- Name the single handoff whose collapse would be unacceptable. For a payments process it is initiate/approve. For an access-management process it is request/grant. For a data-export process it is often execute/review. One boundary, chosen deliberately, enforced properly, beats five applied nominally.
- Who holds each side, by name?
- Named parties, not roles in the abstract. “Finance approves” is not a design; “approvals above £5,000 route to the finance controller rota, excluding whoever configured the agent” is.
- How is the boundary enforced, not just documented?
- In the routing rule itself. If the approval router can send a request to the agent’s configurer, it will. Encode the exclusion where the routing happens — see approval workflow design.
- What happens when the separated party is unavailable?
- Every separation needs a documented break-glass path that alerts loudly and generates a review. Without one, teams invent an undocumented path, and an undocumented path is worse than a logged exception.
A useful structural move where a process must be automated end to end: split the agent rather than the workflow. One agent with entitlement to initiate, a separate agent with entitlement to execute, and a policy requiring the second to see an approval token from a human. Two identities, two entitlement sets, two audit trails — and the separation is now a property of the architecture rather than of anyone’s discipline.
Built on this thinking
Separation enforced in the routing rule, not the runbook
BarzelVault routes approvals by rule and records who approved what against a hash-chained trail, so configurer-as-approver is an exclusion you encode rather than a convention you hope holds. Barzel Central Gateway supplies the per-agent identity without which no role boundary is evidenced.
When separation is genuinely impossible
Small teams, out-of-hours processes and low-volume functions sometimes cannot supply two independent parties. The right response is a stated compensating control, not a quiet exception.
| Situation | Compensating control | Why it partially substitutes |
|---|---|---|
| No second approver available out of hours | Lower the automatic threshold overnight; hold larger actions until morning | Reduces the magnitude that can pass unreviewed rather than the review itself |
| Team too small for role separation | Post-hoc review of 100% of actions above a threshold, by someone outside the team | Moves independence from before to after, which is weaker but real |
| Configurer must also approve | Every such approval flagged and reviewed monthly by a third party | Makes the conflict visible and periodically examined |
| Single agent must complete the process | Hard parameter bounds plus mandatory post-execution notification to an independent party | Bounds the magnitude and guarantees somebody outside sees it |
Two rules for compensating controls. They must be written down as compensating controls, naming the separation they replace — an auditor accepts a stated compensating control and does not accept an undocumented gap. And they must be reviewed on the same cycle as the thing they compensate for, because they are usually adopted as temporary and become permanent.
Testing for collapse
Five checks, all answerable from the registry, the entitlement records and the approval log.
| Check | Query | Finding if |
|---|---|---|
| Self-completion | Can any single agent identity complete a consequential process end to end? | Yes, for any process with irreversible or externally visible effects |
| Configurer as approver | Does any approval route to the person who owns the agent’s configuration? | Any overlap between configurer and approver lists |
| Shared identity | Do two agents with different roles share a service account? | Any shared credential across role boundaries |
| Shared context | Does one agent session handle both sides of a separated process? | Any session spanning a boundary you declared |
| Approval concentration | What proportion of approvals are granted by one person? | One approver above roughly 60% of a category’s volume |
The last check is the quiet one. A rota that exists on paper but resolves to the same person in practice has all the appearance of separation and none of the substance — and it shows up as a concentration statistic long before anyone notices it as a control failure.
Where this control is overapplied
Separation of duties has real costs: latency, staffing, and friction on work that was automated to remove friction. Applied to low-consequence processes it produces bureaucracy that teams route around, which then erodes the boundaries that mattered. Choose one or two boundaries per process and defend those.
It also does not address the case where both parties are wrong in the same way. Two approvers presented with a plausible fabricated invoice will both approve it. Separation defends against unilateral error and misconduct; it does not defend against a convincing premise, which is a content authenticity problem.
And there is a boundary this article does not resolve: whether two agents genuinely constitute separate parties. They have separate identities and separate entitlements, which satisfies the mechanics. Whether two instances of the same model reviewing each other provides meaningful independence is an open question, and our position is that it does not — which is why the approval side of any boundary that matters should terminate in a human.
Frequently asked questions
What is separation of duties for AI agents?
Ensuring that no single agent, and no single human configuring agents, holds every role in a consequential process. Five roles must stay separate: who initiates, who approves, who executes, who configures the agent, and who reviews the record.
Why do AI agents collapse role boundaries faster than people?
Because automation exists to remove handoffs, role boundaries are invisible in a configuration file, and four agent-specific routes accelerate it: one agent completing a whole process, the configurer acting as approver, agents sharing a service account, and two decisions made in one shared context.
Which separation boundary fails first in agent estates?
Configure and approve. The engineer who set the threshold is frequently the person approvals route to, because they understand the system best — which is exactly what makes them the wrong approver.
Is one agent completing a whole process a problem?
If the process has irreversible or externally visible effects, yes. An agent that can initiate, execute and record without any other party acting is not an efficient automation; it is an unreviewed process, however well the code is structured.
Why does shared context break separation between agents?
Because two decisions made in the same reasoning pass are not independent. Two people reviewing sequentially have separate minds; one model reviewing its own earlier output within the same context does not, and this route has no human equivalent.
Can two AI agents provide separation of duties for each other?
Mechanically they can hold separate identities and entitlements, which satisfies the audit trail. Whether two instances of the same model provide meaningful independence is an open question, and our position is that they do not — so any boundary that matters should terminate in a human.
What compensating controls work when separation is impossible?
Lower the automatic threshold when a second party is unavailable; review 100% of above-threshold actions after the fact by someone outside the team; flag and monthly-review any approval given by the configurer; or apply hard parameter bounds plus mandatory notification to an independent party.
How do you test for role collapse?
Five checks: whether any single agent can complete a consequential process end to end, whether approvals route to the agent’s configurer, whether agents in different roles share a credential, whether one session spans a declared boundary, and whether one person grants more than roughly 60% of approvals in a category.
What is the best structural fix when a process must be fully automated?
Split the agent rather than the workflow: one identity entitled to initiate, a separate identity entitled to execute, and a policy requiring the second to present an approval token. Separation then becomes a property of the architecture rather than of anyone’s discipline.
Does separation of duties protect against prompt injection?
Only partially. It defends against unilateral error and misconduct, but two approvers presented with a plausible fabricated premise will both approve. Separation raises the cost of an attack; content authenticity is a different problem.
Glossary
- Separation of duties
- A control requiring that no single party holds every role in a consequential process, so that error or misconduct requires more than one participant.
- Role collapse
- The condition in which one agent or one person holds two or more roles that a control design requires to be separate.
- Collusion path
- A route by which nominally separate parties act as one — for agents, typically shared context, shared identity or a common configurer.
- Compensating control
- An alternative safeguard applied where the primary separation is impractical, stated explicitly rather than assumed.
- Four-eyes principle
- A requirement that two independent parties agree before a consequential action proceeds.
Sources and further reading
Segregation of duties is a long-established, externally audited control and the frameworks below are authoritative on the requirement. The five-role model as applied to agents, and the agent-specific collusion paths, are our own.
- 01 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 02 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
- 03 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 04 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 05 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 06 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 07 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 08 · NISTNIST SP 800-207 — Zero Trust Architecture ↗The policy decision point / policy enforcement point split this architecture borrows directly.
Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Separation of Duties for AI Agents. Real Biz Digital. https://realbizdigital.net/insights/ai-agent-separation-of-duties/
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Dev | Free | 10,000 policy decisions/mo · 9 tools, 4 outcomes, hash-chained audit | A first regulated workflow: one agent, one high-consequence system |
| Team | $199/mo | 75,000 decisions/mo · approval workflow, spend and action limits | Several agents acting on money, records or customer-visible systems |
| Business | $799/mo | 750,000 decisions/mo · exact HTTPS execution, credential isolation, emergency controls | Enterprise-wide pre-execution enforcement with audit obligations |
| Enterprise | $3,999/mo | 5,000,000 decisions/mo · everything in Business, scaled | Group-wide rollout across many teams and systems |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.