Autonomous Agent Roles in MCP Orchestration Workflows

The role an agent occupies inside an MCP orchestration workflow sets its trust surface, its permission scope, and its blast radius if something goes wrong. Assigning roles is therefore a security decision as much as a design choice about how to wire a system together. The Model Context Protocol, introduced by Anthropic in late 2024, has become the standard way to connect large language model agents to outside tools and data, and platforms including Claude, GitHub Copilot, and Cursor now build on it as core infrastructure. Three structural pieces make up the protocol: the Host, which is the user-facing application with an embedded LLM; the MCP Client, which handles the protocol and keeps stateful sessions running; and the MCP Server, which exposes tools, resources, and prompts over JSON-RPC 2.0. A single agent can occupy more than one of these positions at once, and that overlap is where role clarity starts to matter rather than being an academic distinction.

What makes MCP genuinely different from earlier integration patterns is that tool selection happens inside the model, at inference time, based on natural-language descriptions rather than fixed code paths. An agent's role, and its read on what it's allowed to do, is never locked down by code alone. A 2026 systematic survey of agentic AI security makes the case that this is a new category of risk rather than an old one scaled up: agents hold state across turns, build multi-step plans, call privileged tools, and coordinate with other agents, all of which classical LLM threat models never had to account for. That same survey found just 6.3% of paper-cell assignments fall in the under-studied zone containing the highest-severity threats, and when you give an agent more autonomy than a simple chatbot, you widen the space an attacker can work in. Role definition is the point where an agent's capability and its security posture meet, and everything that follows in MCP orchestration, every attack class, every control, traces back to that meeting point.

The four agent roles in MCP orchestration

Orchestrator, subagent, tool caller, and delegator are the four functional roles that recur across MCP orchestration architectures. Each one carries its own relationship to trust, to permission, and to how much damage a compromise can do.

The orchestrator sits at the top. It receives the high-level task, breaks it into subtasks, and decides which agents or tools get called and in what sequence. Because it needs visibility across the whole workflow to coordinate it, the orchestrator usually runs with the widest permission scope of any role in the system, which also makes it the single highest-value target an attacker could aim for. Every other agent in the workflow treats the orchestrator's instructions as authoritative. If that authority is hijacked, the hijacker inherits the same obedience the orchestrator earned legitimately.

The subagent sits one level down. It receives a scoped task from the orchestrator, runs it using whatever tools it has access to, and sends results back up the chain. In principle, a subagent should not be able to find or call tools outside the narrow job it was given. But if the workflow has no explicit scoping controls built in, it often can, and that gap between intended isolation and actual isolation is where several of the attack classes discussed later take hold.

The tool caller is the role that actually picks and invokes a specific tool to get a subtask done. Because the LLM chooses which tool to call by reading a natural-language description of what that tool does, anyone who controls the wording of that description can shape the tool caller's behavior. That fact is the foundation of the tool poisoning threat class, which later sections return to in detail.

The delegator is the role that hands authority, a credential, a signed task, an access token, to another agent or service. Delegation raises a question that doesn't come up with the other three roles: was the receiving agent issued that authority for its own use, or is it holding it temporarily on someone else's behalf? MCP and the Agent-to-Agent protocol, or A2A, work as two separate layers that answer different halves of that question. MCP governs the vertical connection between an agent and its tools. A2A governs the horizontal connection between agents, so agents built by different vendors can find each other, hand off tasks, and exchange results. The delegator role lives right at the boundary between those two layers. The Linux Foundation's AAIF governs both protocols, and it counts more than 140 enterprise members.

How trust flows across roles

Trust in an MCP orchestration workflow is not one property that the whole system either has or lacks. It moves in a direction, from role to role, and every handoff along that path is a place where it can fail.

An agent extends trust to whatever role sits above it in the chain of command. Subagents trust the orchestrator that assigned their task. Tool callers trust the tool descriptions they read. Agents on the receiving end of a delegation trust the authority handed to them by the delegator. Trust carries forward from one handoff to the next, so a single compromise anywhere in that chain can ride it all the way through the rest of the workflow.

The orchestrator-to-subagent handoff is especially fragile. If one subagent is compromised in an enterprise multi-agent pipeline, it can spread malicious intent through peer-to-peer trust relationships, and the entire orchestration network ends up at risk from that one point of entry. Gateway and control-plane systems enforce policy and keep audit logs across every session, and you need them to contain this kind of lateral spread before it reaches the rest of the workflow. Security leaders take the underlying risk seriously: NeuralTrust's 2026 CISO survey found 73% rate AI agent risk overall as very or critically concerning.

The tool-caller-to-MCP-server handoff fails differently. A malicious MCP server looks, from the agent's side, exactly like a legitimate one. It can quietly pull sensitive data out of a session through instructions hidden inside its own tool descriptions, with nothing in the agent's behavior signaling that anything went wrong.

The delegator handoff raises its own version of the same problem, but this time it involves tokens and credentials rather than tool calls. Without a check that binds a token to the specific server it was meant for, a token issued for one server can be handed to a completely different one and accepted there. AIUC-1's Q2 2026 standard requires dedicated controls covering MCP and A2A authentication, transport security, message integrity, and runtime containment, built specifically to close gaps that older API-only security rules never addressed. The 2026 survey work adds a timing dimension that any role-based analysis needs to account for: some attacks get installed in one session and triggered in a later one, and others build up gradually across many sessions. Trust granted to a role in one context can resurface as leverage in a completely different context later on.

The attack classes that exploit role boundaries in practice

Every major MCP attack class documented in 2026 targets a specific boundary between roles, so if you know which boundary is under attack, you know which defense applies.

Tool poisoning targets the tool-caller boundary. An agent reads a tool's description with roughly the same trust it gives its own system prompt, so if a malicious server buries instructions inside that description, it can redirect the agent's actions without touching the application's code. The MCPTox benchmark ran adversarial versions of real tools, pulled from live MCP servers, against several leading language models. Even Claude-3.7-Sonnet, the model that refused the most often among those tested, still complied with poisoned instructions most of the time.

Indirect prompt injection targets the subagent boundary. Rather than hiding malicious instructions in the prompt itself, an attacker hides them in external data the agent is told to process, a document, a webpage, a response returned from an API call. The subagent reads that data as part of its normal task, absorbs the hidden instruction, and carries it out, so it slips past input validation that was only ever built to catch direct injection attempts. NeuralTrust's 2026 CISO survey found only a minority of organizations have any prompt injection filtering running at all, and the filters that do exist often fail against the multi-step pattern indirect injection relies on. The risk grows sharper once subagents carry agentic browsers into the mix: an agent visiting a compromised page can pick up an indirect injection that turns it from a passive task, gathering information, into an active one, taking a high-privilege action against systems inside the organization.

Parasitic tool chaining targets the orchestrator's scope. An agent starts with legitimate access to one tool, then uses that access as a stepping stone to find and call other tools that sit outside its approved workflow. The orchestrator's own broad permission scope is what makes the cascade possible. The MCP-38 threat taxonomy gives this pattern its own named category, parasitic tool chaining, and maps it against STRIDE, the OWASP Top 10 for LLM Applications, and the OWASP Top 10 for Agentic Applications.

Confused deputy attacks and token passthrough both target the delegator boundary. A server accepts an authorization token that was never meant for it, then forwards or reuses that token against some other downstream system. The June 2025 revision to the MCP spec classified MCP servers as OAuth Resource Servers and required clients to implement RFC 8707 Resource Indicators, which binds each access token to one specific server to prevent this kind of misuse, but adoption of that requirement has lagged well behind the spec itself. The spec now states that a server must not forward a token it received upstream, but that rule only holds if the implementation actually enforces it; the protocol text alone does nothing.

The MCP spec's authorization model and the role-level permission gap

The MCP 2026-07-28 specification makes real progress on authorization at the protocol level, but it cannot enforce the role-level permission boundaries that the attack classes above depend on. The May 2026 release candidate for this version is described by the protocol's lead maintainers as the largest revision since MCP launched. It aligns MCP authorization with OAuth 2.1 and OpenID Connect, formally treats MCP servers as OAuth 2.1 Resource Servers, makes token audience binding mandatory, replaces Dynamic Client Registration with Client ID Metadata Documents, and lays out three separate authorization paths: delegated user flows, unattended agent flows, and enterprise-managed identity provider flows.

Mandatory token audience binding closes the exact gap behind confused deputy attacks: without it, an agent holding a valid token for Server A could hand that same token to Server B, and if B accepts any well-formed token from the right issuer, B ends up acting on A's authority without ever checking whether that was intended. The new autonomous-agent path, built on the MCP OAuth Client Credentials extension, lets an agent or background service authenticate with an authorization server directly, giving agents acting for themselves a defined route that didn't exist before, separate from flows built for agents acting on behalf of a human user. And the spec now states outright that an MCP server must not pass through a token it received from the client.

None of that reaches the gap this piece has been building toward. The spec defines how an agent proves who it is and sets up authorization paths for doing so, but it does not mandate how permissions get scoped to individual tool calls inside a session that's already been authenticated. If the operator doesn't build tool-level controls separately, on top of what the spec requires, an authenticated client can still call any tool the server exposes. An implementation can satisfy authentication requirements while leaving the authorization side unaddressed.

The distance between what the spec requires and what's actually deployed remains wide. A meaningful share of MCP servers running today ship with no authentication at all, and many of the ones that do authenticate users or agents still don't scope tool permissions once that authentication succeeds. The spec can define the rules for proving identity. It cannot, by itself, decide what an orchestrator, a subagent, a tool caller, or a delegator is actually permitted to touch once it's in the door, and that decision is still sitting with whoever builds and operates the workflow.