Segregation of Duties in Agentic AI Pipelines

Classical segregation of duties works because humans are bounded. A person occupies one role, sits in one org-chart position, and can only be in one system doing one thing at a time. That boundedness is not incidental to SoD; it is the load-bearing wall. The entire framework assumes the requester and the approver are different people, that the developer and the deployer are different people, and that the sequence of handoffs between them creates natural checkpoints where someone can actually intervene.

An agent has no org-chart position. It has whatever permissions it inherited at setup, which, in the most common origin story, means a developer's own service account or an existing IAM role someone grabbed because it was available and convenient. Then the agent executes at a speed and scale no human ever would.

Speed collapses sequence. An agent connected to an approval workflow, a provisioning system, and a payment processor can receive, approve, and execute a request in seconds with no other party involved. The handoffs that classical SoD relies on to create control boundaries simply do not exist at that tempo.

A case study cited by PwC makes this concrete. A global technology company deployed autonomous agents across a Salesforce-to-Oracle contact-to-cash cycle. A Salesforce agent qualified leads, created opportunities, and generated quotes. When a deal closed, it triggered an Oracle agent that posted revenue-recognition entries. In 87 cases, commission payments exceeded deal margin after third-party costs were factored in. The company paid out more than it earned. SoD controls never flagged the conflict because no single system saw the full chain. The violation was composite, spanning two platforms, invisible to controls scoped to either one individually.

That is the architectural problem, not a configuration gap. SoD controls evaluated within a single system are blind to violations that emerge across the handoffs between systems. The audit question most enterprises cannot yet answer is whether an auditor can reconstruct the full chain of initiation, approval, and recording across every participating system. For most agentic pipelines today, the answer is no.

The Non-Human Identity Explosion That Arrived Before Governance Did

The scale here is not theoretical, and the numbers move fast enough that benchmarks from even a year ago are already stale.

Machine identities now outnumber human identities 109 to 1, according to Palo Alto Networks' 2026 Identity Security Landscape report, up from 82 to 1 just one year prior. Of those 109 machine identities per human, 79 are AI agents specifically. Agents are now the dominant machine-identity type in enterprise environments, which means every governance framework still oriented around human actors is operating on a flawed premise before it even starts.

KPMG's Cybersecurity Considerations 2026 report found that machine identities in the average enterprise grew from roughly 50,000 in 2021 to 250,000 in 2025. Entro Labs' H1 2025 research clocked the non-human identity population growing 44% between 2024 and 2025 alone.

Then there is the ownership question. A 2025 World Economic Forum analysis found that 51% of organizations report no clear ownership of AI identities. More than half of enterprises have agents operating in their environment with no designated accountable party. That distinction matters. You cannot remediate a gap you have not assigned to anyone.

The fastest-growing subcategory compounds this further: agents that spawn sub-agents. Identities that reproduce themselves, each inheriting credentials from a parent, each widening the gap in a way no spreadsheet audit catches in real time. GitGuardian's State of Secrets Sprawl 2026 found 28.65 million new hardcoded secrets exposed in public GitHub commits in 2025, a 34% increase over the prior year. AI-service-related credential leaks specifically grew 81.5% over the same period.

Investment in non-human identity management is following the urgency: the sector was valued at $10.84 billion in 2025 and is projected to reach $70.63 billion by 2035. Market growth in a governance category reflects the seriousness of the problem; it does not indicate how close the industry is to solving it.

The Four Failure Modes That Emerge When Agents Run Without SoD Controls

Every failure mode in this space traces back to the same root: over-privilege. The OWASP Non-Human Identities Top 10 from 2025 attributes 37% of NHI security incidents to over-privileged identities. An estimated 26% of organizations believe more than half of their service accounts are over-privileged. And 92% of organizations fail to rotate machine credentials on a 90-day cycle. "Forever access" is the operational default, not an edge case.

The first failure mode is privilege escalation via delegation chains. Agents inherit user roles, cache credentials, and call each other. Attackers exploit these delegation chains to reuse secrets or manipulate a high-privilege agent into acting on a low-privilege request. CVE-2025-32711, the EchoLeak vulnerability with a CVSS score of 9.3, illustrates this: a single crafted email triggered zero-click data exfiltration from Microsoft 365 Copilot with no user interaction required. A separate GitHub coding-assistant incident followed the same logic, where a malicious prompt embedded in a public issue caused an agent to exfiltrate repository data via a broad-scoped personal access token. The blast-radius principle is simple: an injected agent limited to its current task is bounded by that scope; an injected agent with inherited human-scale permissions can reach everything that person could.

The second failure mode is memory and context poisoning, which surprises people who think of agents primarily as stateless API callers. Agentic systems retain memory across sessions. That is genuinely useful. It is also a persistent attack surface. The MINJA attack, presented at NeurIPS 2025, achieved greater than 95% injection success using query-only interaction, no privileged access required. The memory layer is a trust boundary that classical SoD never contemplated, which means the framework must be extended, not merely applied.

The third failure mode is insecure inter-agent communication. A compromised agent can send spoofed instructions to peer agents. A privileged agent can inadvertently share full credentials with a lower-privilege peer. The agent-to-agent channel is, functionally, an honor system backed by whatever trust model the developer chose at setup, which is often none.

The fourth failure mode is audit fragmentation and shadow AI. Most agents are deployed without a central registry entry. Each platform records its own fragment; no system captures the full chain. This is precisely the condition that made the 87-case commission violation invisible. Per Delinea's 2025 AI in Identity Security report, a majority of organizations encounter shadow AI issues at least monthly, and that figure almost certainly understates the problem because it only captures incidents organizations were aware of.

Rethinking Who Holds Each SoD Role When the Actor Is an Agent

The reframe that actually matters: segregation of duties is not fundamentally about separating people. It is about ensuring that no single actor can initiate, approve, and execute a high-risk action without a check from a structurally independent authority. People were always just the mechanism for achieving that separation. Agents must be designed into the same structure, not exempted from it because they are not human.

Three roles must be explicitly reassigned in any agentic pipeline. The initiator, whether an agent or a human, triggers a workflow and should never also hold approval rights. The approver must be structurally independent of the initiator: separate credentials, separate authorization channel, no overlap, whether that approver is a human, a dedicated policy-enforcement agent, or a hardware control gate. The executor carries out the committed action and should have no path back to modify the approval record.

Practically, this argues for specialized sub-agents over general-purpose ones: modular pipelines where each agent's scope is narrow enough that it cannot complete an end-to-end high-risk workflow alone. A maker-checker model for agents, where one proposes a sensitive action and a separately credentialed agent or human gatekeeper verifies before execution, and neither can reach the other's authorization channel. This is not novel. It is the same control applied to a new actor type.

When agents communicate via API, the authorization decision point is the boundary that matters, not the network perimeter. Every sensitive action should pass through a central policy engine and be evaluated on its own merits, not trusted on the basis of the calling agent's identity alone. The CNCF's 2026 recommendation reflects this: SPIFFE for identity, OAuth 2.0 for access delegation, and OPA for policy. Three layers, so a credential compromise at one agent yields only the minimum permissions that agent held for its specific operation.

Dynamic Least Privilege as the Enforcement Mechanism SoD Requires

Static least privilege is insufficient for agents. Agents switch tasks frequently, interact with multiple systems, and act on prompts and context that shift throughout a session. A fixed permission set scoped to "the agent's job" is still over-broad the moment the task changes. The job title is static; the task is the actual unit of work, and the permissions should follow the task.

Dynamic least privilege means permissions that change based on what the agent is currently doing. Time-bound tokens that expire at task completion. Zero standing privilege where feasible: agents default to minimal trust between tasks, access is granted at initiation and revoked at completion. Per-agent identity is the prerequisite for all of this. Give each agent its own identity rather than a shared service account, scope its tokens to the specific tool calls and API endpoints it needs for the specific task it is executing right now, and isolate each agent's session from its memory store so cached credentials cannot persist into unrelated operations.

A four-tier action classification model gives this practical structure. Auto-approved actions are low risk, reversible, and clearly in scope; the agent proceeds. Notify-and-proceed covers moderate-risk actions, logged in real time, with the agent proceeding but surfacing the action immediately to a human monitor. Human-in-the-loop applies to high-risk or irreversible actions; the agent pauses and waits for explicit approval. Prohibited actions are outside scope entirely; the agent refuses and logs the attempt.

Certain categories require human approval regardless of agent confidence: production deploys, money movement, data deletion, privilege changes, external communications. These are non-negotiable, not because agents are untrustworthy in the abstract, but because errors in these categories are asymmetric and often irreversible. That asymmetry is the whole reason SoD exists.

One failure mode that deserves more attention than it gets is automation complacency. When approval requests arrive too frequently, reviewers stop reading them. The approval becomes a rubber stamp, which is a worse outcome than no approval queue because it creates the appearance of control without the substance. The EU AI Act under Article 14 and the NIST AI RMF both require demonstrable human oversight that is trained, measurable, and provable. An approval queue that no one reads is an SoD control in name only; auditors are starting to treat it accordingly.

What a Governed MCP Infrastructure Provides That Ad-Hoc Agent Deployments Cannot

Return to the cross-platform audit gap. SoD evaluated only at the identity level within each individual system will not catch composite violations that emerge across Salesforce, Oracle, SAP, and Workday in combination. The case cited by PwC is the proof of concept, and the architecture of most agentic deployments today, where each agent is built and deployed independently with no shared registry or centralized enforcement point, structurally guarantees that this category of violation stays invisible.

What the infrastructure layer must actually provide is specific. A centralized registry: every agent, every MCP server, every tool call recorded before deployment. An unregistered agent is an identity no one can account for, and historically the one most likely to be exploited. A gateway through which all agent-to-tool traffic passes, applying role-based access controls and policy checks in real time rather than retrospectively after an incident. Cross-system audit continuity: shared identifiers that allow a complete chain, from initiation through approval through execution through recording, to be reconstructed across platforms either in real time or after the fact.

Real-time observability is categorically different from postmortem audit logs. An audit log read after an incident is a record of damage. Genuine prevention requires visibility into what the agent is touching as it touches it. That distinction determines whether SoD controls are preventive or merely investigative, and in categories like money movement or privilege changes, investigative is already too late.

Role-based access controls for agents are not about restricting what AI can do in some philosophical sense. They are about ensuring that "what AI can do" reflects a decision the organization made deliberately, rather than one inherited by default from a convenient IAM role that happened to be available at deployment.

MCPManager, a product of Usercentrics, provides a centralized governance layer that controls, monitors, and audits how AI systems access business data via MCP, including the policy guardrails and agent registry that governed pipelines require. The shadow AI parallel is instructive: blocking MCP servers pushes adoption underground, while teams that provide a governed path reduce shadow AI more effectively than teams that ban the tools outright. The 56% of organizations hitting shadow AI issues monthly are the evidence base for what the alternative produces.

How to Assess Whether an Existing Agentic Pipeline Actually Has SoD Controls

Run these questions against a pipeline you own.

Can you reconstruct the full chain from initiation to recording across every participating system, or only the fragment each individual platform captured? If the answer is the latter, composite violations of the kind documented in the PwC case are undetectable in your environment right now. Not hypothetically; structurally.

Does any single agent hold the ability to initiate, approve, and execute a high-risk action without a structurally independent check? A check that can actually stop the action before it commits, not a logging check, not a notification.

Are SoD controls evaluated at the transaction-chain level across platforms, or only within each platform individually? Controls that exist only inside system boundaries will not catch violations that live between those boundaries.

Does each agent have its own identity, or does it operate under a shared service account or an IAM role scoped for a human? Shared credentials mean a breach of one agent is effectively a breach of every agent sharing that identity.

Are credentials rotated on a defined cycle, and does that cycle apply to agent credentials specifically, rather than only to human user accounts? Before citing the 92% failure rate on 90-day credential rotation as an industry problem, check your own environment first.

Is there a registry of every active agent, every MCP server it connects to, and every tool it can invoke? Without that registry, the organization cannot answer basic questions about its own attack surface.

Is human approval in the pipeline real: trained reviewers, manageable queues, measurable engagement? Or is it formally present but effectively bypassed through volume and fatigue?

These questions do not require a consultant or a new platform to answer. They require someone with access to the pipeline and the willingness to be honest about what they find. Most organizations, if they answer carefully, will discover the controls they believe they have are thinner than the documentation suggests.