Separation of duties means splitting a sensitive workflow so that no single actor, human or agent, can both initiate an action and approve it, the same principle that's kept one accountant from both writing and signing off on their own checks for a very long time. In agentic workflows, this gets overlooked in a specific way: teams build an approval gate for an agent's action, then let the same agent, or a closely related agent under the same broad service account, effectively act as its own approver by feeding it the context and framing that makes approval a formality. The control exists on paper without actually existing in practice.
Why agents make this easier to get wrong
A human process usually has an organizational reason two different people are involved, different roles, different reporting lines, different incentives. An agentic workflow can be built entirely by one team, using one framework, with one agent instance doing both the proposing and, functionally, much of the influencing of the approval, because it's technically simpler to build that way. The structural separation a manual process got almost by accident doesn't happen automatically in software; it has to be designed in deliberately.
What genuine separation looks like for agents
A genuinely separated workflow has the agent that proposes an action be a distinct actor, with a distinct identity and distinct permissions, from whoever or whatever approves it. If the approver is another agent, that second agent needs independent access to the relevant context, not just the first agent's summary of the situation, and it needs the actual authority to deny the action, not just a symbolic check that always returns yes in practice.
Watching for de facto collapse of separation
Separation can exist in an architecture diagram and still collapse in practice if the approving party, human or agent, has no real independent way to evaluate the request and just defers to whatever the initiating agent presented. This is the same failure mode as approval fatigue, but it's specifically dangerous in a separation-of-duties context because it means the control that was supposed to provide an independent check has become a formality dressed up as oversight.
Applying separation to high-value or irreversible actions specifically
Not every action needs this level of structural rigor, and applying it everywhere creates the same fatigue and overhead problems any overly broad control creates. Reserve strict separation of duties for the actions where a single point of control failing would cause serious damage: financial transactions above a threshold, permission changes, deletion of significant data, anything where one compromised or manipulated actor acting alone is a genuinely unacceptable risk.
Auditing for separation, not just designing for it
A separation-of-duties control needs to be checked periodically to confirm it's still functioning as intended, not just verified once at design time. Look at actual approval patterns: is the approving party ever denying anything, or does every request from a given initiating agent sail through, which is a sign the separation exists in name only.
Documenting which roles satisfy separation for which actions
Separation of duties works best when it's explicit about which pairs of roles or identities actually satisfy the requirement for a given action type, rather than left as a general principle everyone assumes is being followed somewhere in the architecture. A short, maintained record, this action requires initiation by role A and approval by a distinct role B, gives both engineers building new workflows and reviewers auditing existing ones something concrete to check a design against, instead of relying on tribal knowledge about how separation is supposed to work in this particular system.
This documentation earns its cost the first time a new team member builds a workflow without realizing an action was supposed to require separated roles, and the record makes that gap obvious during review rather than something that only surfaces after the workflow has been live and unguarded for months.
Where TELEON fits
TELEON's policy enforcement and audit trail can help verify separation of duties in practice, by recording which identity initiated an action and which identity approved it, giving teams the data to check whether those are genuinely distinct actors making independent decisions, rather than one actor's decision dressed up as two steps.
Designing the actual workflow structure, and deciding which actions warrant strict separation, is organizational and architectural work specific to each team's risk tolerance.
A short checklist
- Ensure the agent proposing an action is a distinct identity from whoever approves it.
- Give the approving party independent access to context, not just the initiator's summary.
- Reserve strict separation of duties for high-value or irreversible actions specifically.
- Watch for approval patterns that suggest the approving party is deferring rather than evaluating.
- Audit separation of duties periodically, not only at initial design time.
- Avoid applying strict separation so broadly that it recreates approval fatigue.
- Record which identity initiated and which identity approved each action for later review.
Separation of duties fails quietly in agentic systems specifically because it's easy to build something that looks separated on a diagram while functioning as a single point of control in practice. The test that actually matters isn't whether two steps exist, it's whether the second step could genuinely produce a different outcome than the first, and how often it actually does.