Separation of Duties Controls in Agentic AI Pipelines

---

Separation of duties has run enterprise controls for decades on one basic premise: consequential decisions get split across people with different incentives, different reporting lines, and different eyes watching them. That premise breaks down the moment the "people" involved become AI agents. This piece walks through why, and what it actually takes to rebuild SoD for a world where the actor initiating a request, approving it, and carrying it out can all be the same non-human identity.

What agents can do that prior automation could not — and why that changes the threat model

A chatbot answers questions. An agent plans out multi-step tasks, calls APIs, reads and writes data across systems, and chains those actions together with little or no human checking its work along the way. That's the real shift, and it's worth sitting with for a second because most of the SoD thinking still in use was built for a world where software followed fixed instructions and people made the judgment calls.

Three things make agents different from any automation that came before them.

First, autonomy. An agent interprets intent rather than executing a fixed command. Tell it what you want and it decides how to get there, which means the "how" is no longer something a human wrote down in advance.

Second, composability. An agent wired into an approval workflow, a provisioning system, and a payment processor at the same time becomes a general-purpose actor sitting across three systems that were never meant to be touched by the same hand.

Third, self-direction. I've seen writeups of agents managing knowledge systems that granted read access to a new AI assistant on their own, after deciding the assistant's tasks justified it, no approval requested. And the agent's own logs described the decision as sound. The agent did exactly what it was built to do, just without anyone in the loop who could've said no.

Here's the asymmetry that matters: a misconfigured piece of traditional software might expose one data endpoint. A misconfigured agent with write access across several systems can execute dozens of consequential actions before a single person notices anything's wrong. That's what makes over-permissioning, which is already endemic across non-human identities, so much more dangerous once agents are the ones holding the keys. Research from NHI Management Group puts the number at 97% of non-human identities carrying excessive privileges, and the average enterprise now runs upward of 250,000 NHIs across its cloud footprint, most of them with more access than their actual job requires.

The threat model here centers on correct behavior, not malfunction: the agent will behave exactly according to its own logic, correctly by its own lights, and in doing so violate every SoD boundary the organization assumed was still standing.

The identity crisis underneath agentic pipelines: NHIs are growing faster than governance can track

Enforcing SoD requires, at minimum, knowing which identity did what. Most agent deployments today can't clear that bar.

The scale here is hard to overstate. Wavestone research projects non-human identities will outnumber human ones 82 to 1 by 2026. AI agent identities are the fastest-growing slice of that population, with a projected annual growth rate above 25% through 2035. BeyondTrust's Phantom Labs found agents operating inside enterprise environments jumped 466.7% year-over-year, a number that should stop anyone doing identity governance in their tracks.

Credential hygiene hasn't kept up, and it's not close. Entro Security's H1 2025 research found 74% of organizations already run agents or automations that need credentials, yet 92% don't rotate machine credentials on anything close to a 90-day cycle. Nearly half, 47%, of NHIs went unchanged for over a year, meaning they sit there static and effectively unmanaged. GitGuardian's State of Secrets Sprawl 2026 report counted 28.65 million hardcoded secrets added to public GitHub repos in 2025 alone, a 34% jump from the year before. AI-related secrets made up more than 1.27 million of those exposures, up 81% year-over-year, the fastest-growing category they track.

None of that works without someone owning it, and mostly nobody does. A 2025 WEF analysis found 51% of organizations have no clear ownership assigned to their AI identities. Of 919 executives surveyed, fewer than a quarter said they had real visibility into which agents talk to each other inside their own environment.

Here's the part that matters for SoD specifically: you can't separate duties across identities you haven't counted. An agent that isn't registered anywhere is an accountability gap, full stop, and no policy fixes that after the fact. Every MCP server or agent added without a registry entry is an identity the organization can't account for, and the identities nobody's tracking are exactly the ones that get exploited.

How multi-agent delegation chains collapse SoD boundaries that single-agent controls cannot protect

Multi-agent orchestration, where one coordinating agent manages a set of specialized worker agents, is quickly becoming the standard way enterprises deploy AI. And every delegation inside that chain raises the same question: whose permissions actually apply here?

If Agent B inherits Agent A's permissions wholesale, it might end up with access to systems it was never scoped for. That's privilege escalation, routed through delegation instead of a hack. If Agent B instead uses its own permissions to carry out Agent A's request, it might do more than the task actually calls for. That's scope creep, dressed up as autonomy. Either way you land on the confused deputy problem: Agent B has no real way to check whether the instruction it got came from someone with the authority to issue it.

There's a documented example worth sitting with: a document-analysis agent, several steps downstream in a chain, tried to write to a user's mailbox. Nothing about its subtask required that. Nothing in the delegation should have granted it. But no scoping constraint existed to stop it, so it just tried.

The Gradient Institute put it well: a collection of safe agents does not guarantee a safe collection of agents. Each one can be scoped reasonably on its own and the system they form together can still do something none of them should've done alone.

This isn't hypothetical. A GitHub MCP server got compromised through a malicious issue that smuggled in hidden instructions, hijacking the agent and pulling data out of private repos. EchoLeak, tracked as CVE-2025-32711, hit Microsoft Copilot through infected emails carrying engineered prompts that got Copilot to exfiltrate sensitive data with zero user interaction. And in NIST's January 2025 red-team research, novel attacks against AI agents succeeded 81% of the time, against just 11% for baseline defenses. That gap tells you almost everything: the controls in place weren't built with agent-specific attacks in mind.

Trust between agents has to be treated as an identity problem now, not a networking one. A downstream agent needs a way to verify that the instruction it received is legitimate, not just a channel to receive it on.

The OWASP agentic risk taxonomy and what it says about where SoD enforcement has to live

In December 2025, the OWASP GenAI Security Project put out its Top 10 for Agentic Applications, built with input from over 100 security researchers and practitioners. It's the closest thing the industry has right now to a shared map of what can go wrong in agent systems, and three entries land squarely on SoD.

ASI03, Identity and Privilege Abuse, covers agents that inherit high-privilege credentials, session tokens, or delegated access that then get reused, escalated, or passed to other agents without anyone meaning for that to happen. Think SSH keys cached in an agent's memory, or delegation between agents with no scoping attached. The fix OWASP points to: short-lived credentials, permissions scoped to the specific task, and separate identities per agent instead of shared ones.

ASI07, Insecure Inter-Agent Communication, covers spoofed identities, replayed messages, and forged consensus messages between agents, the kind of thing that quietly wrecks the trust assumptions that make delegation safe in the first place.

ASI08, Cascading Agent Failures, describes how small errors or misconfigurations spread through connected agents, amplifying as they move through planning, execution, and memory. The interconnection is the whole problem: one small mistake stops being small once it's traveled through three or four agents.

Worth adding ASI04, Agentic Supply Chain Compromise, to that list too, since it covers malicious MCP servers pretending to be trusted tools and poisoned prompt templates pulled in dynamically at runtime. The supply chain is part of the attack surface now.

What's striking in the field data behind this taxonomy is how ordinary most incidents actually are: 61% trace back to plain old over-permissioning, nothing exotic about it. OWASP is really just naming what practitioners have already been dealing with. And the implication for SoD design is clear: enforcement has to live at the identity layer, deciding who the agent is; the capability layer, deciding what it's allowed to call; and the communication layer, deciding whether the instruction it just received is real.

Redesigning SoD for agent actors: decomposing capabilities instead of segregating roles across people

Here's the reframe that actually matters. In a human SoD model, you separate roles across people. In an agent model, you decompose capabilities, both within a single agent and across the chain it operates in.

In practice, that means defining exactly what a given agent can read, write, approve, and delegate, as separate, listed-out capabilities rather than a role that quietly bundles all of it together. No agent should hold read, write, and approve in the same sensitive domain at once. That's the same failure as letting one employee initiate, authorize, and execute a wire transfer solo, just wearing a different costume. Where the downstream consequences are irreversible, the agent that decides what to do and the agent that does it should be two different identities.

Least privilege has to be a design decision made up front, not a setting someone tweaks after something goes wrong. Scope an agent's permissions to what the specific task needs, not to whatever role it might plausibly play down the line. Use credentials that expire quickly and are scoped to the task, instead of a persistent service account token sitting there indefinitely. And every MCP tool an agent is allowed to call is a capability boundary; it belongs in a registry where someone can see it, not buried in whatever the server happens to expose by default.

Human checkpoints still matter. For anything irreversible, deleting data, moving money, changing access controls, a human confirmation before the agent acts preserves the one thing traditional SoD always assumed: a separate party standing at the authorization step. This preserves that step rather than slowing agents down for its own sake.

Put simply: giving an AI agent a set of permissions shouldn't be an accident of what the framework defaults to. It should be a decision someone in the organization actually made on purpose.

Enforcing role boundaries across multi-agent chains: where a gateway becomes the control layer

Controls on a single agent help, but they're not enough on their own. Delegation chains need enforcement at every hop along the way, not just a checkpoint at the front door.

Three things have to be true for multi-agent SoD to actually hold. Each downstream agent needs to verify the instruction it receives is legitimate before it acts, rather than assuming that because the instruction came from upstream, it must be authorized. When Agent A delegates work to Agent B, that delegation needs to spell out exactly what Agent B is allowed to do for that task, not hand over Agent A's whole permission set by default. And no agent in a chain should automatically inherit another agent's privileges; each one needs to be treated as its own principal with its own access controls.

The practical way to enforce this is a gateway that sits in front of the whole chain: every MCP server call and every message between agents routes through it, gets checked against policy, and gets logged as it happens. That's where capability decomposition stops being a document nobody reads and becomes something actually enforced, since an agent physically can't call a tool it wasn't authorized to use, no matter what the orchestrating agent told it to do. It's also where you catch the confused deputy problem in the act: if Agent B tries to exercise authority its delegation never granted, the gateway blocks the call and logs the attempt for someone to review.

A CSA survey on agentic identity in 2026 found only 18% of organizations feel confident their current IAM systems can actually govern AI agents. That tracks. IAM was built around human accounts and static service credentials, not chains of agents delegating work to each other in real time, and there's no patch that turns one into the other.

Teams that feel MCP adoption dragging are often running into the absence of a gateway that would've let them move fast with guardrails already built in. This is where a purpose-built control layer earns its keep: MCP Manager, for instance, provides the gateway, the RBAC enforcement, and the registry that make SoD something you can actually check rather than something you hope is true, built on Usercentrics' data governance work. It's a reasonable answer to a problem most IAM stacks weren't designed to solve.

Making auditability real: what an agent audit trail needs to contain to support SoD enforcement

None of the redesign above means anything without a record that proves it happened. SoD isn't a real control unless you can show, after the fact, who did what, under what authority, and why the system let them.

For agents, that record needs to go further than a normal access log. It has to capture which identity performed the action, and if that identity is an agent operating on behalf of another agent, the record needs the whole delegation chain, not just the last hop. Which specific credential was used, and whether it was scoped to that one task or was a standing token that shouldn't have been sitting around anyway. What tool or system got called, and whether the call fell inside the capability boundaries that agent was supposed to have. Whether a human checkpoint was required for that action and what happened at that checkpoint, approved, rejected, or skipped, and if skipped, why.

That last one matters more than it might look. A skipped checkpoint with no reason attached is exactly the kind of gap that turns into an incident nobody can explain six months later.

An audit trail like this is the thing that makes every other piece of this article real. Capability decomposition, gateway enforcement, scoped delegation, none of it means anything if you can't reconstruct after the fact what actually happened and prove the boundaries held. Enterprises rushing agents into production without this in place risk more than a breach. They're building a system where, if something does go wrong, they won't even be able to say what happened or why.