Why do agentic AI systems break segregation of duties models?

Why Traditional Segregation of Duties Fails for Agentic AI

segregation of duties was designed for human workflows where one person requests, another approves, and a third executes. agentic ai collapses those steps into one autonomous loop. An AI agent can plan, call tools, retrieve secrets, and complete the task before a reviewer sees the request, so the prohibited combination exists only briefly inside runtime state. That is why static RBAC alone is not enough for autonomous systems.

This is the same pattern NHI teams now see in the broader agentic risk landscape documented in OWASP NHI Top 10 and in the OWASP Agentic AI Top 10. Current guidance suggests the control objective has to move from “who may have this role” to “what may this agent do, right now, in this context.” NIST’s NIST AI Risk Management Framework is useful here because it emphasises governance, measurement, and ongoing monitoring rather than one-time entitlement review.

In practice, many security teams only discover SoD failure after an agent has already chained access, used a credential, and completed the prohibited action without any human ever seeing the risky combination.

How SoD Has to Work in Practice for Autonomous Agents

For agentic AI, SoD needs to become sequence-aware and intent-aware. That means the policy decision must evaluate the agent’s current goal, the tool it is requesting, the data it is about to touch, and whether the action conflicts with another action in the same task graph. The control point cannot be limited to a pre-approved role because the agent’s path is dynamic and may change mid-execution.

Practitioners are increasingly pairing intent-based authorisation with just-in-time issuance of ephemeral secrets. Instead of giving an agent standing access, the system issues short-lived credentials for a single task, then revokes them automatically when the task completes. This is where workload identity becomes important: a cryptographic identity for the agent, such as SPIFFE/SPIRE or OIDC-backed workload tokens, proves what the agent is, while policy-as-code decides what it may do. That approach aligns with the direction described in the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework.

• Issue credentials per task, not per environment.
• Bind access to an explicit intent, such as “read ticket metadata” or “open a pull request.”
• Evaluate policy at request time, not only at onboarding or role assignment.
• Revoke secrets as soon as the task or session ends.
• Log each tool call so conflicting actions can be reconstructed later.

NHIMG research shows why this matters operationally: in the AI agents attack surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope. These controls tend to break down when agents are allowed to reuse long-lived credentials across multiple tools because the trust boundary disappears between one action and the next.

Common Variations and Edge Cases

Tighter SoD enforcement often increases operational overhead, requiring organisations to balance task speed against review depth and policy complexity. That tradeoff is real, especially in multi-agent pipelines where one agent drafts, another validates, and a third executes. There is no universal standard for this yet, so best practice is evolving toward risk-tiered controls rather than a single rigid model.

One edge case is delegated autonomy, where a planner agent triggers lower-trust sub-agents. In those designs, SoD should apply across the whole chain, not just within each individual agent. Another is emergency access: if a system needs break-glass behaviour, the exception should be time-bound, heavily logged, and isolated from the normal agent workflow. The DeepSeek breach and the AI LLM hijack breach both reinforce the same lesson: once secrets or tool access are exposed, autonomous systems can move faster than human review cycles.

For governance teams, the practical target is not perfect human-style SoD. It is preventing one runtime from creating, consuming, and laundering the same privilege in a single sequence. That becomes even more important when agents are connected to external tools, because current guidance suggests perimeter-only models fail once the agent can chain prompts, APIs, and secrets in one execution path. For that reason, the most useful control pattern is short-lived workload identity plus runtime policy, as outlined in the OWASP Top 10 for Agentic Applications 2026 and the OWASP Agentic Applications Top 10.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern machine identity credentials in agentic AI environments?
• Why is identity such a critical factor in securing AI agent systems?
• When is it appropriate to implement MCP in the context of AI systems?