You already know the human version of this rule: nobody who detects a threat should also investigate it, approve the response, and execute it. Your Segregation of Duties Policy exists to prevent exactly that accumulation of authority. Now, as your team deploys AI agents into security workflows, the question is whether the same rule applies to machines, and if so, how rigidly.
Evaluating AI in Security Workflows
Auditors evaluating SOC 2 against the Trust Services Criteria look for evidence that no single actor can control a process end to end. ISO/IEC 27001:2022 Annex A control 5.3 requires conflicting duties and conflicting areas of responsibility to be segregated. Neither text carves out an exception for non-human actors.
The practical debate is about implementation. Do you build a chain of narrowly scoped, specialized agents with distinct identities, or deploy one capable general-purpose agent and constrain it with guardrails and monitoring? Both approaches have defensible arguments, and both must satisfy your assessor.
Specialized Agents in Segregated Roles
The argument starts with a simple observation: a single agent that sees, understands, and does everything is the simplest design and potentially the most dangerous. If one agent can detect, investigate, recommend, authorize, and execute, you've recreated the exact single point of failure your human org chart was built to prevent.
Proponents of specialization point to how the human workflow already decomposes. Detect, identify, respond, and recover are different capabilities, usually held by different people. An agentic version mirrors that. One agent monitors for anomalous activity. Another investigates using threat history, identity, and policy context. A third recommends a response. A fourth checks that response against enterprise policy. A human, or an appropriately governed agent, authorizes it based on severity. Only then does an execution agent act.
There are three practical benefits to this design:
Smaller access footprints. A purpose-built agent starts with a specific role and narrower context. It doesn't need access to anything irrelevant to that role, so least privilege becomes easier to enforce and easier to evidence. A fraud-detection agent may need sensitive transaction and device data, but that doesn't mean it should also approve and execute the response.
Cleaner evidence. Each agent has its own identity, so access reviews, logs, and approvals map to distinct actors. Your auditor can sample an approval and see that the approver and the executor were different identities.
Contained blast radius. If one agent is compromised or misbehaves, the damage is bounded by its permissions.
Fewer, Broader Agents
The counterargument is not that segregation is unimportant. It's that decomposition has costs, and those costs create their own risks.
Practitioners on this side raise several points. First, every handoff between agents is a place where context gets lost or distorted. A chain of five agents passing summaries to each other can produce worse decisions than one agent holding the full picture. Second, more agents mean more identities, more credentials, more permission sets, and more things to review. You may be trading one control problem for a sprawl problem, and sprawl is where access reviews quietly fail. Third, a capable general-purpose model with tightly enforced guardrails and strong logging may be easier to govern than a dozen bespoke components, each with its own failure modes.
There's also a fair point about what segregation is actually for. Control 5.3 is aimed at reducing opportunities for unauthorized or unintentional modification or misuse. If you can achieve that through enforced technical separation inside a single platform, such as separate execution privileges that the model cannot grant itself, the number of "agents" matters less than whether the separation holds under pressure.
The weakness in this position is that guardrails and permissions solve different problems. Guardrails define what an agent is allowed to do within its role, and they matter most for general-purpose models because you have to constrain everything you don't want the model to do. Permissions govern what the agent can access and act upon. A broad agent needs broad permissions to do dozens of jobs, which means a large access footprint, and a guardrail is behavioral, not a hard boundary. Asking your auditor to rely on a prompt instruction as a segregation control is a hard conversation.
Practical Approaches
Most teams that have thought this through end up with a hybrid approach, and they tend to agree on a few points.
Separate the decision from the action. Even teams comfortable with broad analytical agents want a hard boundary between recommending and executing. The agent that proposes a response should not hold the credentials to carry it out.
Put an independent check in the path for consequential actions. That check can be a policy-evaluation agent or a human, depending on severity. What matters is that it's independent and that your documentation says when escalation is required.
Treat agents as identities. Each one gets an owner, a defined scope, least-privilege access, and inclusion in your User Lifecycle Management process, including provisioning, review, and decommissioning.
Keep humans in charge of the system, not every action. People define objectives, policies, authority boundaries, and escalation conditions. Approving every individual action defeats the purpose of automation; owning the rules that govern which actions agents may take does not.
Conclusion: A Balanced Approach
Specialization should be your default, and you should require a documented justification for any agent that holds more than one of these roles: detect, recommend, authorize, execute. The reasoning is about evidence as much as security. Segregated identities produce segregated logs, and segregated logs are what let you demonstrate a control rather than assert it.
The hybrid camp is right that you shouldn't build an agent per micro-task. The test is whether a separation corresponds to a real conflict of duties. If two functions would never sit with one person in your organization, they shouldn't sit with one agent.
Agentic systems also give you something humans can't. Interactions, decisions, actions, and results can be captured as they occur, with context, rather than reconstructed afterward. That makes auditability a built-in property of the workflow. Design for it: capture agent reasoning and tool calls, and record which policy was applied and who or what authorized the action.
Start by asking the questions you'd ask when designing a human workflow. What job does this agent perform? What identity and permissions does it need? Which actions require human oversight? Where does the independent check occur? If you can answer those on paper, you can answer them for an assessor.
Segregation of duties has always been about not concentrating power in a single actor. That principle matters more, not less, when the actor is a machine.
