MCP Server Deployment Patterns for Platform Teams

Anthropic shipped MCP in November 2024 as a wire protocol for connecting agents to tools. By early 2026, most enterprise AI teams had at least one MCP-backed agent running in production, and the governance conversation still hadn't caught up. Most of these things got built to make a demo work, nothing more, and the demo just didn't stop. It got promoted to production status by accident, the way a lot of infrastructure does when nobody's watching the door.

The Linux Foundation took custody of the spec in 2025, which puts MCP in the same bucket as HTTP or OAuth as far as governance goes. That's good news for procurement; legal teams get to point at a standards body now instead of chasing a vendor's roadmap. For platform teams it means something less comfortable: the actual work of running this safely sits with them, and nobody else is going to do it for them. A meaningful chunk of the Fortune 500 already runs MCP servers, and wiring an agent to a tool is a governance decision whether anyone treats it that way or not. The consequences, security, audit, cost, get locked in long before the first agent ships.

What the MCP spec actually requires platform teams to understand before picking a pattern

Start with the wire format. It explains half the operational headaches everyone runs into downstream. MCP runs on JSON-RPC 2.0 over UTF-8, and connections are stateful, with explicit capability negotiation between client and server. Stateful sessions and load balancers have never gotten along; anyone who's tried running a stateful protocol behind a standard load balancer knows exactly the kind of friction that produces. That friction quietly shapes nearly every decision a team makes about remote deployment, whether they notice it or not.

The current spec mandates OAuth 2.1 with PKCE using the S256 method, plus Protected Resource Metadata and Resource Indicators (RFC 9728 and RFC 8707, respectively). Token passthrough, where a client just hands its own token straight to a downstream server, is explicitly forbidden now. Worth mentioning, because a lot of early integrations did exactly that: treated the MCP server as a dumb pipe instead of a resource with its own identity boundary.

The transport layer changed too. The original spec used HTTP with Server-Sent Events; a later revision swapped that for Streamable HTTP, a single connection that supports bidirectional streaming. Teams still running clients built against the older spec are, without quite realizing it, working against a transport model the rest of the ecosystem left behind a while ago.

One mistake shows up over and over in enterprise designs: treating Sampling, Roots, and Elicitation as server-side capabilities, when they're actually client features. Get that backward and the access-control model built on top is wrong from day one, because permissions land on the wrong side of the connection.

And there's a gap nobody's closed. MCP has no standard discovery mechanism. A registry or crawler can't tell what a server exposes without opening a live connection to it first, so every team building a catalog of internal MCP servers ends up solving this by hand, because the spec doesn't hand them an answer. The roadmap gestures at some of this, stateless Streamable HTTP for better load-balancer compatibility, native audit trails, defined gateway behavior under OAuth 2.1, configuration portability. Real gaps, all of them, and current deployments have to patch over each one manually in the meantime.

The four canonical deployment patterns and what each one trades away

Single-tenant. One server, one internal team, network boundary as the security perimeter. Simple to reason about, simple to run, fine for one team's internal tooling. It falls apart the moment a second team wants in. There's no central audit, so every server becomes its own island, and tracing what happened means instrumenting each one separately.

Multi-tenant, row-isolated. The SaaS pattern: one server, many tenants, isolation enforced at the row level in the data layer. It cuts down on operational sprawl, sure, but it moves the isolation burden into application code, so a single bug becomes a security incident fast. Getting RBAC right at the tool level is the whole job here. Misconfigure a tenant boundary and data leaks across customers.

Federated gateway. Large organizations running many MCP servers route everything through a central gateway that enforces policy and collects audit logs. Right call when an organization needs an enterprise-wide audit trail but can't, or won't, consolidate every server into one deployment. The tradeoff is operational: now there are two things to run instead of one, the gateway and the fleet behind it.

Edge-cached, read-only. Good for high-volume tool discovery where the catalog barely changes. Caching tools/list responses at the edge takes load off the upstream servers, but it trades freshness for speed. A stale cache can hand an agent a tool signature that no longer matches reality: fine when the catalog holds still, a liability the moment it doesn't.

Most organizations mix all four: single-tenant for sensitive internal tools, a federated gateway for shared services, edge caching for high-traffic discovery. The pattern should follow the governance requirement of the workload, not whatever's easiest to ship on a Friday afternoon. None of the four wins outright, and anyone telling you otherwise is selling something.

How direct connections create the N×M governance problem at scale

Do the math on a modest deployment. Ten agents, five tools each, all connecting directly, comes out to fifty independent integration points, each needing its own authentication, its own monitoring, its own upkeep. In practice, most of those fifty don't get a policy decision, a credential store, or an audit log. They get a config file and a prayer.

MCP has no native RBAC. If an agent can connect to a server, it sees every tool that server exposes, full stop. A finance agent querying an expense database might also see database administration endpoints sitting right there on the same server. A support agent might discover, purely by accident, that it has access to a command that drops a production table. Nobody designed that access. It came bundled with the connection, like a software license nobody read.

At real enterprise scale this grows quadratically, not linearly. Add agents, add tools, and the security surface expands faster than either number alone would suggest. The discovery gap makes it worse: without a governed registry telling agents what they should see, teams get stuck choosing between two bad options, letting agents overreach into tools they don't need, or maintaining discovery inventories by hand, which is its own quiet tax on everyone's time.

API gateways solved this same problem for REST about fifteen years ago. Direct point-to-point connections work fine on a five-person team. They stop working the moment an organization crosses from "small enough that everyone knows everyone's integrations" into "large enough that nobody does."

What the MCP gateway pattern adds and why the category emerged from production pain, not spec design

The MCP spec never defines a gateway role. Nobody wrote one into the protocol. The category showed up because teams ran headfirst into the N×M problem in production and needed something, anything, to sit in the middle and referee. AWS made this concrete when Bedrock AgentCore Gateway went GA in October 2025. Gartner has since described MCP gateways as the missing enterprise layer for registration, discovery, authentication, authorization, and observability across an estate that might run thousands of MCP servers.

A real gateway does four things. It enforces per-tool authorization policy, versioned and reviewable, before a tool call ever reaches the server. It brokers credentials centrally, holding the actual secrets, a Snowflake personal access token, a Jira credential, a SharePoint key, so the model itself never sees the plain-text secret. It gives per-tool observability, tracing latency, error rate, and call volume back to a specific conversation, with OpenTelemetry's GenAI semantic conventions emerging as the shared baseline for that instrumentation. And it presents virtual servers, role-specific bundles of tools, so a sales team sees CRM and analytics tools while engineering sees Git and deployment systems, instead of everyone staring at the same bloated catalog.

Here's a quick way to tell the real ones from the pretenders: ask the vendor to explain, in writing, exactly how per-tool policy enforcement works. A vague answer, or none at all, is itself the answer. Plenty of products marketed themselves as gateways in late 2025 while actually being LLM proxies with MCP-shaped logging bolted to the side.

The security risks that apply regardless of which pattern a team picks

GitGuardian found tens of thousands of unique secrets exposed in MCP configuration files across 2025, Google API keys and PostgreSQL connection strings leading the pack. That number has nothing to do with which deployment pattern a team chose. It's what happens when credentials get managed per-server instead of centrally, and it happens in single-tenant setups just as readily as federated ones.

Prompt injection is the other half of the risk surface, and it stopped being theoretical a while back. Researchers at Unit 42 documented large-scale indirect prompt injection attacks in the wild in early 2026, including ad review evasion and system prompt leakage on live commercial platforms. CVE-2025-53773 is the sharpest example on record: a hidden prompt injection buried inside a pull request description enabled remote code execution through GitHub Copilot, with a CVSS score of 9.6, about as bad as these ratings get. OWASP lists prompt injection among the highest-risk categories for AI systems generally, and the place to actually catch it is the gateway: validating input against JSON-RPC schemas, allowlisting actions, redacting PII, scoring tool reputation as calls come in.

Then there's blast radius. Obsidian Security has found agents moving over fifteen times more data than a human doing comparable work. A compromised agent doesn't cost you one session; it costs you everything that agent's authority touches, across every system it's connected to. Security teams built their playbooks around a human-scale threat model, and this exceeds it by an order of magnitude.

Shadow AI compounds all of it. A large majority of organizations now call shadow AI a definite or probable challenge, a sharp jump from a year prior. IBM's Cost of a Data Breach Report puts the added cost of a shadow-AI-linked breach in the hundreds of thousands of dollars, and a meaningful share of breached organizations traced the incident back to shadow AI, roughly double the prior year's rate. Deployment pattern alone doesn't touch this. Real enforcement between agents and servers, actually kept in place rather than configured once and forgotten, is what closes the gap.

What access control and identity need to look like across a multi-pattern deployment

OAuth 2.1 with PKCE is the floor MCP's spec sets, not the ceiling. The protocol handles how a connection authenticates. It says nothing about how identity maps to which tools a given user or agent can actually call, and that mapping is the platform team's job to design, from scratch, every time, with no spec to lean on.

The only approach that scales is RBAC tied to an identity provider you already run, Okta, Entra ID, SAML or OIDC, rather than some bespoke auth system bolted onto each MCP server individually. Per Nexla's baseline for an enterprise-grade MCP server, tool-level RBAC isn't a nice-to-have; it's table stakes. A support agent should never sit one tool call away from a command that drops a production table. If that's possible today in your environment, the deployment isn't finished, whatever the launch date says.

Virtual servers are how gateway-pattern deployments operationalize this: role-specific tool bundles instead of rebuilding permission logic from scratch for every server. Discovery should follow the same logic, scoped and namespaced to role rather than dumping the entire catalog into a prompt. Hundreds of tools sitting in context eat into an agent's budget and hand it access it never needed for the task in front of it.

Agent identity deserves its own treatment, kept separate from human identity. Agents need their own principals, their own token lifetimes, their own revocation paths. Treat an agent's calls like a human's SSO session, and the audit trail develops gaps exactly where scope quietly creeps. Quotas and rate limits belong in this same bucket, not as an operations nicety but as an actual governance control. Agents loop; a runaway agent without a throttle isn't a performance problem, it's an unbounded data-access event waiting to happen.

Observability and audit logging as non-negotiable production requirements, not post-launch additions

Every tool call should trace back to a data product, a user, and a specific prompt run. That's Nexla's baseline for lineage in enterprise MCP, and it also happens to be the bare minimum a security team needs to reconstruct what happened after something breaks.

Skip the audit log and the timeline problem shows up later, once it's expensive to fix. Research from AI Agent Security Practices 2026 shows shadow AI incidents take longer to detect on average than standard incidents—247 days versus 241 days, a six-day gap. Small gap in raw numbers, real gap in practice, and audit telemetry is exactly what closes it.

Cost belongs in the same conversation as security here. Per-tool call volume, latency, and error rate are a security signal (an anomalous spike in calls to a sensitive tool is worth someone's attention) and a cost lever in the same breath, since tool-call spend at enterprise scale adds up faster than most budgets account for, with SDK downloads across the MCP ecosystem now in the tens of millions per month. OpenTelemetry's GenAI semantic conventions are becoming the shared standard for this instrumentation. Teams adopting it now skip a rebuild later, once the spec formalizes around it anyway.

None of this retrofits cleanly onto an estate built on direct connections, and that's the part worth sitting with. Real audit trails need a governed layer from day one, which turns out to be the same argument that decides pattern selection in the first place.

How to evaluate which deployment pattern fits a given workload's governance requirements

Four questions do most of the work. Who calls this server, and how wide is the tool scope they actually need? Single-tenant and edge-cached fit a narrow, bounded audience; multi-tenant and federated fit anything broader. What does the audit requirement actually demand? If the organization needs one cross-agent trail, a federated gateway is the only pattern that delivers it without stitching together per-server logging by hand afterward. Where do the secrets live, really? A config file on someone's laptop is not a production answer, no matter which pattern surrounds it. And what happens the moment an agent misbehaves? Rate limits, a revocation path, scoped tool access, all of it needs an answer before the server ships, not after an incident forces the question at 2 a.m.

Nexla's minimum viable checklist for an enterprise MCP server covers tool-level RBAC, dynamic scoped discovery, lineage and observability, and quotas with rate limits. Treat it as a go, no-go gate, applied per deployment, not as a box checked once at the org level and forgotten.

A gateway isn't mandatory for every server. But any deployment that can't answer those four questions on its own should treat a gateway as the starting requirement, not some optional upgrade bolted on later once things get uncomfortable.

Govern at the layer where all agent-to-tool traffic actually passes through, wherever that layer happens to sit, no matter how many patterns an organization runs at once. Enforcement scattered across dozens of individual servers won't survive contact with scale.