Est.
MCP SecurityLong read

Separation of Duties in AI Agent Workflows

AI agents collapse all three separation-of-duties roles into one unaccountable identity.

Staff Writer · · 12 min read
Cover illustration for “Separation of Duties in AI Agent Workflows”
MCP Security · August 14, 2026 · 12 min read · 2,790 words

Separation of duties was built for humans. A single AI agent operating with unconstrained access can shatter that entire framework in one session, and most enterprises won't know it happened until they're staring at an audit log with one name in it instead of two.

SoD is a control principle with a straightforward premise: no single entity initiates, authorizes, and executes a consequential action alone. You trace it back to financial controls and audit standards, where the person who requests a payment is categorically different from the person who approves it, who is categorically different from the person who cuts the check. Those three roles create friction on purpose. The friction is the protection.

The entire framework assumes the actor is a human who pauses between steps, can be questioned mid-process, and carries a stable, registered identity that leaves a traceable name in a log. AI agents violate all three assumptions simultaneously, and they do it at machine speed.

How an AI agent's operational profile makes it capable of collapsing all three SoD roles at once

Here's what a modern AI agent can actually do inside a single session: retrieve data from systems of record, analyze patterns, trigger transactions, update CRM entries, fire outbound emails, modify configurations, open tickets, and invoke financial workflows. That list is not hypothetical, it's what enterprise agents do today, off the shelf.

Map each capability to a SoD role and you see the problem immediately. Retrieval is initiation. Analysis that feeds a decision is authorization. Execution is the action itself. An agent doing all three simultaneously hasn't just bypassed SoD; it has replaced it with a single identity that holds no accountability boundary.

A chatbot answers. An agent acts. That distinction is precisely where the risk lives, because acting means writing to systems, not just reading from them.

Two compounding factors make this worse than it sounds on paper. First, session-state and memory persistence: an agent that retains context across steps accumulates effective authority that no individual permission grant would have given it. Second, dynamic tool chaining: agents select APIs, plugins, and external services on the fly at runtime, which means an access policy written at deployment time cannot anticipate the chain the agent will build four steps later.

The OWASP Top 10 for Agentic Applications frames this through what it calls the "Least Agency" principle: autonomy is a feature to be earned, not a default. Giving an agent a blank mandate to solve a problem is the operational equivalent of handing a new contractor your SSO credentials, write access to your data warehouse, and a live email integration, then leaving for the day. An agent in exactly that configuration has collapsed initiation, approval, and execution into one unaccountable identity. That's not a security posture; it's an inside threat waiting for a malicious prompt.

The scale at which ungoverned agents are already in production

Gartner projects that 40% of enterprise applications will include task-specific AI agents by end of 2026, up from less than 5% in 2025. Separately, 70% of enterprises are projected to deploy agentic AI in IT operations by 2029. IDC projects up to 1.3 billion AI agents in operation by 2028. Microsoft Copilot Studio users had collectively created more than one million AI agents by May 2026; agent framework packages pulled 483 million downloads in that same month alone.

Those numbers are not abstract. They represent the deployment velocity that governance programs are currently failing to match.

Per Cycode's 2026 State of Product Security report, 81% of organizations lack full visibility into how AI is used across their SDLC, and 65% report increased security risk from AI tooling. A Gartner survey of 302 cybersecurity leaders found that 69% of organizations either suspect or have confirmed evidence that employees are using prohibited public generative AI, largely without IT review.

This is what makes the SoD problem structurally worse than most compliance teams realize. The agents most likely to collapse segregation of duties are frequently the ones IT and compliance don't know exist. They get built bottom-up, outside formal procurement, optimized for shipping fast, with no one filling out an intake form before deployment.

The speed-governance gap isn't accidental. It's the predictable outcome of agent tooling that any developer can stand up in an afternoon, inside an enterprise whose governance process still assumes a multi-week procurement cycle.

Why SoD enforcement for AI agents is inseparable from the non-human identity crisis

You cannot separate duties for an identity you haven't registered. That sentence is the entire argument of this section, and everything below is evidence for it.

Per Palo Alto Networks' 2026 Identity Security Landscape, machine identities now outnumber human identities 109 to 1, up from 82 to 1 just one year prior. That's a 32.9% jump in the ratio itself in twelve months. KPMG's Cybersecurity Considerations 2026 puts the average enterprise machine identity count at roughly 250,000 in 2025, up from roughly 50,000 in 2021, a fivefold increase in four years. AI agents account for a growing and accelerating share of those identities, with companies projecting 85% agent growth over the next twelve months.

The over-permissioning data is damning across every source I've seen. A 2025 NHI Management Group report found that 73% of secrets held by non-human identities carry excessive permissions. The 2026 NHI Reality Report from Protego puts it at 97% of NHIs holding more privileges than they need. Over 5.5% of AWS machine identities carry full administrative privileges.

The governance vacuum matches those numbers. A 2026 Cloud Security Alliance survey found that 92% of respondents said legacy IAM tools cannot manage AI and NHI risks; half reported no clear ownership or accountability for agent identities. Only 28% of organizations can trace an agent's actions back to a human sponsor across all environments. A 2025 World Economic Forum analysis put the figure for organizations with no clear ownership of AI identities at 51%.

Teleport's 2026 research, drawing from interviews with 205 CISOs, makes the consequence concrete: organizations with least-privilege non-human identity access reported a 17% AI agent security incident rate. Those without it reported a 76% rate. That's a 59-percentage-point difference attributable to one governance practice.

SoD enforcement for agents runs through identity governance. There's no other entry point.

Diagram: Least Privilege Cuts Incident Rate by 59 Points. Visualizes: Show a stark before/after or two-bar magnitude contrast: organizations WITHOUT least-privilege non-human identity access report a 76% AI agent security incident rate…

How secrets sprawl and ungoverned MCP configurations turn SoD gaps into exploitable attack surfaces

GitGuardian's State of Secrets Sprawl 2026 found that 28.65 million hardcoded secrets were added to public GitHub repositories in 2025 alone, a 34% year-over-year increase and the largest single-year jump on record. AI-related secrets accounted for more than 1.27 million of those exposures, an 81% year-over-year increase and the fastest growth in any single credential category they've measured.

Within MCP specifically: in the protocol's first year of adoption, 24,008 unique secrets appeared in MCP configuration files on public GitHub. Partly, that happened because quickstart guides normalized hardcoding API keys directly into config files. The protocol was designed for interoperability, not for secrets hygiene.

This matters for SoD in a way that often gets missed. A hardcoded credential embedded in an agent's config isn't just a hygiene failure; it's a standing grant of access that no authorization step can revoke in real time. The approval boundary that SoD requires simply doesn't exist when access is baked into a static file. Every ungoverned MCP server added without a registry entry is an identity that can't be accounted for, and an unaccounted identity is consistently the one that gets exploited.

The 2026 NHI Reality Report found that 71% of non-human identities are not rotated within recommended timeframes. Stale credentials persist long after the scope of a workflow changes, meaning the access that an agent legitimately needed six months ago still exists today, when that agent's role has been modified, deprecated, or handed to a different workflow entirely.

Anthropic introduced MCP in November 2024. It was donated to the Linux Foundation in December 2025. The protocol is maturing faster than the governance tooling around it, and the attack surface doesn't appear at deployment. It exists the moment a server goes ungoverned, which in most environments is the moment it gets created.

What the OWASP Top 10 for Agentic Applications maps as the specific SoD failure modes

Table: OWASP Agentic Risk Categories Mapped to SoD Failures. Compares SoD Failure Mode, How It Manifests, Documented Example and Core Governance Gap by ASI01: Goal Hijack, ASI03: Identity & Privilege Abuse and ASI08/02: Cascading Failures.

The OWASP Top 10 for Agentic Applications, published December 9, 2025, is a peer-reviewed framework developed with more than 100 industry participants. It catalogs ten risk categories, labeled ASI01 through ASI10, specific to agents that plan, hold memory, call tools, and act with delegated authority. Three of those categories map directly to SoD breakdown.

ASI01: Agent Goal Hijack. An agent's objective gets redirected by a malicious external input, causing it to act on behalf of an attacker while appearing to serve the legitimate user. The clearest documented example is EchoLeak, assigned CVE-2025-32711 with a CVSS score of 9.3. It was the first known zero-click attack on an AI agent: a crafted email planted hidden instructions that Microsoft 365 Copilot later retrieved as context, causing it to exfiltrate data with no user interaction. One agent. One malicious prompt. One collapsed SoD boundary, with no human step between the attacker's input and the data leaving the environment.

ASI03: Agent Identity and Privilege Abuse. Agents inherit, misuse, or retain privileges improperly across sessions, users, or delegated workflows. This surfaces in enterprise agents with single sign-on access, multi-role deployments, and delegated task chains where the original scope of access was never formally bounded.

ASI08 and ASI02: Cascading Agent Failures and Tool Misuse. When one agent's overprivileged action propagates through a chain, downstream agents act on corrupted inputs with no mechanism to reject them. The failure compounds because each agent in the chain treats the prior agent's output as a trusted signal.

OWASP's Least Agency principle reframes SoD in terms that fit agentic systems: autonomy is something to be earned through demonstrated scope, not granted as a default. The taxonomy defines the risks with precision. What it leaves open is enforcement, and that's where the next two sections sit.

Why multi-agent architectures make SoD structurally harder — and what that demands of governance design

In a single-agent system, SoD is hard. In a multi-agent system, it can't be evaluated by looking at any one node. You have to evaluate the entire chain, and the failure modes that emerge from the chain are categorically different from anything traditional access governance was designed to catch.

Three specific failure modes stand out. Miscoordination: two agents with overlapping scopes take contradictory actions on the same resource, with no human noticing until a downstream inconsistency surfaces, sometimes hours or days later. Diffusion effects: authority granted to an orchestrator agent bleeds into sub-agents that inherit context and credentials they were never explicitly assigned. Collusion: not malicious intent, but emergent behavior where two agents optimizing for the same goal collectively bypass a control that neither would bypass operating alone.

Academic analysis of multi-agent risk published in 2025 is direct on this point: these failure modes cannot be assessed by evaluating any individual model in isolation. The risk emerges from interaction. That means the governance model has to observe the system as a system, not audit individual agents as discrete components.

Static policy enforcement breaks here by design. Agents chain tools dynamically at runtime, selecting APIs and services the access policy writer never anticipated. The policy has to travel with the agent through delegation, not just enforce at the point of initial access.

What governance infrastructure has to provide in a multi-agent environment:

  • Unique agent IDs that enable attribution across every node in a chain, not just at the entry point
  • Behavioral constraints that follow an agent through delegation handoffs
  • Inter-agent communication protocols that carry authorization context alongside task data, so downstream agents know the provenance and scope of what they're acting on
  • A registry where every agent in every workflow has a registered identity; gaps in the registry are gaps in the SoD model by definition

The harder the multi-agent system becomes to govern in isolation, the more a centralized control layer becomes load-bearing. One that observes the system as a whole rather than auditing nodes individually.

Human-in-the-loop as a structural SoD mechanism — and where it has to be policy-driven rather than discretionary

Diagram: Three-Party Separation at Every Approval Boundary. Visualizes: Illustrate the structural SoD requirement for agentic systems as a three-node flow or stepped diagram: (1) the Agent — requests an action; (2) the Policy Engine — evaluates the…

HITL is not a single configuration. It exists on a spectrum with two meaningfully different positions. Human-in-the-loop means humans intervene during execution to approve or correct agent actions before they take effect; the agent is interrupted and waits. Human-on-the-loop means humans supervise after completion, reviewing outcomes and flagging exceptions after the fact. Both have legitimate uses. Only one enforces SoD.

Financial services organizations built the layered HITL model that the rest of industry is now adopting, because their existing SoD compliance requirements forced them to find a structured answer before anyone else needed one. That precedent is worth following closely.

The dynamic oversight problem is what makes binary HITL configurations fail in practice. An agent that books a travel reservation and then negotiates a vendor contract within the same workflow session presents fundamentally different risk levels at different steps. A configuration that treats both steps identically is either over-interrupting on low-risk actions or under-supervising on consequential ones. Oversight has to be dynamic, policy-driven, and enforceable through identity controls at the agent level, not left to the agent's judgment or the operator's availability.

Three-party separation at approval boundaries is the structural requirement: the agent that requests an action, the policy engine that evaluates the request, and the human or system that authorizes it must be structurally distinct. If the decision to trigger human review is made by the agent itself, the agent has already collapsed the authorization role into its own execution path. That's not human-in-the-loop; it's the agent deciding when it needs a supervisor, which defeats the control entirely.

The real-time requirement is non-negotiable. An audit log read after an incident is a postmortem, not a safety net. HITL only enforces SoD when the intervention happens before the action is irreversible. At the deployment scale Gartner projects for 2026, HITL patterns designed for narrow, single-purpose workflows will need to scale to cross-functional, multi-step operations where the risk calculus changes mid-flight, sometimes mid-session.

The technical controls that operationalize SoD for agents: RBAC, least privilege, and gateway enforcement

Role-based access control applied to agents is not a blanket policy restricting what AI can do. It's the practice of scoping each agent identity to the minimum set of capabilities required for its defined function, binding those capabilities to a registered identity, and enforcing that binding at every integration point.

In practice, that means four things working together:

  • Agent-specific roles, not shared service accounts. An agent that reads from a data warehouse and an agent that writes to it are different identities with different role assignments. Shared credentials between agents are shared blast radius.
  • Least privilege enforced at the tool level. Each API, plugin, and external service an agent can call should be explicitly permitted in the agent's role definition. Implicit inheritance from a parent process or orchestrator is a diffusion failure waiting to happen.
  • Gateway enforcement as a chokepoint. All agent-to-system traffic should route through a control layer that validates the calling identity, the requested action, and whether that combination is within policy before the call completes. Tools like Aembit and CyberArk Conjur operate at this layer for non-human identities; purpose-built agent security platforms such as Pangea and Socket extend this to agent-specific enforcement with session-level context.
  • Immutable audit logs with identity attribution. Every agent action logged against a registered, non-shareable identity. If the log can't answer "which registered agent, operating under which role, performed this action at this timestamp," the SoD model has an attribution gap.

The Teleport research I cited earlier puts the incident rate difference at 59 percentage points between organizations with and without least-privilege NHI access. That's the measurable return on these controls, not a theoretical benefit.

Secrets management is the layer underneath all of this. Hardcoded credentials in agent config files undermine RBAC at the root because they grant access that no role definition can revoke. Every agent identity should authenticate through a secrets management system that issues short-lived credentials, enforces rotation, and can revoke access without touching the agent's codebase. HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault are the established options; the principle is the same across all of them.

SoD for AI agents isn't a new problem requiring entirely new thinking. The underlying principle has been sound for decades. What's new is an actor that doesn't pause, can't be questioned mid-flight, scales horizontally across millions of instances, and carries an identity that most enterprises haven't formally registered. The controls exist. The frameworks are published. The incident data is in. The remaining variable is whether governance programs move fast enough to catch the deployment curve before the exposure compounds further.

Sources

  1. cloudeagle.ai
  2. labs.cloudsecurityalliance.org
  3. axis-intelligence.com
  4. securityboulevard.com
Filed underMCP Security

More in MCP Security