Building Agentic AI with MCP Orchestration

MCP orchestration is the wiring that lets an AI agent reach outside its own model weights and actually do things: look up a record, book a flight, query a database, call another agent. This pattern runs between an AI client, which is the model or agent runtime, an MCP server, which brokers capabilities, and individual tools. The server's job is narrow but critical: match incoming requests to registered capabilities, then route the results back up the chain.

That sounds like a conventional API, but it runs backward. In a conventional API, the client asks the server for data and the server hands it over. MCP often flips that: the server queries and executes actions on behalf of the connected client. The NSA's guidance from May 2026 described this inversion directly, calling it "new and largely not well-traced attack paths". That phrase is doing real work. It means the industry does not yet have a mature map of how this reversed trust relationship gets abused, because the pattern itself is new.

A travel-booking agent makes the mechanics concrete. An agent assembling an itinerary uses MCP to orchestrate location lookup, visa retrieval, and flight search across separate tools, all inside one workflow. Each of those steps is a discrete tool call routed through the MCP server. The server sits in the middle of every one of those calls, deciding what's permitted and passing results back.

The protocol defines two transport mechanisms for carrying these calls. Streamable HTTP transport handles remote server connections. STDIO, standard input and output, is recommended for local tool integrations: the spec says clients SHOULD support stdio whenever possible, and it's the mechanism shown in Anthropic's official documentation and the most widely deployed path in the ecosystem.

The enterprise case for building on MCP rests on its neutrality. The protocol now sits under the Linux Foundation's Agentic AI Foundation, and new contributions are licensed under Apache 2.0 after it transitioned from MIT. OpenAI, AWS, Google, Microsoft, Cloudflare, and Bloomberg are founding or platinum members alongside Anthropic and Block. OpenAI deprecated its own proprietary Assistants API in favor of the Responses API, which has built-in MCP support, and it set an August 26, 2026 sunset date for the old system.

How a multi-agent architecture maps onto MCP's layers

MCP can handle a single agent calling a single tool, but that's as simple as it gets. Production deployments rarely stay that simple. In a multi-agent MCP deployment, orchestrator agents decompose a task and delegate pieces of it to specialist sub-agents, and each of those sub-agents invokes its own MCP tools. The protocol has to carry identity, intent, and permissions across every hop in that chain, including the point where a human first typed a request.

A working MCP orchestration stack has four components. You start with the user-facing interface or application, the entry point for human intent. There's the LLM runtime, which interprets that intent and formulates structured tool requests. Then there's the MCP server, the capability broker that matches requests to registered tools and enforces what the spec allows. And there are the tools themselves, the actual systems being called.

But if you chain a few agents together, orchestration starts to mean something specific. An orchestrator agent passes a sub-task to a specialist agent over a cross-agent communication interface. That specialist agent then invokes MCP tools using its own credentials, not the orchestrator's. Results flow back up through the chain. Every link in that chain is an independent trust boundary. A permission granted at the top doesn't automatically mean anything at the bottom. It has to be checked, hop by hop.

A financial operations team's setup makes this tangible. A Copilot Studio agent connects to a Dataverse MCP server for vendor master data, an Outlook connector, and a third-party invoice enrichment MCP server. That gives you three separate tool connections, and each one has its own server, its own trust relationship, and its own permission surface. The architecture produced that outcome on its own, because every MCP server a workflow touches is its own island of trust.

That is where the protocol's design choices start to cost you. MCP blends instructions with data, makes authentication optional by default, and gives servers elevated execution privileges. None of those are implementation mistakes that careful engineering can fix. They're structural defaults built into the specification, and they create gaps that persist regardless of how carefully a given deployment is built.

The authentication gap is the clearest example. MCP does not define how a session maps to a verifiable identity. Authentication is optional in the spec for local stdio transports, though it's now mandated for remote HTTP-based servers under the 2026-07-28 revision. Role-based access control isn't part of the protocol at all. When the Cloud Security Alliance scanned the internet in 2025, it found thousands of publicly accessible MCP instances responding to unauthenticated requests, because the protocol makes this security control optional instead of requiring it.

Blending tool descriptions with the data a tool returns compounds this problem. MCP blends tool descriptions, the natural-language metadata the model reads to decide how to call a tool, with the data that tool returns. Changing a tool's metadata can shift an agent's behavior as thoroughly as rewriting its system prompt, with no code change anywhere in the system.

The STDIO transport carries a flaw of the same structural kind. It executes operating system commands without sanitization or validation. Anthropic confirmed the behavior is intentional, and it declined to modify the protocol architecture, so remediation falls to individual downstream developers. That decision propagated the flaw into the official MCP SDKs in Python, TypeScript, Java, and Rust, and from there into every downstream project that trusted the reference implementation.

Credential storage follows the same pattern. MCP servers often store credentials and API keys in plaintext configuration files, so every client that connects to that server inherits the same privileged access, no matter what the requesting user is actually entitled to. That setup produces what security researchers call the confused deputy pattern: a user without database admin access asks an agent to run a query, the MCP server (which does have admin access) complies without checking the requesting user's actual permissions, and the server acts on its own elevated privileges instead of scoping down to the user's.

The four attack classes that exploit these gaps in production

The MCP-38 threat taxonomy catalogs 38 distinct threat categories, organized into five risk categories, and every one of them follows directly from the protocol's design defaults, not from some separate, newly discovered vulnerability. Four attack classes illustrate how that plays out in actual production incidents.

Tool description poisoning exploits the instruction-data conflation directly. An adversary modifies a tool's description, the natural-language metadata the agent reads to decide how to use it, and the model misinterprets what the tool does, executing attacker-directed behavior with no code change. Microsoft's security blog from June 2026 walked through exactly this in a finance workflow: a developer silently modified the enrichment MCP server's tool description to instruct the agent to retrieve and exfiltrate the last thirty unpaid invoices. Its name and its user-facing summary stayed the same, so no re-approval prompt ever triggered. The attack lived entirely in metadata nobody was watching.

Indirect prompt injection widens the same gap to any data the agent reads, not just the user's own input. If malicious instructions sit in a tool's returned data, they can hijack everything the agent does next. CyberDesserts documented this in a report covering the Agentjacking research from Tenet Security: a Sentry MCP event injection where organizations with injectable DSNs could have their agent's actions redirected. Sentry declined to remediate the root cause and deployed only a payload-string filter, but the company later made substantial changes to the MCP server, including migrating to the 2026-07-28 spec and adding new tool capabilities.

Dynamic server capability drift attacks the trust model's biggest blind spot: time. A server's capabilities can shift after it's already been approved, and the agent keeps trusting it based on that initial review even though its actual behavior has changed since. The base protocol has no re-approval mechanism to catch that drift.

Speed is what makes all three of these dangerous in practice rather than theoretical. The same research that documented the Sentry case found that exposed credentials got used against live APIs within seconds in most observed cases, faster than audit logs reach a defender. By the time a security team sees the log entry, the exploit has already run.

MCP specification changes to authentication and authorization in July 2026

The 2026-07-28 revision is the protocol's most direct answer to the authentication gap described above, and here is what it actually requires. MCP servers are now formally defined as OAuth 2.1 resource servers, a role first introduced in the 2025-11-25 spec and tightened in this revision. Servers must implement OAuth 2.0 Protected Resource Metadata under RFC 9728, so that clients can automatically discover the correct authorization server rather than hard-coding it. Clients, in turn, must implement Resource Indicators under RFC 8707, specifying explicitly which MCP server a given token is meant for. That requirement closes a specific hole: without it, a malicious server could obtain a token that was actually meant for a different, legitimate server.

If an agent runs without a human in the loop, the spec gives it an OAuth Client Credentials extension. So an autonomous agent, a background service, or a CI/CD job can authenticate directly with the authorization server, and nobody has to click a consent screen. The extension supports reusable client secrets as well as signed JWT assertions, with signed assertions the recommended path.

A separate extension, Enterprise-Managed Authorization, reached stable status on June 18, 2026, adding centralized organizational control over MCP server access through an identity provider, replacing per-server consent prompts with a zero-touch flow where users sign in once and access approved servers without further setup. EMA adds centralized organizational control over which MCP servers an organization's users can reach, routed through an identity provider. So instead of a consent prompt for every individual server, users sign in once and get zero-touch access to whatever servers their organization has approved. Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already support EMA, with Slack and others listed as in progress.

What the spec requires and what deployments actually implement are two different things. Authorization remains optional at the implementation level. The specification defines the framework; it does not force anyone to turn it on. Practical DevSecOps's analysis found that only 8.5% of MCP implementations use OAuth at all. Enterprises that don't actively build OAuth 2.1 and EMA into their deployments stay exposed to the same structural gaps the July spec was written to close.

Identity handling for agents versus human users

Agents don't fit the identity categories that enterprise IAM systems were built around. They authenticate against APIs instead of logging into a session. They operate ephemerally, often existing for the length of a single task. They act on behalf of humans while sometimes holding permissions that exceed what that human actually has. And they do all of this at machine speed. Most early deployments take the shortcut of treating an agent like a standard service account, and that is the specific failure behind a large share of the incidents described above.

Industry standards bodies are starting to formalize the distinction. In the second quarter of 2026, AIUC-1 updated its standard, with input from the Cloud Security Alliance, and it separated agent identity from agent access into two distinct control domains. NIST's AI Agent Standards Initiative, launched February 17, 2026, takes a consistent position. The reasoning behind the split is straightforward: authenticating an agent (confirming it is what it claims to be) and governing what that agent may do are two different technical and governance problems, and conflating them lets over-broad permissions creep in.

That over-provisioning is itself a common pattern. In most early deployments, permissions end up broad because scoping what an agent needs takes more engineering time than just handing it wide access. That shortcut is precisely the condition that confused deputy attacks and parasitic tool chaining rely on. An agent with more access than its current task requires is an agent that can be redirected into doing far more damage than the task ever called for.

A credential architecture built for agents looks different from one built for people. Short-lived tokens replace the long-lived API keys that sit in plaintext configuration files. Just-in-Time provisioning issues credentials for a specific task and revokes them the moment that task completes, matching the way agents actually live and die. Permissions get scoped to what the current task requires. Verification has to continue checking whether the agent is still behaving within the parameters it was given.

Delegation chains raise the same question at a bigger scale. When an orchestrator hands a task to a sub-agent, that sub-agent needs an identity that's verifiable on its own terms and traceable back to the original user request that started the chain. Every hop in that delegation has to stay auditable, because a chain where identity gets lost partway through is a chain where accountability does too.

Tool call governance in a production MCP deployment

Knowing which agent is making a request answers only half of what a production deployment needs to know; the rest is what that agent is actually doing with each individual tool call, which requires governance at the level of the call itself, not just at the level of the session.

Every tool invocation needs to be evaluated against the specific task it's part of, not against a blanket permission granted when the agent was first configured. That's what task-scoped permissions and JIT provisioning are built to support: an agent should be able to reach a database today because it has a task that needs that database today, with credentials issued for that task and revoked on completion, not because someone set up broad access and never revisited it.

Tool description poisoning and dynamic capability drift both point to the same governance requirement: tool metadata itself has to be monitored and versioned, the same way code is. A change to a tool's description is a change to the agent's behavior, and it deserves the same re-approval scrutiny a code change would get, not a silent pass because the tool's name never changed.

The confused deputy pattern points to a second requirement: the MCP server itself has to check the requesting user's actual entitlements before acting, instead of simply executing with whatever privileges the server happens to hold. A server that can't distinguish between what it's capable of and what a specific user is allowed to ask for will keep producing the same failure.

And the speed at which these exploits run, credentials used against live APIs within seconds in the cases researchers have documented, means governance can't depend entirely on logs reviewed after the fact. Controls that act at the moment of the tool call, evaluating identity, scope, and task context before execution rather than flagging the problem in a dashboard afterward, are what close the gap between a protocol that defines the right framework and a deployment that actually holds to it.