Least privilege limits how much access an identity has, while SoD limits which conflicting duties that identity can combine. You need both. An account can be narrowly scoped and still violate SoD if it can request, approve, and execute the same sensitive action. Segregation is about incompatible power, not just small permissions.
Why This Matters for Security Teams
Security teams often use “least privilege” and SoD as if they are interchangeable, but they solve different problems. Least privilege is about minimizing access scope, while segregation of duties is about preventing a single identity from combining incompatible powers. That distinction matters most when service accounts, pipelines, or AI agents can request, approve, and execute sensitive actions in one flow.
The risk is not theoretical. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks highlights that 97% of NHIs carry excessive privileges, which means many environments already fail the basic access-scope test before SoD is even considered. The OWASP Non-Human Identity Top 10 frames the same issue from a control perspective: weak identity governance is not just over-broad permissioning, but also failure to prevent concentrated authority.
In practice, many security teams discover SoD violations only after a workflow, automation, or incident response path has already combined duties that should never have been held by one identity.
How It Works in Practice
Least privilege should be applied first as an access design principle: give an identity only the minimum actions, resources, and time window needed to complete a task. SoD then adds a second control layer by separating incompatible responsibilities across distinct identities, approvals, or execution stages. A human may approve a change, while a separate system account executes it; an AI agent may prepare a recommendation, while a different control plane identity applies the change.
For non-human identities, this separation is often implemented with short-lived access, scoped tokens, and workload identity rather than long-lived shared credentials. NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it connects identity sprawl, secrets handling, and privilege lifecycle into one operational model. In parallel, NIST SP 800-207 Zero Trust Architecture reinforces that access should be continuously evaluated rather than trusted simply because an identity is “inside” the environment.
- Use least privilege to constrain what an identity can do.
- Use SoD to ensure one identity cannot complete a sensitive process end-to-end.
- Map approval, execution, and administration to separate identities where risk is material.
- Prefer ephemeral, task-bound credentials over reusable static secrets.
This distinction becomes especially important in CI/CD, cloud admin automation, and AI-assisted operations where a single workflow can trigger change, approval, and deployment unless controls are explicitly separated. These controls tend to break down when teams share privileged service accounts across pipelines because the same credential becomes both the requestor and the executor.
Common Variations and Edge Cases
Tighter separation often increases operational friction, requiring organisations to balance speed against control coverage. That tradeoff is real: strong SoD can slow automation, while aggressive least privilege can break legitimate workflows if the task boundaries are not well understood.
There is no universal standard for SoD implementation in modern cloud and agentic environments, so current guidance suggests using risk-based separation rather than trying to force every workflow into the same pattern. For low-risk tasks, least privilege may be enough; for high-impact actions such as billing changes, access grants, production deployment, or key rotation, SoD should be explicit and enforceable. This is especially true for AI agents, where a single autonomous system can chain tool calls in ways that look harmless individually but create a toxic combination when viewed end-to-end.
Another common edge case is delegated administration. A platform team may need broad operational reach, but that does not mean one admin identity should both approve and execute sensitive changes. A better model is to split duties across roles, use policy checks at decision time, and keep human review separate from machine execution where feasible. The same logic applies to emergency access: break-glass accounts may temporarily exceed least privilege, but they should still be constrained by SoD, logging, and post-event review.
In most environments, the hardest failure is not missing one control or the other, but assuming that a narrow permission set automatically prevents conflicting authority.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses over-privileged and mismanaged NHI credentials. |
| NIST CSF 2.0 | PR.AC-4 | Access control governance underpins least privilege and duty separation. |
| NIST Zero Trust (SP 800-207) | Zero Trust supports continuous, context-aware enforcement instead of implicit trust. |
Define and review access rules so no identity can combine incompatible sensitive actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
