Govern the workflow, not just the person. Every identity that can alter, approve, or route a sensitive transaction should be in scope, including service accounts, API integrations, bots, and AI agents. The review model needs one ownership chain, one entitlement picture, and one remediation path across all participating identities.
Governing SoD Across Human and Non-Human Identities
Segregation of duties works when the control is anchored to the business workflow, not to a job title alone. If a transaction can be initiated, approved, changed, or routed by software as well as people, the SoD model has to treat those non-human participants as part of the same control boundary. That means the policy, review, and remediation model must follow the transaction path end to end.
For the identity layer, the best starting point is a single control model that can describe who can do what across both humans and machines. NHIMG’s Human vs Non-Human Identity helps frame where shared workflows, delegated access, and mixed ownership create ambiguity. When the same business action is reachable through users, service accounts, integrations, bots, or AI agents, SoD has to evaluate the combined effect of those identities, not each account in isolation.
Practically, that means the review scope should include the full chain of entitlements behind a sensitive workflow. A person may never directly approve their own request, but an automation they own can still do so indirectly if it can create, enrich, approve, or release the transaction. NHIMG’s Segregation of Duties (SoD) Guide is useful here because it extends SoD thinking to service accounts, bots, and AI agents, which is exactly where many modern control failures hide.
The second important distinction is that SoD is not just a ruleset, it is an ownership problem. Teams need one accountable owner for each workflow conflict, one view of all entitlements that participate in it, and one remediation path when a conflict is found. NHIMG’s NHI Ownership and Accountability Guide is relevant because orphaned or weakly owned non-human identities are a common reason SoD exceptions linger without decision or cleanup.
Why Mixed Human and Machine SoD Breaks in Practice
The control often fails when organisations model SoD at the account level instead of the action level. A single human may appear clean in review, while the actual conflict sits in a linked integration, shared service account, or delegated approval path. The same issue appears in SaaS-to-SaaS automations, where consent, scopes, and token access can quietly create a second approval path that bypasses the intended workflow boundary.
NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is a good fit for these cases because consented integrations can act with authority that is easy to miss in a manual SoD review. When a business process can be driven by OAuth grants, API scopes, or automation tokens, the conflict is often systemic rather than personal. That is why the review question should be, “Can this workflow violate separation even if no single user seems over-entitled?”
Another common failure mode is lifecycle drift. A role change, integration update, or automation refresh can reintroduce a conflict after the original approval has been cleared. NHIMG’s Joiner-Mover-Leaver (JML) Guide matters because SoD governance depends on timely removal of old access paths, not just initial access design. In practice, SoD exceptions should be time-bound, owned, and revalidated whenever a human or non-human participant changes.
For teams that need a broader operating model, NHIMG’s Identity Convergence Guide is useful because it treats workforce, privileged, customer, NHI, and AI agent identity as a connected governance surface. That is often the right mental model for SoD: one workflow, multiple identity types, one control outcome.
How to Operationalise SoD Reviews Across All Participating Identities
Good SoD governance starts with inventory. Teams need to know which identities can initiate, enrich, approve, reconcile, or release a sensitive transaction, and they need that mapping to stay current as integrations and automations change. NHIMG’s Service Account Security Guide supports this operational view because service accounts are often the hidden control path inside enterprise workflows.
From there, review design should use three questions: who owns the workflow, which entitlements create the conflict, and what is the actual remediation action. If the same owner can both create and approve, or if a bot can complete the second step with no independent check, the conflict exists even if the business process feels automated and efficient. NHIMG’s NHI Governance Maturity Model is helpful because maturity here is not measured by how many accounts are reviewed, but by whether inventory, ownership, access, and lifecycle are governed as one system.
When teams want a practitioner shortcut, they should treat every sensitive workflow as a control chain: map the identities, identify the approval points, then remove any path that lets one actor effectively control both sides of the transaction. NHIMG’s Segregation of Duties (SoD) Guide is a strong reference point for building those rulesets, while the Human vs Non-Human Identity explainer helps teams decide where the same control must apply to people and machines alike.
Risk and Threat Considerations
SoD weaknesses are attractive because they turn a legitimate workflow into a low-friction abuse path. If a service account, bot, or AI agent can participate in both sides of a sensitive process, the organisation may have preserved formal approval steps while losing real separation.
Failure mechanism: Conflict detection breaks when reviews stop at the visible user and do not include the automation, integration, or delegated access path that actually completes the transaction. That leaves toxic combinations hidden inside legitimate operational workflows.
Impact: The result can be fraud, improper payment, unauthorized release, policy bypass, or a privileged abuse path that is hard to spot in routine access reviews. At scale, the risk becomes systemic because the same control gap repeats across many workflows and identities.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | SoD across humans and machines depends on identity governance and access separation. |
| Recommendation — Apply IAM controls to map and enforce duties across all identities in the workflow. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses separating conflicting duties in sensitive workflows. |
| AC-6 — Least Privilege | Limiting privileges reduces the chance that one identity can complete conflicting steps. | |
| IA-5 — Authenticator Management | Non-human participants often rely on credentials whose lifecycle affects SoD exposure. | |
| Recommendation — Define SoD rules that prevent the same actor from holding incompatible permissions. Restrict each identity to only the permissions needed for its workflow step. Manage credentials so conflicting access paths are rotated or revoked promptly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SoD is an access-control governance problem spanning people and machines. |
| Recommendation — Set access-control rules that enforce separation across all participating identities. | ||
Practitioner Guidance
What to prioritise: Build SoD rules around business transactions first, then attach every human and non-human identity that can influence the result. If an automation can create a conflict even indirectly, it belongs in scope.
What to verify: For each high-risk workflow, verify that ownership, entitlement review, and remediation all point to the same accountable process, not to separate teams with different sources of truth. If a conflict is found, there should be one path to disable or redesign it.
Common mistake: Treating SoD as a quarterly checklist for named users while leaving service accounts, API integrations, bots, and agents out of the review population. That approach creates a control that looks complete but does not actually separate duties.
Practitioner takeaway: The cleanest SoD model is the one that can explain the entire transaction path, including every identity that can change the outcome, and can remove a conflict without debating whether the actor was human or machine.