Separation of Duties in Agent Workflows
Can the same actor propose, approve and execute a consequential change?
Reference notes by Min · Reviewed October 15, 2026
Definition
Separation of duties assigns incompatible responsibilities to distinct authorized actors so one actor cannot complete a sensitive sequence alone. Agent implementations must preserve that separation across accounts, tools and approval paths.
The purpose is to prevent an entire sensitive sequence from being controlled by one compromised or mistaken actor. Counting assistants or chat windows is insufficient. Independence depends on credentials, decision rights and the ability to alter evidence or bypass the reviewer.
What it covers
- Roles
- Which responsibilities conflict.
- Identity
- Which principals hold each role.
- Enforcement
- Where conflicting combinations are rejected.
- Exceptions
- How emergency departures are authorized and reviewed.
Review the complete sequence, including setup steps. An actor who cannot approve a transfer directly might still change the approver list or destination account. Administrative permissions can undermine an otherwise well-designed transaction approval flow.
In practice
Practical design patterns by Min.
- Identify consequential sequences requiring independent review.
- Check effective permissions rather than interface labels.
- Reject approvals issued by the initiating principal where independence is required.
Create a role-conflict matrix and test it against effective permissions. Include delegated identities and service accounts. Where independent review is required, the execution service should validate that the approving actor is eligible and distinct in the relevant relationship.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Separate incompatible responsibilities
NIST SP 800-53 AC-5 addresses separation of duties. Applying it to agent services requires examining effective access, not simply naming separate workflow stages.
Source: NIST SP 800-53 Rev. 5: Security and Privacy Controls ↗
Working example
An agent proposes a supplier bank change
The organization requires independent confirmation before modifying payment details.
- Let the agent prepare a proposed change.
- Route review to an authorized independent role.
- Commit only the reviewed values through the protected service.
Why the controls matter
For the bank-change example, review should use trusted supplier records or a separate verification procedure. Agreement between two models reading the same potentially malicious message does not establish independent confirmation of the destination.
Common pitfalls
- Using two agents backed by the same unrestricted credential.
- Allowing the proposer to edit approval records.
- Making the reviewer depend solely on the proposer’s explanation.
Additional reviewers can create delay without meaningful protection if they lack information or authority. Match the separation to the consequence and preserve an emergency procedure that is bounded and visible. Review exceptions after the urgent condition ends.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Can one principal hold conflicting effective permissions?
- Can the proposer alter the reviewer or evidence?
- What makes the approval independent?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- NIST SP 800-53 Rev. 5: Security and Privacy Controls ↗Accessed October 15, 2026
- OWASP: Authorization Cheat Sheet ↗Accessed October 15, 2026