# Unified MCP Platform vs Fragmented Agent Stack

> Enterprises need unified governance and identity controls that fragmented MCP stacks cannot provide.

URL: https://www.runlayer.com/llms/unified-mcp-platform-vs-fragmented-agent-stack
Last updated: 2026-10-05

Enterprises are stalling on MCP because production needs unified identity, auditability, and real-time governance, and most current stacks don't have those controls in place.

The speed of adoption makes the stall more striking, not less. MCP started as an open-source release in November 2024, and in under two years it has become cross-vendor infrastructure: donated to the Linux Foundation's Agentic AI Foundation in December 2025, backed by OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg, with SDK downloads reaching roughly 97 million per month by early 2026, numbers of a protocol that won. But winning the adoption race and surviving the move to production are two different tests, and a large share of pilots fail the second one.

MCP's gaps trace back to its design. MCP was built as a protocol, a common language for agents to call tools and reach data sources, not as a platform with built-in governance. That design choice made sense for driving adoption quickly. It also means nobody shipped a standard way to authenticate enterprise users through it, no native tooling to govern what agents can touch, and no account for the fact that stateful agent sessions collide badly with the load balancers that enterprise infrastructure already runs on. Those gaps open up precisely when a pilot scales into something a security team has to sign off on.

Gartner's MCP Cybersecurity Guide, published in 2026, treats this as an urgent problem. It projects that by 2028, roughly a quarter of enterprise generative AI applications will experience at least five minor security incidents a year, up from a small fraction in 2025. That jump describes what happens when governance doesn't scale with adoption. Platforms like Runlayer have emerged specifically to close that distance, pairing anAIcontrol plane with MCP gateway capabilities so that identity, policy, and audit infrastructure exist before an enterprise needs them, not after an incident forces the question.

## Why the fragmented stack cannot govern itself

A typical enterprise MCP deployment runs one server per source system: one for the CRM, one for the finance tool, one for the internal wiki, one for the ticketing system. Each server has its own credential, its own permission model, its own log format. It's the structural result of assembling governance out of separate tools that were never built to talk to each other, leaving no single point from which anyone can review what's actually happening across the stack.

The convenience that makes each server useful is the same thing that makes it dangerous. An MCP server aggregates credentials for multiple enterprise systems behind one interface, so an agent can reach the CRM, the billing system, and the document store through a single connection. A compromised server becomes catastrophic rather than contained for this reason: every system behind that interface is now reachable in one move, and the fragmented stack has no mechanism to detect the compromise before it propagates.

Ownership makes the problem worse. Responsibility for agent identity typically splits across security teams, IT departments, and whatever AI security function has recently stood up, and usually no one team is accountable for the whole picture. Surveys on enterprise practice back this up: only a minority of organizations report having a formal, enterprise-wide strategy for agent identity management, and a large share are still running on informal practices improvised as agents got deployed. The result is access sprawl, and security teams usually find out about it only after a policy has already been bypassed.

The Cloud Security Alliance has named the root of this clearly: AI agents now function as privileged identities, and they belong to a distinct identity class that sits outside both traditional user accounts and traditional service accounts. These agents act on behalf of humans, but the IAM controls built to govern humans and service accounts were never designed to fully govern them. The real question facing enterprises is whether those controls live in one place a security team can actually review, or get scattered across every agent and every connector to every source system. Ownership of agent identity is fragmented across teams with no clear accountability, and that fragmentation is what makes least privilege impossible to enforce consistently. A unified platform approach ties identity to every MCP action through SSO and just-in-time credentials, and enforces policy at tool-call depth, closing the governance gaps that a fragmented stack inherits simply by being fragmented.

## The specific threats that a fragmented stack cannot stop

Six attack classes define the current MCP threat landscape, and all six exploit the same structural condition: trust boundaries exist between systems, but no system in a fragmented stack enforces them consistently.

Tool poisoning is the highest-leverage version of this. The attack doesn't touch the tool's name or its user-facing summary. It alters the natural-language metadata the agent reads to decide how and when to call the tool, leaving everything a human reviewer would glance at looking untouched. Microsoft Incident Response documented a finance workflow case showing how this plays out: a developer pushed an update to a third-party invoice enrichment MCP server, and the tool description was silently modified to instruct the agent to retrieve unpaid invoices and attach a summary to the enrichment call, framed internally as a fraud-heuristic requirement. Because description changes didn't trigger any re-approval workflow, the new instructions went live without a single security review. The failure wasn't in the invoice system or in the agent. It sat in the trust boundary between them, and a fragmented stack has no mechanism to monitor that boundary, since nothing in it compares tool descriptions across versions or triggers automatic re-review.

Unauthenticated server exposure is a separate failure mode, and it has its own scale. Trend Micro identified 492 MCP servers sitting on the public internet with zero client authentication and zero traffic encryption. BlueRock Security looked at thousands of MCP servers and found that a substantial share of them were potentially vulnerable to server-side request forgery. A specific case, CVE-2026-32211, an authentication bypass in Azure MCP Server with a CVSS score of 9.1 from Microsoft's own CNA (NVD scores it 7.5), made API keys and tokens accessible without any credentials at all.

A deeper cause sits beneath both failure modes: supply chain compromise hits the dependencies underneath the servers themselves. In January 2026, aresearcher publicly disclosedan exploit chain against Anthropic's official Git MCP server, spanning path traversal, argument injection, and a repository scoping bypass, tracked as CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145. Anthropic had already patched the issue in December 2025 with mcp-server-gitv2025.12.18. In April 2026, OX Security disclosed a systemic vulnerability running across Anthropic's MCP implementations in Python, TypeScript, Java, and Rust, a flaw that rippled through a supply chain with more than150 milliondownloads behind it.

Confused-deputy attacks exploit a design pattern baked into how MCP servers execute actions. A server runs with its own elevated privileges regardless of the requesting user's. A user without database admin access can ask a question, and the server, which does hold admin access, will comply without checking whether the human on the other end should have that answer. Compounding this, credentials, API keys, and database passwords are routinely stored inplaintext configuration files, so every client connecting to that server inherits the same privileged access by default.

Agentjacking through protocol injection has already reached production at scale. A Sentry MCP event injection attack reached thousands of organizations through injectable DSNs, and testing showed a high rate of agent execution on the injected payload. Sentry declined to remediate the root cause and deployed only a filter targeting the specific payload string identified during research.

Cross-agent lateral movement shows most clearly why fragmentation is the common thread. Cisco documented an enterprise case where an attacker first compromised a low-privilege data query agent, then used that agent's cross-agent communication interface to send disguised requests to a higher-privilege financial approval agent. No single tool in the stack could see that path, because no single tool had visibility across both agents.

The NSA has formally characterized this whole category of risk:agentic AI systems introduce novel and systemic risks that established cyber defense strategies do not adequately address, including dynamic tool invocation, implicit trust relationships between agents, and the way context gets shared across a system with no central point of control.

## Why traditional IAM and perimeter controls fail for agents

The obvious instinct, when a new technology creates security gaps, is to apply the identity and access controls already on hand. With agents, that instinct runs into a wall. Traditional IAM was built around human roles, and human roles change slowly: someone gets promoted, someone changes teams, someone leaves the company, and access changes accordingly on a timeline of weeks or months. Agents accumulate permissions on a completely different timeline, so fast that existing IAM tooling was never built to track it, let alone enforce limits on it in real time.

Privilege drift is the clearest symptom. Development teams, trying to avoid breaking a workflow mid-build, routinely over-provision OAuth scopes. Service accounts get reused across deployments instead of issued fresh for each one. Permissions stack on top of each other across this process, and no one is tracking what the aggregate exposure actually looks like once all those individual decisions combine.

In the absence of a real alternative, some teams resort to sharing human credentials and access tokens directly with agents, because most current stacks don't offer a purpose-built way to secure identity for autonomous workflows. That's a stopgap, not a control, and it means an agent's actions become indistinguishable from a human's in the audit trail, which defeats the point of having an audit trail at all.

Perimeter-style controls fail for a related but distinct reason. Server-level access control only answers one question: can this caller reach this server at all? It says nothing about the question that actually matters for governance, which is what that caller can do once inside. A single MCP server routinely exposes safe read operations right alongside high-risk write or export actions, all through the same connection. A control that stops at the server boundary treats an agent pulling a read-only report the same as an agent exporting a customer database, because from the server's point of view, both are just an authenticated caller making a call.

## What unified governance requires at the platform level

Closing the gap between pilot and production comes down to four capabilities, and they have to work together as a single system. Assembled piecemeal from separate tools, they don't hold.

The first is identity binding per action, not per session. Agents need OAuth 2.1-based identity so they inherit scoped user permissions instead of running on standing, long-lived credentials. Tokens need to be issued just-in-time: short-lived, scoped to the task at hand, and revocable the moment they're no longer needed. SSO and SCIM integration have to extend into this system too, so that the instant a human employee's access gets revoked, every agent acting on that employee's behalf loses access at the same moment, not hours or days later. NIST's agent identity concept paper lays out the relevant focus areas directly: identification, authorization, auditing, non-repudiation, and binding agent actions back to human authority through access delegation. Each agent and each integration needs its own distinct identity, with token audience validated and every token scoped only to the resource it's meant to touch.

The second is a centralized MCP gateway with enforced tool allowlists. This means a real inventory, not a spreadsheet someone updates when they remember to: every MCP server, every tool inside it, its version, its owner, the class of data it touches, its permission set, and the approval rule that governs it. You have to treat tool description changes as security-relevant configuration changes that trigger re-approval automatically, instead of silent updates that slip through because nobody built a check for them.

The third is policy enforcement at tool-call depth. Server-level access control doesn't go far enough on its own. Policy has to be evaluated at the level of the individual tool call, distinguishing a safe read from a high-risk write or export, even when both actions live inside the same server and the same session.

The fourth is real-time threat detection tied to tamper-proof audit. Detection for MCP-specific threat classes, tool poisoning, prompt injection, intent drift, exfiltration, has to run at the moment the tool call happens, not days later during a post-hoc log review. That requires full OTEL tracing and audit logs that can't be altered after the fact, so every tool call carries the identity of both the human and the agent behind it, and the record stands as a reliable account of what happened. It also requires a fast disable path: the ability to shut off a single compromised server or tool without taking down every other workflow that depends on the rest of the stack.

## What a unified platform closes

Runlayer is built around exactly this specification. It comes from the team that built Zapier MCP and Agents, carries backing from Khosla Ventures and Felicis, and counts Gusto, Instacart, and Opendoor among the companies relying on it. Its design premise is that the secure way to use AI should also be the easy way: security and governance sit in the foundation of the platform rather than bolted on as an afterthought, which turns security teams into enablers rather than gatekeepers and gives the vast majority of employees who are not power users the same golden path that developers get.

Enterprises weighing how to close the governance gap generally face three paths. Another is to assemble a stack from separate best-of-breed components: an agent builder from one vendor, a gateway from another, a security monitoring tool from a third. Each piece can be excellent at its specific job, but integration between them becomes the enterprise's problem to solve and maintain, and the seams between tools are exactly where the threats described above, tool poisoning, confused-deputy attacks, cross-agent lateral movement, tend to live. A third path is a unified platform where identity, gateway, policy enforcement, and audit are designed as one system from the start.

If you want real-time detection for tool poisoning, prompt injection, intent drift, and exfiltration, you need both full visibility into every tool call and the ability to enforce policy at that same depth. A unified control plane with tamper-proof audit logs makes it possible to catch a malicious tool description update, or an unauthorized access pattern, before it spreads across connected systems. That's the capability a fragmented stack structurally cannot deliver, no matter how good any individual piece of it is on its own. The choice enterprises face is whether governance lives in one system built to carry it, or gets stitched together after the fact from parts that were never meant to fit.