Why do manual SoD reviews fail when permissions change daily?

Why This Matters for Security Teams

Manual segregation of duties reviews assume permissions are stable long enough for a human reviewer to catch a conflict. That assumption breaks in environments where RBAC assignments, JIT elevation, CI/CD tokens, and service-to-service trust change daily. The risk is not just missed paperwork; it is that a conflicting access path can be exercised, monetised, or chained into a broader compromise before the next spreadsheet cycle. OWASP’s OWASP Non-Human Identity Top 10 frames these NHI problems as a control gap, not a reporting gap, and NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks shows how quickly fragmented identities turn into ungoverned access paths.

This matters most where teams still treat non-human access like a quarterly audit item instead of a live control plane. A spreadsheet can record that a build agent, integration token, or temporary admin grant existed, but it cannot prove the conflict was absent when the action occurred. In practice, many security teams encounter SoD failure only after a privileged workflow has already been completed, rather than through intentional detection.

How It Works in Practice

The practical failure mode is temporal. A reviewer checks yesterday’s entitlements, while the real exposure lives in today’s runtime state. Modern SoD enforcement needs to evaluate access at the point of use, not after the fact, especially for NHI, agents, and deployment tooling. That means combining identity signals, task context, and policy checks so the system can decide whether a request is acceptable right now. Current guidance suggests that static RBAC is necessary but insufficient when identities are ephemeral or autonomous.

For that reason, organisations increasingly pair workload identity with JIT credentials and short-lived secrets. A build system, bot, or AI agent should receive only the minimum credential needed for the specific task, then lose it automatically when the task ends. Policy engines can then make intent-based decisions, for example allowing a deployment token to read artifacts but not approve its own release. This is where real-time authorisation differs from manual SoD: the control is enforced on every request, not sampled during review. The DeepSeek breach is a useful reminder that once secrets and credentials escape into operational environments, the window for abuse can be very short, while remediation still takes time. In parallel, OWASP Non-Human Identity Top 10 emphasises secret sprawl, over-privilege, and weak lifecycle control as recurring NHI failure patterns.

• Use workload identity as the primary control anchor, not just stored credentials.
• Issue JIT access with tight TTLs and automatic revocation after task completion.
• Evaluate policy at request time using context, purpose, and execution environment.
• Log who or what requested access, what intent was declared, and what action was permitted.

These controls tend to break down in legacy environments where shared service accounts, long-lived API keys, and batch scripts still bypass the runtime policy layer.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance stronger control against developer velocity and automation reliability. That tradeoff is real, especially where release pipelines, data migrations, or support tooling depend on rapid access changes. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: replace periodic review with continuous validation wherever access can change outside human oversight.

Edge cases usually appear when one identity serves multiple jobs. A CI runner may need to deploy code, query logs, and rotate a secret in the same workflow, which makes coarse RBAC hard to defend. In those cases, teams should split the workload into smaller identities and narrower policy rules, then bind each identity to a single intent. This is also where NHI governance becomes more than access review. It becomes lifecycle control for secrets, certificates, tokens, and agent permissions. If an environment cannot represent those boundaries cleanly, manual SoD reviews will keep producing a false sense of safety even when the actual access pattern has already drifted.

For agentic systems, the risk is sharper still: an autonomous agent may chain tools in ways no reviewer predicted, so control design must assume dynamic behaviour rather than fixed role maps. That is why the NHI view from NHIMG and the broader industry guidance from OWASP both point toward continuous, context-aware enforcement instead of retrospective approval.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• When should organisations replace access reviews with continuous validation for NHIs?
• Why do dormant permissions become riskier when employees use generative AI?