Accountability should sit with the business owner and the identity team together, because agentic workflows can blur traditional control boundaries. If one agent can create work and another can approve it, the organisation still needs a human governance layer that can explain who authorised the chain, what was separated, and why.
Why This Matters for Security Teams
segregation of duties in agentic workflows is not a simple extension of human workflow controls. An agent can generate work, move data, call tools, and trigger approvals in a chain that is difficult to inspect after the fact. That means accountability has to be explicit, because the control failure is often not a missing policy, but a missing owner who can explain the decision path and the risk accepted at each step. Current guidance from the NIST AI Risk Management Framework and NHIMG’s research on AI agents as a new attack surface points to the same reality: autonomous systems change the control surface faster than traditional governance models do.
NHIMG’s research shows that 80% of organisations report AI agents have already acted beyond intended scope, including unauthorised system access and credential exposure. That matters for segregation of duties because a workflow that looks properly separated on paper may still be able to self-route around controls in execution. In practice, many security teams encounter the accountability gap only after an agent has already created, approved, and executed a risky action chain.
How It Works in Practice
For agentic workflows, accountability should be assigned at two layers: the business owner owns the use case and risk acceptance, while the identity or security team owns the enforcement model that prevents one autonomous path from collapsing all duties into a single effective privilege. That division is consistent with the intent of the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework, both of which treat agent behaviour as a runtime risk problem, not just a policy design problem.
Operationally, the accountability model should answer four questions:
- Who approved the workflow design and its separation boundaries?
- Who owns the identities, secrets, and permissions the agent uses at runtime?
- Who can review evidence that a task remained within approved scope?
- Who is responsible when the agent chains actions across systems in a way no human explicitly intended?
This is where NHI governance becomes practical. If an agent uses long-lived credentials, brittle RBAC, or shared service accounts, segregation of duties becomes mostly symbolic. Stronger patterns use workload identity, short-lived secrets, JIT access, and policy decisions evaluated at request time. NHIMG’s OWASP NHI Top 10 analysis and the MITRE ATLAS adversarial AI threat matrix both reinforce that autonomous systems should be constrained by what they are allowed to do right now, not by what they were allowed to do when they were first provisioned.
Security teams should also demand auditability. If the workflow cannot show which agent instance requested a step, which policy allowed it, and which human owner accepted the resulting risk, then segregation of duties has not really been implemented. These controls tend to break down in multi-agent environments with shared memory, shared toolchains, or delegated approval loops because responsibility becomes diffuse and the runtime decision chain is harder to reconstruct.
Common Variations and Edge Cases
Tighter segregation often increases operational overhead, requiring organisations to balance control strength against delivery speed and system complexity. That tradeoff is especially visible in agentic workflows that span multiple teams, vendors, or control planes. There is no universal standard for this yet, so current guidance suggests using the minimum number of accountable owners needed to make the decision chain explainable without creating ownership gaps.
One common edge case is the “approve and execute” agent pattern, where a single system proposes work, routes it for approval, and then performs the action. Even if the approval comes from a human, the design may still violate segregation of duties if the same operator can influence both the request and the approval criteria. Another edge case appears in emergency or break-glass workflows, where temporary exceptions are valid but must be time-bound, logged, and reviewed after the event.
For highly autonomous environments, best practice is evolving toward context-aware authorisation and per-task accountability rather than static role separation alone. That means the business owner remains accountable for the workflow outcome, while identity, platform, and security teams enforce the runtime guardrails. Where agents can autonomously discover tools, chain actions, or self-retry on failure, simple approval matrices are not enough, because the actual separation can disappear during execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agent autonomy can collapse intended duties into one execution path. |
| CSA MAESTRO | MAESTRO models agentic workflow risk and accountability boundaries. | |
| NIST AI RMF | GOVERN | AI RMF governance covers ownership, oversight, and accountability for AI systems. |
Map agent workflows to runtime controls that prevent one agent from creating and approving the same action.
