Separation of Duties Enforcement in Multi-Agent Pipelines

Classical separation of duties says no single actor should hold the whole chain of a sensitive transaction: the person who requests a wire transfer isn't the person who approves it, who isn't the person who sends it. That model was built for humans working at human speed, where every step leaves a name, a timestamp, and a pause long enough for someone to catch a mistake. Multi-agent pipelines break all three assumptions at once. Gartner projects 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from under 5% in 2025, and the control frameworks riding along into that shift were never built for an actor that isn't a person. In a pipeline where a planner hands off to a researcher, who hands off to an executor, who hands off to a verifier, the "actor" is a chain, not a person, and Kovrr's analysis shows three agents can each hold modest, individually reasonable permissions that compose into an action none of them was authorized to take alone. Fixing this at the permission layer won't work. It has to happen at the architecture layer.

How multi-agent trust models create the conditions for SoD collapse

Most multi-agent systems in production today run on implicit peer trust: one shared credential, inherited across the whole session, with no re-authentication between hops. Compromise one agent and the blast radius is every agent it can talk to, because trust was never scoped to the interaction. It was scoped to the session, which is a much bigger and much lazier boundary.

That structure lets a low-privilege agent talk a higher-privilege one into acting on its behalf, with nothing that looks like an authorization event ever happening. As a planner delegates to specialist sub-agents, scope tends to drift outward at each hop rather than staying put, and a lot of those sub-agents are transient: spun up for a task, used once, torn down, never registered anywhere. By the time a terminal API call fires, the decision chain behind it may be impossible to reconstruct. Attribution doesn't degrade gracefully here. It just falls off a cliff.

Trust also behaves transitively in these systems in a way it never does in human organizations. If Agent A trusts Agent B, and Agent B trusts Agent C, Agent A ends up trusting Agent C by default, no HR department required. That's the classic confused-deputy problem, except now it scales across an entire delegation chain instead of tripping up one API call: an outer agent acting on a user's behalf gets manipulated into instructing a more privileged inner agent to do something neither the user nor the outer agent ever intended.

Shared memory compounds the problem. Agents pass context back and forth, and one agent can request or forward information well past its actual need-to-know. Worse, a hallucination that lands in shared memory doesn't stay a hallucination. Downstream agents treat it as fact, because nothing in the architecture tags it otherwise. Each individual grant, taken alone, looks fine. The violation only shows up once someone models the full chain as a single unit, which is exactly the kind of review conventional IAM tooling was never built to do. Research accepted at ICLR 2025 backs this up at the model level too: large language models cannot reliably tell instructions apart from data, so no amount of prompting discipline substitutes for a control that sits outside the model.

Prompt injection and memory poisoning as active SoD bypass mechanisms

Prompt injection isn't a novelty attack anymore. In multi-agent systems it's structurally amplified, because inter-agent messages are usually trusted by default, tool outputs go unsanitized, and the whole trust hierarchy runs on implicit assumptions nobody wrote down. Run the math on detection: a filter that catches an injection 70% of the time at any single hop only has a 17% chance of catching it across five hops. Pipelines multiply the probability of failure, not the probability of success. That's not a rounding error, that's the whole game.

The most dangerous variant is control-flow hijacking through a confused deputy: attacks target the metadata and control-flow logic that decide which agent gets invoked next, redirecting execution toward an adversary's chosen agent rather than the intended one. OWASP's ASI06 category covers the related problem of memory and context poisoning: corruption that sits in the context window or long-term memory, shaping decisions long after the session that introduced it has ended, and spreading to other agents that share the same store. Systems that pool context from agents operating at different classification levels into one unified session store, per arXiv:2603.09002, build in a cross-contamination risk that traditional single-user applications never had to think about.

The incidents aren't hypothetical. EchoLeak, tracked as CVE-2025-32711 and disclosed in mid-2025, hit Microsoft 365 Copilot: crafted prompts embedded in email triggered automatic exfiltration of sensitive data with zero user interaction, collapsing the request and execution roles into a single automated chain. A malicious MCP package discovered in 2025 impersonated a legitimate email service and quietly copied every message it handled to an attacker; when an orchestrator picks a peer agent based on nothing more than its published description, a well-written lie in that description is the entire attack surface. Invariant Labs demonstrated a GitHub MCP exploit the same year that reached private repositories through tool-layer trust, crossing a boundary the pipeline was never supposed to let it cross. Researchers have also demonstrated vulnerabilities where project-contained code executed before the user ever saw, let alone accepted, the trust dialog. The approval step that separation of duties depends on got bypassed at the protocol level, not the application level. Every one of these incidents shares the same fingerprint: nobody broke an individual permission. The gap exploited was between what each agent was authorized to do and what the composed chain actually pulled off.

Where MCP and A2A leave SoD enforcement unaddressed

MCP, introduced by Anthropic in late 2024, standardizes how agents reach tools, data sources, and prompts through a client-server setup. It caught on fast: Wiz Research found MCP servers running in at least 80% of observed cloud environments in early 2026, and 5% of those environments expose at least one MCP server directly to the internet. An empirical study across 177,436 tools in public MCP repositories found the share of "action" tools, meaning tools that modify something in the outside world rather than just reading from it, rose from 27% to 65%. That's a fast move from read-only to write-capable, and write-capable is where separation of duties actually matters. MCP picked up OAuth 2.1 support and has accumulated tens of millions of monthly SDK downloads. Adoption is way out ahead of governance, and it isn't close.

The specification says servers "MUST sanitize tool outputs" and clients "SHOULD validate tool results before passing to LLM," but as of this writing, the reference SDK doesn't enforce either one as a mandatory default, though optional output schema validation exists for structured content. There's no credential revocation when a session closes, no consent gate for sensitive tool calls, no mandatory audit trail. Signed capability declarations exist as a concept, but enforcing them is a deployment choice, not something baked in.

A2A, announced by Google in April 2025 and handed to the Linux Foundation that June, handles agent discovery and delegated execution between agents. Neither A2A nor MCP specifies any governance primitive: no enforceable action constraint, no audit-grade provenance, no way to detect collusion between agents. An agent that bridges the two protocols has to reconcile two separate trust models with its own logic, and that semantic gap is itself something an attacker can work with. Both standards solve transport and discovery. Neither one touches the actual separation-of-duties question: who gets to propose an action versus who gets to approve it, and how that boundary holds up across agent-to-agent calls. Software development alone accounts for 67% of all agent tools and 90% of MCP server downloads, which means the sector with the deepest MCP penetration is also the sector with the most write access sitting exposed.

The reasoning-execution split as the foundational SoD control

The model that generates intent should never hold direct administrative access to the systems it's reasoning about. That's the whole principle, and everything else follows from it. Split the reasoning layer, the part producing a plan or proposing an action, from the execution layer that actually carries it out against real infrastructure, and put an independent policy decision point between the two. Done right, even a fully compromised reasoning model stays boxed in by deterministic policy rules it has no way to talk its way around.

Call it the agentic version of four-eyes review: the agent proposing an action can't be the agent approving it, and that separation has to be enforced at the identity and context level, not just assigned as a role label somewhere in a config file. Delegation events need logs that capture the orchestrator's identity, the sub-agent's identity, and the exact context passed between them, so the chain of authority can be reconstructed after the fact rather than guessed at.

OWASP's Top 10 for Agentic Applications 2026 introduces a concept worth sitting with: Least Agency, which extends least privilege into the autonomy dimension. It's not only about what an agent can access. It's about how much it can do with that access before it has to check back with anyone. Agents should get the minimum autonomy their task actually requires, and the decision about which actions run independently versus which need a human in the loop belongs to business owners, not to whichever developer shipped the fastest. Practically, this means scoped credentials that expire per task, not a standing API key an agent holds for the length of a session. This architecture handles the vertical split between reasoning and execution well. It says nothing about peer agents sitting at the same tier, talking to each other, which is a separate problem needing its own controls.

Agent identity and per-edge authorization as the enforcement substrate

Three trust models cover most of what's deployed today, and they carry very different risk. Implicit peer trust, the shared-credential model, is the weakest: the weakest and never acceptable in production touching regulated data. Role-based trust does better, but only if role assertions are cryptographically bound rather than just self-declared, otherwise nothing stops an agent from claiming a role it doesn't have. Per-edge zero trust is the strongest posture: every communication edge gets independently authenticated, authorized, and encrypted. It's also the most work to build, and it's mandatory once agents cross an organizational trust boundary or touch data where a compromise can't be undone.

None of this is theoretical. SPIFFE/SPIRE workload identity gives each agent a cryptographically verifiable SVID that has to be presented and checked against a SPIRE trust bundle on every inter-agent call. Per-edge policy evaluation checks each communication edge against the specific combination of caller identity, callee identity, requested action, and current context, using something like OPA/Rego or Cedar to make the call. Dynamic trust scoring adjusts an agent's standing based on behavioral history and disables edges once a score drops below threshold, catching anomalies at the network level instead of waiting for a bad action to happen first.

None of it works without an agent registry. Every active agent, including the transient sub-agents that get spun up and torn down mid-task, needs to be cataloged: underlying model, scope of agency, tool permissions, memory architecture. Skip the inventory and there's no perimeter to defend, because shadow AI fills the gap with agents nobody's tracking. Delegation events need signed provenance too, so lineage can be traced at any point in the chain: who authorized what, and when. It's the audit trail that follows the transaction itself, not just the final action it ends in.

Execution isolation, tool governance, and bounding what the network can accomplish

Every agent session should run in its own process space, so a compromised session can't reach into another one's execution domain, per NIST 800-53 SC-39. That means ephemeral containers, read-only root filesystems, non-root execution, and network access limited to a specific allowlist of endpoints. No shell access unless the agent's job actually calls for it. No outbound internet unless the destination URL is explicitly whitelisted.

Tools need a home too: a centralized registry with risk ratings, not ad hoc deployment by whichever team gets there first. Every MCP server or tool integration should pass a risk rating, a data classification check, a security review, and a source audit before it goes live, and access should get reviewed quarterly, because agents quietly accumulate new SaaS integrations over time without anyone circling back to check whether they still need them.

Bounding has to happen at the network level too, not just per agent. Token budgets, API call caps per session, maximum execution time per workflow: these set the ceiling on what the whole pipeline can do together, not just what one agent can do alone. Cost circuit breakers matter here in a way that's easy to underrate. A workflow burning resources at an anomalous rate isn't a billing problem, it's a signal: runaway delegation, or a reasoning loop that's gone somewhere it shouldn't have. RAG pipelines need the same discipline. Retrieval-level authorization should make sure an agent querying a vector store only pulls documents it would be cleared to read directly, not a wider slice of the corpus just because it happens to live in the same shared index. Documents need classification before ingestion, and provenance tracking on anything retrieved and handed to the reasoning layer. The Open Security Architecture SP-047 pattern names the underlying issue plainly: ungoverned agent deployments are shadow IT's successor. When a team runs agents outside the managed platform, every control described here gets bypassed in one move. Governance has to live in the platform itself, not in a policy document nobody consults at 2 a.m. when the pipeline is already running.

What runtime monitoring must catch that pre-deployment controls cannot

Pre-deployment controls check whether a system is built correctly. They can't catch what a system does once it's live and improvising, which is most of what a multi-agent pipeline actually does. Runtime monitoring is the layer built to catch exactly that gap, and it's the one most organizations haven't built yet.

The composition problem doesn't show up in a static review. Three agents with individually reasonable permissions only look dangerous once their actions are chained together in production, in an order nobody pre-approved because nobody could have predicted it. Trust scores drift as agents behave in ways training and testing never covered. Delegation chains stretch past whatever depth got modeled during design. None of that is visible before deployment, because none of it exists yet before deployment. It only becomes visible while the pipeline is actually running, doing the job it was built to do, occasionally in ways nobody signed off on.

That's the argument for treating separation of duties as a live property of the system, not a box checked once at design time. A pipeline can pass every architectural review and still compose a violation at 3 a.m. on a Tuesday, because the chain that produced it never existed until that exact moment. Monitoring has to watch the composed behavior of the network, not just the individually authorized behavior of each agent in it, because by the time a human reviewer would normally step in, the transaction that mattered has already completed. Machine speed doesn't wait for the four-eyes check. It just executes and moves on to the next task, permission slip already spent.