Remote MCP Server Deployment and Access Control

Anthropic released MCP in November 2024 to give AI agents a standard way to call tools, pull data, and touch internal systems without every vendor building a custom plug for every model. It worked. OpenAI, Google DeepMind, Microsoft, and others all adopted it, and in December 2025 the protocol was handed to the Agentic AI Foundation under the Linux Foundation, which is the polite industry way of saying "this isn't going anywhere, plan accordingly." The Python and TypeScript SDKs now pull roughly 97 million downloads a month. By the first quarter of 2025, 28% of Fortune 500 companies had MCP servers running in production, up from 12% just one quarter before. That's a land rush.

Here's what makes this different from every API rollout your platform team has done before. A REST API call runs a code path a developer wrote, tested, and signed off on. An MCP tool call is a decision an autonomous agent makes at runtime, based on its own reasoning, with no human in the loop and no script to review beforehand. And because these servers sit on the network rather than on someone's laptop, the thing making that decision could be reaching you from anywhere. Your SaaS governance playbook, your REST API security checklist, your developer toolchain policies were built for a caller that is human and an action that was pre-written; this is neither. This piece is about closing that gap. Infrastructure decisions (how you host, how you route, how you authenticate) and access control decisions (who gets in, what they can touch, who's watching) are one project, not two. Treat them as separate and you'll ship something that works in the demo and fails the audit.

How the protocol itself handles remote connections (and what it leaves to you)

MCP originally shipped with SSE (Server-Sent Events) as its remote transport. It needed a persistent connection held open the whole time, which is fine until you're running thousands of agent sessions and your load balancer starts sweating. The March 2025 spec update deprecated it in favor of Streamable HTTP, which handles both streaming and one-shot responses over plain HTTP with no persistent connection required. If you're standing up something new, use Streamable HTTP. If you're inheriting someone else's deployment, check which one it's actually running, because a lot of servers still keep SSE around for backward compatibility and that detail matters when you're debugging a connection drop at 2 a.m.

That same March 2025 update also made OAuth 2.1 with PKCE mandatory for every remote MCP connection. Every server has to act as its own OAuth resource server or hand that job off to an external authorization server. This is the protocol solving authentication. It says nothing about authorization once someone's authenticated, which is the part enterprises actually care about. The update also introduced JSON-RPC batching, letting multiple tool calls ride in a single HTTP request. That sounds like a footnote now; it becomes relevant later when we talk about gateway latency, because batching is one of the cheapest ways to make governance overhead disappear.

What the spec doesn't touch: role-based access control, tool-level permissions, audit logging, rate limiting, session management at any real scale. All of that is homework left for whoever deploys the thing. The one piece of good news is the formal deprecation policy that shipped alongside these changes, which guarantees at least twelve months between a feature getting deprecated and actually removed. You can build against this spec without worrying the ground will shift under you next quarter. The spec gives you a secure wire; a governance program is a separate build.

The infrastructure choices that shape every remote deployment

There are three ways to host this, and they trade control for speed in different amounts. Self-hosting on your own cloud infrastructure (VMs, containers, Kubernetes) gives you maximum control and maximum operational burden in equal measure. It's the right call when data sovereignty rules or network isolation requirements take third-party hosting off the table entirely. Managed MCP hosting platforms cut the operational load and shift some compliance responsibility onto the vendor, which works fine as long as that vendor's security posture actually clears your bar. Then there are agentic integration platforms like Composio, which offer several hundred pre-built, managed MCP integrations for tools like Slack, GitHub, Jira, and Salesforce, all routed through a single gateway. That's the fast option. You're buying speed and paying for it in control.

Most enterprises running more than a couple of servers land on Kubernetes as the substrate, using namespace-level isolation and NetworkPolicies to separate trust boundaries in practice rather than in a slide deck. Microsoft's MCP Gateway is one example of what this looks like operationally: a reverse proxy and management layer that handles session affinity, deploy-update-delete lifecycle, telemetry, and access control inside a Kubernetes environment.

The single decision that matters most here is whether you run one gateway per environment or one gateway per trust boundary. Those are not the same thing, and confusing them is how a company ends up front-page news. Internal agents with broad, trusted access and customer-facing agents with restricted, untrusted access need to run through separate gateway instances with separate policies, full stop. A misconfigured policy on the customer-facing side should never be able to reach into internal tooling, and the only reliable way to guarantee that is physical and logical separation: distinct VPCs or Kubernetes namespaces, NetworkPolicies enforcing the boundary between them. There's exactly one scenario where a single gateway for all of production is fine: every agent hitting it shares the same trust level. In practice, that's rare enough to treat as the exception, not the plan.

What the MCP gateway category is and why it emerged

An MCP gateway is a reverse proxy sitting between AI clients (agents, IDEs, copilots, whatever's calling out) and one or more MCP servers. It centralizes authentication, routing, session management, rate limiting, observability, and policy enforcement in one place instead of scattering that logic across every server team's own implementation. The category exists because MCP solved the "how do agents call tools" problem and left "how do we govern that" completely untouched. That gap was visible within months of the November 2024 launch, and the market moved fast to fill it.

By mid-2025, Microsoft, Docker, AWS, Kong, Tyk, Gravitee, TrueFoundry, and a run of startups had all shipped a product in this space. Gartner gave it its own category rather than filing it under API gateways, and the analyst firm projects that 70% of software engineering teams building multimodal applications will use AI gateways by 2028, up from 25% in 2025. That's a category going from niche to default in three years, which in enterprise software terms is basically overnight.

It helps to see where this sits relative to things you already know. API gateways sit at the network edge and handle REST traffic. AI gateways sit in front of model providers and route LLM requests. MCP gateways sit in front of tool servers, parsing JSON-RPC, holding session state across multiple requests, streaming responses back. These three layers stack on top of each other; none of them replaces the others. Skip the MCP gateway layer and here's what you actually get: developers pasting long-lived tokens into local config files, no central record of which agent can reach which system, and no way to revoke access when somebody quits. The gateway is what owns the server registry, unified auth enforcement, tool-level RBAC, audit logging, rate limiting, and DLP at the transport layer, all in one place instead of reinvented badly five times across five teams.

How access control actually works at the gateway layer

The gateway enforces OAuth 2.1, but the smart move is tying agent and user identity back to whatever identity provider you already run: Okta, Entra ID, SAML or OIDC, rather than standing up a separate credential store built just for agents. Managing a second identity system is how you end up with orphaned service accounts nobody remembers creating.

Shared credentials fail here for a specific reason, not a vague one. HIPAA requires an audit trail attributable to an identifiable user or service for every touch of protected health information. SOC 2's CC6 controls require access controls with actual evidence of enforcement, not a policy document nobody checks. GDPR's accountability principle requires documented authorization for data access. A deployment where five agents share one API key satisfies none of these, and that's not a technicality, it's the whole compliance case falling apart at the first audit.

Server-level access, meaning "can this agent even reach this server," is necessary but nowhere near sufficient. The control that actually matters is tool-level RBAC: which specific tools inside a server can this agent or role invoke. An agent might be allowed to read a customer record through a CRM's MCP server but blocked from the tool that deletes one, on the same server, under the same connection. That distinction is what compliance frameworks are actually asking for when they say "access controls."

Enforcement has to live at the gateway, not scattered across individual server teams, because you cannot trust twenty different teams to implement the same policy the same way twice. Default-deny is the only posture that holds up: new tools are blocked until someone explicitly approves them, not allowed until someone remembers to block them. DLP belongs at this same layer, catching PII or secrets in a tool's response before it ever reaches the agent, not after the fact when it's already been read and possibly acted on. Session management works the same way: the gateway holds state across a multi-step agentic workflow, and every session ties back to one authenticated identity for its entire lifetime.

Then there's prompt injection, which deserves its own paragraph because it's not theoretical anymore. A malicious instruction buried in a tool's response can redirect an agent's behavior mid-task, and the gateway inspecting both inputs and outputs is the one place positioned to catch it. OWASP ranked prompt injection the number one LLM security risk for 2025, and subsequent agentic security guidance has made it a core threat rather than a footnote. This has EchoLeak (CVE-2025-32711) and a second one, CVE-2025-53773, that scored a 9.6 on CVSS. That's about as close to "on fire" as a severity score gets.

The performance cost of governance and how to keep it negligible

Every objection to gateway adoption eventually comes down to latency, so let's put a number on it. Authentication, policy evaluation, and input validation at the gateway add somewhere between 5 and 15 milliseconds per tool call. The actual tool execution underneath it runs 200 to 2,000 milliseconds. Do the math and governance is eating less than 5% of total call time in most cases, which is not the bottleneck anyone should lose sleep over.

JSON-RPC batching, the feature the March 2025 spec quietly added, shrinks that further. Bundle five independent tool calls into one HTTP request and you've eliminated four separate round-trips of gateway overhead in one move. For teams that want a concrete reference point rather than a vibe, Bifrost, an open-source Go implementation, publishes benchmarks showing 11 microseconds of overhead at high request volumes. That's what a well-built gateway costs you at scale.

Worth saying plainly: sometimes "performance concerns" is a euphemism for "I don't want a gateway telling me what my server can do." Measure your actual tool execution latency first. If you're in the hundreds of milliseconds, gateway overhead is a rounding error. If you're genuinely optimizing microseconds at your scale, you've got bigger fish to fry than whether a policy check costs you 11 of them.

How Cloudflare built governed MCP deployment at enterprise scale internally

Cloudflare runs a centralized team responsible for MCP server deployment across the company, and the governance is built into the platform itself rather than bolted on after a server ships. Teams copy a template inside the company's monorepo, write their own tool definitions, and deploy. What they inherit automatically, without asking for it, is default-deny write controls, audit logging, and secrets management. Standing up a new, fully governed MCP server takes minutes of scaffolding work. Governance didn't slow this down; it's the reason adoption moved as fast as it did, because nobody had to stop and build the security layer themselves.

Employees connect through an internal MCP server portal and immediately see every server, internal or third-party, they're actually authorized to use. No hunting through wikis, no pasting a token someone Slacked them. Administrators, from the same portal, see who logged into which server, and DLP rules block PII from reaching servers that shouldn't have it, enforced centrally rather than trusted to individual judgment. Cloudflare also runs shadow MCP detection through its AI Gateway product, surfacing unauthorized remote MCP servers before they turn into an incident report.

The lesson generalizes past Cloudflare specifically: governance that adds extra steps for developers gets routed around, quietly and immediately. Governance that is the easiest path gets followed, because nobody goes looking for a harder way to do their job. Build the platform so the compliant option is also the fast option, and you don't need to enforce anything; people will just take it.

The shadow MCP problem and why most enterprises are already exposed

Somewhere in your company right now, a team has connected an agent to GitHub, Slack, an internal database, or a third-party API through an MCP server that IT never reviewed, that has no credential policy attached, and that the security team has never heard of. This isn't a hypothetical. It's the default outcome of a protocol this easy to use, deployed inside an organization this large.

That's the uncomfortable part: the thing that makes MCP good is the same thing that makes it dangerous unmanaged. Ease of connection is the entire selling point, and ease of connection is exactly what turns a Tuesday afternoon side project into a production security hole with nobody's name on it. Ask most enterprises to list every MCP server currently running in their environment and watch the room go quiet. That's the same blind spot that preceded shadow IT a decade ago, just moved up one layer of the stack and moving faster this time.

Fintech is out ahead of everyone else on adoption, with 45% of companies in the sector already running MCP servers, which is also the sector facing the sharpest regulatory consequences if any of those servers turn out to be ungoverned. Finding the exposure requires network traffic analysis, agent log aggregation, and an actual MCP registry that shows what's officially registered next to what's actually calling out over the wire. The gap between those two lists is your shadow MCP surface, and it's usually bigger than anyone wants to admit before they've looked.

The window to get ahead of this is closing fast. As of early 2026, 80% of Fortune 500 companies have active AI agents running in production, and every one of those agents is a potential new ungoverned MCP connection waiting to happen.

What audit logging for MCP servers must actually capture

Every MCP tool invocation needs a log entry with five things in it: timestamp, the authenticated identity of the user or agent making the call, the tool name and which server it lives on, the full input parameters, and the execution result. Leave any one of these out and the log stops being useful the moment someone actually needs it.

The timestamp matters because incident investigations run on sequencing, and compliance needs to show access happened at a specific moment, not get reconstructed afterward from memory. Identity matters because HIPAA, SOC 2's CC6, and GDPR all demand that data access trace back to one specific principal; an anonymous or shared-credential log fails all three at once. The input parameters matter because knowing a tool was called tells you nothing; knowing what data it operated on is the actual forensic value. And the execution result matters because it's the only way to tell whether a policy-violating action actually went through or got stopped before it did any damage.

These logs also need to be immutable. A log an agent can rewrite is a suggestion, not an audit trail. SOC 2, HIPAA, and ISO 27001 all require this level of traceability as a baseline, not a nice-to-have, so this isn't a debate worth having twice.

There's a second use for this same data that has nothing to do with compliance: cost and usage telemetry. Which agents are calling which tools, how often, at what cost, builds the baseline you need before anomaly detection means anything at all. Most enterprises today have some tool invocation logging switched on somewhere. Very few have it complete, immutable, and tied to identity in a way that would survive an actual audit. That gap is the whole ballgame.