How to Manage Authentication and Authorization for MCP in Multi-Agent Systems

Agentic systems are becoming increasingly complex, often delegating tasks to various sub-agents and sometimes spanning multiple AI platforms and large language models (LLMs). At the same time, Model Context Protocol (MCP) is empowering multi-agent systems with access to external tools and functions, making them far more actionable.

Yet, when configuring authentication and directing authorization across disparate AI environments, the potential for privilege drift, overpermissioned access, and shadow MCP servers is high. With MCP, engineers often bring their own tools and configure access ad hoc. In these scenarios, the risk for leaked data and credentials or LLMs taking unintended actions, starts to increase.

So, how do you govern, monitor, and manage access to MCP when you have multiple agents and LLMs that each require uniquely scoped MCP server access? Below, we’ll look at the problem, and consider what’s needed when enterprises want to authenticate multiple agents at scale across their MCP-enabled environments.

Multi-agent systems are on the rise

Enterprises are now beginning to operate more complex agentic AI systems. For instance, the 2026 Agentic Enterprise Report surveyed 621 enterprise digital leaders and found that 58% already have agentic AI programs in use or in production, and 40% of them have agentic AI programs spanning multiple departments.

Much of this development involves multi-agent systems. Capgemini reports that out of organizations already scaling AI agents, nearly half are piloting or scaling multi-agent systems. While many groups are admittedly in early stages with AI agents, the technology is anticipated to expand quickly: Gartner predicts that the average Fortune 500 will have over 150,000 agents in use by 2028, highlighting how quickly agent sprawl may emerge.

Multi-agent systems can be defined as an agentic system with various sub-agents built around discrete tasks, such as customer look up, order fulfillment, help desk, or other activities. Having specific roles tends to produce better results. These systems are typically guided by an orchestrator or lead agent and might involve variously-tuned underlying LLMs.

The multi-agent approach is going beyond software development and entering business workflows too. For instance, Workato has, for its sales team alone, built 28 purpose-specific AI agents to empower their internal sales processes. These agents validate prospects, generate quotes, schedule follow-up meetings, and perform other tasks.

Such multi-agent systems often rely on MCP as a standard mechanism to interact with external SaaS platforms, or connect with internal APIs and databases. As a result, MCP use has expanded alongside the interest in agents. As evidence, a researcher at Bloomberry charted a 232% increase in public MCP servers just within a six-month time frame.

The agent-to-MCP access dilemma

MCP-powered agentic systems are empowering users with unprecedented capabilities to build, design, and initiate chained workflows. However, the underlying problem is security. A handful of authentication and authorization hurdles exist when we consider syncing various agentic platforms with a rising pool of in-use MCP servers.

Problem #1: Not all MCP servers handle authentication in the same way… or at all

First, the biggest hurdle is that a large group of MCP servers aren’t even meeting the minimal security requirements. Nearly 40% of MCP servers have no authentication at all, according to the aforementioned Bloomberry analysis. For those that do, some still rely on API keys instead of using OAuth 2.1 and having the MCP server act as the resource server.

Beyond authentication, authorization is optional for MCP servers according to the official MCP specification. And, the exact authorization mechanics differ depending on whether the MCP server uses HTTP-based transport, STDIO transport, or an alternative transport protocol. These nuances often lead to users configuring each MCP server independently, and sharing credentials like API keys with each AI tool, which can be risky if exposed.

Problem #2: Agentic platforms do authentication differently

On the flip side, the AI coding and agent platforms, whether it’s Codex, GitHub Copilot, or Claude, or others, have their own tool authentication flavors. So, if you’re operating across multiple platforms, how is MCP access configuration stored and managed consistently across agents?

Without a separate, standardized method, you could accidentally expose raw keys, or waste time reconnecting to MCP tools over and over. And, although Anthropic has made recent strides toward a new universal access model, the strategy leaves gaps around how granular privileges are handled and access decisions determined at runtime.

Problem #3: Privileges can easily drift in agentic systems

On top of that, multi-agent systems are now juggling a vast array of permissions, which can easily balloon over time. Writing for the Nordic APIs blog, Janet Wagner recently demonstrated an example FinOps application scenario in which a 5-agent system starts each with 2-3 scopes, but they quickly escalate to about 10 read and write scopes each due to simple feature requests over a matter of months.

Of course, this kind of privilege drift isn’t anything new. Sonrai estimates that 90% of permissions for cloud identities at large already go unused, breaking a least privilege model. But, the real danger emerges when AI agents have unintended access to potentially destructive read and write capabilities in the form of MCP tools. A number of agentic AI failures, like the Replit and PocketOS database deletions, show what can go wrong when an autonomous agent has ungated access to write functions or if their permissions drift from their original purpose.

Problem #4: Much of MCP usage is still ungoverned

Within your average software engineering organization, many MCP servers are left ungoverned, with a lack of context on where they came from, who owns them, and what their security profiles are. Many are unofficial servers with unknown provenance, or are created quickly for internal purposes without security approvals, complicating the IT governance side of the authentication story. Some experts even fear MCP is at risk of becoming the new form of shadow AI.

Solutions to authenticate and authorize MCP in multi-agent systems

As one can see, controlling access to MCP in multi-agent environments comes with some challenges. Thankfully, some tactics are emerging to help architects, platform engineers, and security engineers respond, including abstracting direct tool access and designing MCP access for any type of AI client.

Abstract direct MCP access

It’s becoming a common practice to introduce some form of abstraction layer between agents and direct MCP tool calls. This can aid tool discovery, guide token optimizations, and benefit security. An MCP gateway, for instance, can act as a means to provide runtime governance over agent-to-MCP interactions and provide a universal authentication layer.

Enable “bring your own LLM”

AI platforms will evolve to the latest and greatest, and the underlying models will keep changing. Authentication, however, must remain stable. Securing MCP access at scale, then, will require a separation of concerns approach to separate MCP access policies and permissions from the underlying platform, agent, or LLM.

By pointing agents at an MCP gateway, for instance, you can unify authentication for upstream servers, no matter which AI platform you’re working with. Outsourcing authentication to such an intermediate layer also solves the issue of differing authentication methods per upstream MCP server. This does not mean traditional identity federation is zapped — most gateways incorporate an enterprise’s existing identity provider of choice.

Make curated, reusable permission sets

With an abstraction layer around MCP, an organization can use as many agents as they like and simply point them to a curated set of permissions that reflect the MCP scopes they require. This helps reduce the drift issue, since your permissions don’t travel from agent to agent to agent: they reside in a single control plane. For example, using Zuplo MCP Gateway, teams can quickly create virtualized MCP servers to share with any agent, containing curated scopes for only the tools they need.

Unify security and governance

Overall, it’s a good practice to centralize observability into MCP environments. By having an AI-native way to monitor and track agentic tool calls, you can have the logs in place to aid debugging and auditing. Such analytics can help spot unauthorized usage and greatly reduce the chance of further shadow MCP servers emerging.

Governing MCP access in multi-agent systems

AI-reasoning is powerful due to its probabilistic and non-deterministic nature. However, security controls shouldn’t be non-deterministic. Authentication requires a standard, repeatable approach that can be applied across any platform, no matter what the underlying agent or model is.

MCP is a powerful standard and exciting for the developers teams trying to get more out of their agents. However, it does come with some authentication hurdles, especially when you have multiple clients all needing varying levels of access to different flavors of MCP servers. It’s a situation where credentials, permissions, and identities can quickly become muddled.

In short, MCP authentication becomes less about connecting one client to one server, and more about consistently governing access across hundreds or thousands of agent-to-tool interactions.

There are many emerging practices to address MCP security gaps, from server scanning, to runtime diagnostics, and beyond. As part of this effort, an MCP gateway can act as a prime abstraction layer between agents and underlying tools, acting as a control plane to govern access. With this approach, teams can use as many agents as they like, assign flexible permissions for each (or across as many as they like), and unify on a standard method for handling authentication.