How MCP Servers, Clients, and Hosts Fit Together in an Enterprise Portal

Before MCP, connecting AI models to external tools was an exercise in bespoke misery. Ten models talking to ten data sources required something approaching a hundred custom connectors, like trying to plug a hundred different appliances into outlets that each speak a different voltage. Each new model meant rebuilding integrations from scratch. MCP's core bargain collapses that N×M burden into N+M: every AI application implements the client protocol once, every tool implements the server protocol once, and they interoperate.

The three roles are distinct, and conflating them is the fastest way to build something ungovernable.

The host is the environment where the AI model or agent actually operates: an IDE, an enterprise AI application, an agent orchestration platform. It manages session context and coordinates communication between components. It does not decide which tool to call; it provides the environment in which those decisions occur.

The client is the application layer doing the actual reasoning: a chatbot, an AI assistant, an autonomous agent. The client interprets requests, decides which capability is needed, and selects which server to call. One host can run multiple client instances simultaneously, which is what allows complex agent topologies without each instance needing its own isolated environment.

The server exposes tools, data sources, APIs, and databases through standardized schemas and discoverable metadata. Instead of requiring an AI to understand each application's unique interface, the server presents capabilities in a consistent, machine-readable form. During initialization, clients and servers explicitly negotiate which capabilities each party supports, and both sides must respect those declared limits throughout the session.

What the spec deliberately does not solve: how permissions are enforced, how audit trails are maintained, or how risk-tiered execution is governed. That omission is not an oversight. It is a design choice that leaves enterprise architecture teams holding the bill.

How the Three Roles Communicate, and Why Transport Is Not a Minor Detail

The transport layer is where most enterprise architects get tripped up, because MCP's transport story has evolved quickly and the documentation ecosystem has not always kept pace.

The original transport used HTTP plus Server-Sent Events across two separate endpoints. It was deprecated in the March 2025 specification. The current transport, Streamable HTTP, consolidates everything to a single /mcp endpoint: clients POST JSON-RPC messages, servers respond with JSON or upgrade to an SSE stream over the same connection. Materially simpler, and critically, load-balancer-friendly in a way the original design was not.

The 2026 release candidate removes protocol-level sessions and the Mcp-Session-Id header entirely, meaning MCP servers can now operate behind plain round-robin load balancers without shared session state. For operations teams, this is the change that matters most: MCP servers become ordinary HTTP services, scalable with standard Kubernetes and cloud-native tooling already in use.

The local-versus-remote distinction is equally consequential. Most official MCP servers were historically built on stdio transport, running as local processes on the same machine as the AI client. That is a single-user authentication model by design. Remote deployments, by contrast, enforce strict tenant boundaries and can isolate data across organizations on shared infrastructure. The ecosystem is moving where enterprise needs it to go, and the migration is not slow.

One more primitive worth understanding: MCP Tasks, now an official extension rather than an experimental one. Tasks are durable, addressed by stable handles, and clients can persist task IDs so that polling resumes after a crash or restart. This is the mechanism that makes long-running agentic workflows viable at scale, specified behavior rather than a workaround.

Why Local Deployments Break Down Before Governance Is Even on the Table

Local deployments work fine for one developer. They do not work for thousands of users across a regulated organization, and the problems compound faster than most teams expect.

The stdio-based server model requires the MCP server to run on the same machine as the AI client. That constraint is simply insuperable at enterprise scale; there is no architectural path that makes it work across a distributed workforce. The more insidious issue, though, is the auth model baked into local deployments: whoever runs the process has whatever access the server was configured with. There is no identity boundary, no meaningful separation between the user, the agent, and the permissions. It is trust-by-proximity, which is not trust at all.

The natural consequence is what some teams are calling shadow MCP, the 2026 equivalent of shadow AI, where employees connect unauthorized MCP servers to their AI tools without security team visibility. Network-layer detection rules for this traffic now exist in commercial gateway products. Whether most organizations have actually deployed them is a separate, less encouraging question.

The spec itself acknowledges these gaps as out of scope. No architectural guidance for permission enforcement at the protocol layer. No audit trail requirements. No mechanism for risk-tiered execution. No SSO-integrated authentication pattern. These are not criticisms of MCP's design philosophy; they are accurate descriptions of what enterprise architecture must supply independently, and what most teams are not supplying yet.

The identity dimension is the acute pressure point. Non-human identities, service accounts, API keys, and agent tokens are proliferating in large enterprises at a ratio that dwarfs human identities. Zero trust frameworks originally designed around human-user verification are structurally unequipped to govern agent-to-tool traffic without deliberate architectural extension. The tools exist; they were built for a different principal type, and the industry has not fully reckoned with that mismatch.

Roughly 28% of Fortune 500 companies have already implemented MCP servers. This means roughly 72% of Fortune 500 companies reaching for MCP today are building on local or ad-hoc remote deployments without a governance layer, not because they lack the intention, but because the spec does not prescribe one and urgency reliably wins over architecture.

What an Enterprise MCP Portal Actually Is

An MCP server portal centralizes multiple MCP servers onto a single HTTP endpoint. Instead of agents reaching out to a sprawl of individual server addresses, every tool call passes through one governed gateway. The structural simplicity is deceptive; the operational consequences are significant.

Tool discovery becomes a governed function rather than an ad-hoc one. Users and agents see only the resources explicitly authorized for their role. Identity enforcement applies to every request before it reaches a server. Observability concentrates: prompt traffic and tool calls are logged in one location, giving auditors a single source of truth rather than a pile of incompatible server logs from six different vendors.

This is where the three MCP roles converge into something coherent. The host operates inside the enterprise environment. The client's tool calls are intercepted and verified at the portal. Only approved servers are reachable. The portal is not an add-on to the architecture; it is the architecture.

Cloudflare's MCP Server Portals, built on its global edge and security network and available in open beta since August 2025 to Cloudflare One customers through the Zero Trust Dashboard, provide a concrete reference for what this looks like in production. Administrators register MCP servers, approve them, and assign permissions. Unapproved servers are invisible to agents. The governance surface becomes, finally, legible.

How Identity and Access Controls Attach to MCP Traffic

The portal applies the same controls used for human users, multi-factor authentication, device posture checks, geofencing, to MCP traffic. Agents are not a separate security domain; they operate inside the same identity perimeter as employees. Most organizations are not using this framing yet, which is precisely why their MCP deployments are exposed.

Integration with SASE means MCP governance can inherit the same network-level controls already applied to employee access, rather than requiring a parallel security stack built from scratch. Role-based tool visibility at the portal layer means a user or agent sees only the tools and data sources authorized for their specific context. Least-privilege applied to tool calls, not just to data access.

The financial case is not abstract. Per IBM's 2025 Cost of a Data Breach Report, organizations with ungoverned shadow AI in their environments paid roughly $670,000 more per breach on average, and zero trust organizations saved $1.76 million per breach compared to non-adopters.

The non-human identity problem is where this gets genuinely difficult. Agent tokens, service accounts, and API keys need continuous verification and least-privilege treatment exactly as human identities do, but the tooling for managing them at scale was not designed with agents in mind. A portal architecture that enforces identity at the gateway level, rather than trusting whatever credentials the agent was initialized with, is one structural approach that scales, because agent populations will grow faster than any team can manually audit them.

One important caveat: per IBM's 2025 Cost of a Data Breach Report, a large majority of organizations view zero trust as essential to their security strategy, yet only a small fraction have fully implemented it. So for most enterprises, MCP governance is being bolted onto a zero trust program that is itself still maturing. The portal architecture that aligns with an existing, partially-implemented SASE investment is therefore more likely to actually get deployed than one requiring a greenfield security stack. That is not a philosophical point; it is a procurement reality, and procurement realities determine which architectures actually survive contact with budget cycles.

WAF, Prompt Injection, and the Threat Surface Nobody Budgeted For

Every remote MCP server is an HTTP endpoint. This is obvious in retrospect, but in practice, teams building MCP integrations think of them as AI plumbing rather than web infrastructure, which means they inherit the entire web application attack surface without necessarily having budgeted for it. A WAF is not optional; it is table stakes.

What a standard WAF does not address is where things get interesting. Prompt injection is the MCP-specific threat worth losing sleep over: malicious content embedded in tool responses that redirects agent behavior downstream. The agent processes the tool's output and acts on adversarial instructions embedded within it, with no inherent mechanism to distinguish legitimate tool data from injected directives. The agent does not know it has been compromised. That is the problem, stated plainly.

Sensitive data leakage through tool call responses is a second vector. Topic misuse, where agents invoke tools for purposes outside their sanctioned scope, is a third. Neither maps cleanly onto traditional WAF rule sets.

Security inspection for MCP traffic cannot rely on the agent to detect its own manipulation. The inspection has to happen at the network layer, upstream of the model. An agent that has already processed a successful prompt injection is compromised by definition; the defense has to be earlier in the chain. This is a structural requirement of the threat model, not a limitation of current AI capabilities.

AI Security features within the WAF can inspect inbound MCP traffic for these patterns: prompt injection attempts, sensitive data exposure, and topic classification, all applied at the gateway before responses reach the agent. This is where the portal architecture earns its keep beyond access control. It treats tool-call traffic as a threat surface rather than merely a communication channel, a framing that does not occur naturally to teams who came up through API integration rather than security.

Observability and Audit Trails Across the Boundary

The audit gap in ad-hoc MCP deployments is straightforward to describe and painful to discover post-incident. When agents call servers directly, there is no natural aggregation point for logs. Each server logs independently, in incompatible formats, with inconsistent retention policies, or simply not at all. Post-incident investigation becomes an exercise in reconstructing what happened from partial evidence across systems that were never designed to talk to each other.

The portal as a single observability chokepoint resolves this structurally. All prompt traffic and tool calls pass through one endpoint, producing a unified log of who accessed which server, when, with what inputs, and what was returned. Per-user and per-agent tool call history becomes available without custom instrumentation. Rate limiting signals emerge naturally from aggregated traffic, enabling detection of anomalous agent behavior before it becomes a breach. Token-level usage attribution enables cost allocation, which finance will eventually require regardless of how the security conversation resolves.

At that volume, unified observability is not a nice-to-have; it is the only mechanism by which a security team can know what is happening.

MCP Tasks' durable task handles add another observable artifact. Long-running agent operations have stable identifiers that can be tracked, resumed, and audited across sessions, which matters considerably when an agent workflow spans hours or days and an incident occurs partway through. The ability to reconstruct what a multi-hour agent did, step by step, is a compliance requirement in most regulated industries, not a luxury.

Without logs, security teams cannot determine which tools are being called, by whom, or whether the permissions model is calibrated correctly. Most organizations building MCP integrations today are operating without that visibility, which means they are governing by assumption.

Putting the Architecture Together: The Reference Pattern

The governed enterprise MCP portal resolves to three functional layers, each with a distinct responsibility.

An access control layer at the perimeter authenticates every request, human or agent, before it reaches the portal. MFA, device posture checks, and geofencing apply to MCP traffic with the same consistency they apply to employee access. The perimeter does not distinguish between principal types; it enforces policy uniformly, which is the point.

The MCP Server Portal as the control plane centralizes server registration and approval, enforces role-based tool visibility, and routes all traffic through a single governed endpoint. Hosts operate inside the Zero Trust perimeter. Clients reach only the servers the portal exposes. Servers are registered and wrapped so they are never directly addressable by agents outside the sanctioned path. The three MCP roles converge into an administered system rather than an ad-hoc one.

AI Gateway for observability and rate limiting logs every tool call, enforces usage limits, and provides the audit surface compliance and security teams require. The WAF with AI Security for Apps sits across all inbound MCP traffic, providing prompt injection and data leakage inspection at the network layer before responses reach the model.

The stateless MCP architecture enables the server layer to scale horizontally behind standard load balancers, so the governance infrastructure does not create a performance bottleneck as agent volume grows. It scales with the same tooling the rest of the infrastructure already uses, which is the argument that closes the conversation with operations teams.

Organizations building MCP portals today are doing so inside a broader infrastructure transition toward zero trust and SASE consolidation. The portal architecture that aligns with an existing SASE investment is the one that actually gets deployed, not because it is philosophically superior, but because it does not require a parallel security program to operate. The alternative is a separate auth vendor, a separate gateway, a separate WAF, stitched together to govern infrastructure that was itself designed to eliminate integration complexity. That irony lands differently once someone has lived through the procurement process.