What is an enterprise MCP gateway?

By Nolan Sullivan, Founding Growth Engineer

·Published September 29, 2026

For an enterprise, both the promise and the threats of AI are magnified. Thousands of people with agents that can read the CRM, file tickets, and query the data warehouse is a larger productivity gain than any small company can capture. But every one of those connections is also a path from an agent to company data that needs governing. Due to the board-level excitement about AI, adoption has outpaced governance. In an April 2026 Cloud Security Alliance research note, 71% of 235 large-enterprise CISOs and CIOs said AI had access to core business systems, and 16% said that access was governed effectively.

The MCP gateway reference covers the basics of what a gateway is, how a tool call passes through it, and the enablement loop and security controls it runs. This page covers what happens when you start to scale MCP use for enterprise: the problems a small company doesn’t have, and how a gateway can address them.

What challenges do enterprises face with MCP that smaller companies don’t?

A twenty-person startup can govern MCP with a shared document and a Slack channel (actually they can’t, but they can pretend they do). The same approach fails in an enterprise. As headcount increases, you commonly encounter a few issues: shadow MCP (unknown, unvetted servers) becomes impossible to manage manually, you need both a carrot and a stick to get the desired behavior, and reporting and controls become a compliance requirement, not a nice-to-have.

Shadow MCP becomes impossible to manage manually

AI adoption has been bottoms up. Employees are connecting MCP servers to Claude, Cursor, ChatGPT, or Codex long before anyone approves them. The configuration lives in a dotfile or client setting on the laptop rather than in an installed application that asset inventory would catch, so endpoint tooling reports nothing. Shadow MCP is that unsanctioned slice, listed as MCP09 in the OWASP MCP Top 10, and it is one part of the wider shadow AI problem.

In a small company the security lead can ask everyone what they’ve connected. In an enterprise, the number of client and server combinations grows with every hire and every new client release, and the people connecting servers work in sales, finance, and support as well as engineering. Security teams we’ve spoken to describe the same sequence. They want an organization-wide view of every installed MCP server, including servers nobody is calling, before they switch to block by default. Several have accepted that they can’t stop people from building MCP servers, so they want new servers surfaced as they appear, along with newly used tools inside servers they already know about.

Only a few gateways do discovery, because a typical gateway only sees the servers registered with it. Speakeasy’s MCP gateway is part of a larger AI control plane with access to the entire agent session and its context. It uses hooks inside agents, to detect MCP servers in use that fall outside the approved list of servers. The output of discovery is an MCP inventory, which IT uses to routinely monitor server access.

Changing behavior takes a golden path and enforcement together

MCP use in an enterprise is distributed by default. Configuration sits on thousands of laptops, across several clients, in teams from engineering to finance, and each person decides on their own which server to connect and how to authenticate to it. Left alone, an estate like that tends toward entropy, because each person takes the quickest route to a working tool and thousands of quickest routes add up to something nobody designed.

A policy document doesn’t reverse the drift, because it changes nothing about which route is quickest. Two things do, and an enterprise needs both:

• A golden path (the carrot). Making it dead simple to hook up approved servers. Approved servers appear in each person’s client according to their role, sign-in happens once through the company’s identity provider (IdP), and a new hire has working tools on day one. The sanctioned route becomes the quickest route.
• Enforcement (the stick). Unapproved servers and agents are blocked by default, so the routes that bypass governance stop working.

Each fails without the other. A golden path with no enforcement is optional, and an optional path never reaches full coverage. Some people never hear about it, some prefer the setup they already have, and every server they keep outside it is missing from the inventory and the audit trail. Enforcement with no golden path blocks people from their work and offers nothing in its place. They route around the block with personal accounts, API keys pasted into scripts, and local servers, or they stop using agents and the productivity gain goes with them.

Paired, the two reinforce each other. A block that carries a request link sends the person into the approval queue, each approval adds a server to the golden path, and a wider golden path leaves fewer reasons to go around it. MoonPay runs both, with more than 200 MCP servers under governance and unsanctioned shadow MCP blocked by default.

Order matters in a rollout. Switching to block by default before the registry covers the servers people depend on produces a wave of blocked work, so enforcement usually starts in observe-only mode and tightens once the golden path is in place.

Controls and reporting become compliance requirements

A small company’s security controls are whatever its engineers decide, and it rarely needs a report on agent activity. In an enterprise, both are requirements. They come from the identity stack, regulators, procurement, and auditors, and they arrive as constraints the gateway has to meet before anyone uses it.

The IdP is the first constraint. Enterprise buyers want every human user to reach MCP through one central point with single sign-on, usually through Okta or Microsoft Entra ID. Applications already in the IdP should keep the permissions they have, and anything that isn’t gets token-based access governed by policy. They want existing directory groups to decide who reaches which servers, finance and accounting tools restricted to the people who need them, read access for business users separated from write access for engineers, and scope changes approved by the owning team rather than queued for one administrator. Rogue agents and unapproved clients shouldn’t be able to connect at all, which makes client admission a security control. Enterprise MCP auth covers how MCP establishes client and principal identity, and MCP SSO covers signing in once across servers.

Agents are the second constraint. An autonomous agent running on a shared service account is a principal the directory doesn’t model well, and an audit trail that shows only the service account can’t say which workflow did what. Non-human identity and extending IAM to agents cover the identity model.

Regulation and residency are the third. Buyers in regulated industries have told us that a HIPAA business associate agreement is a dealbreaker, with servers that carry protected health information restricted to named groups. Federal contractors ask about FedRAMP or on-premises deployment. Financial services buyers cite PCI DSS and NYDFS 500, run quarterly audits, and review SOC 2 reports, ISO 27001 certificates, and penetration test results before a proof of concept begins. Some can’t let prompts, tool calls, or session context transit a third party, and a few require air-gapped deployment. The threat is concrete. A 2025 Knostic scan found 1,862 MCP servers exposed to the internet, and all 119 it checked by hand listed their tools to an unauthenticated caller. MCP security, agent DLP, and private MCP gateway cover the controls and network options.

Reporting is the fourth. An enterprise owes reports to several audiences, and each wants a different cut of the same events.

Security and audit want a trail at the tool call: which person, through which client, called which tool on which server, with what outcome. Where agents share a service account, a tool-call record is the only way to reconstruct who did what. Some buyers want the full trail of prompts and tool calls, and then immediately need scoped access to it, so a manager can review an engineer’s sessions without gaining access to sessions from HR or legal. Leadership wants AI usage reporting for the CTO and CISO. Finance wants usage and cost by team, model, and MCP server, with budgets and alerts. Internal security teams want an API to pull the data into their own metrics dashboards. Compliance teams want runtime evidence for ISO 42001, ISO 27001, and EU AI Act audit logs, covered in agent compliance. AI cost tracking covers the spend side.

None of these reports can be assembled from client logs spread across thousands of laptops. They need one record, written at one point every call passes through.

How does an MCP gateway help an enterprise?

An MCP gateway gives an enterprise one control point with identity attached. Each routed tool call arrives carrying the person or agent behind it, the client, the server, the tool, and the arguments, so the directory’s roles can be checked, the traffic can be inspected, and one record can be written, all in the same place. The three challenges above share a root: MCP use is scattered across clients and laptops, where the organization can’t see it, steer it, or act on it. A gateway gives that traffic one path.

Why the enablement loop matters more in an enterprise

An MCP gateway runs an enablement loop: discover the servers in use, promote approved ones into a registry, distribute them by role, and govern every call at one control point. The MCP gateway reference explains each step. In an enterprise the loop matters more, because each step becomes a queue with its own owner, and the loop only works if every queue keeps moving.

Discovery without promotion leaves security with a growing list of risks and no way to say yes. Promotion that is slower than the workaround sends people back to pasting URLs into config files. The arithmetic here is a hypothetical: if each server review takes two weeks and a platform team can run five at a time, the team clears about 130 servers a year. An estate the size of MoonPay’s, which brought more than 200 MCP servers under governance, would take more than eighteen months to clear at that rate. Distribution by hand can’t reach thousands of people, so access has to come from IdP groups, and removing someone from a group has to end their access at the next sync. The loop’s last step, Govern, is the control point every call passes through, and it belongs to enablement. The security controls that run at that point, which the MCP gateway reference groups under governance, are a separate job and are covered below.

One system for the golden path and enforcement

A gateway puts the carrot and the stick in the same system. The enablement loop builds the golden path: approved servers in a registry, distributed by role from the IdP, reached with one sign-in, with upstream credentials brokered so nobody pastes a key into a config file. The control point supplies enforcement. An unapproved client is refused at admission, and each call is checked against the role of the caller. For servers outside the registry, the agent hooks, device agent, or network controls that do discovery can also block the call and hand the person a request link into the approval workflow.

That request link connects the two. The person who hits a block has a sanctioned way to get the server they wanted, and the reviewer’s approval puts it on the golden path for everyone with the same role.

Running both in one system is also how an enterprise avoids choosing between enablement and security. A gateway built only for enablement gives agents a faster route to data nobody inspects. A gateway built only for security gets routed around. When the sanctioned path is also the easiest path, the traffic security needs to see is the traffic people send.

One control point for security requirements

Once calls pass through one point, the security requirements above become things the gateway enforces rather than policies on paper. Sign-in goes through the IdP. Directory groups map to roles, roles narrow to individual tools, and the check runs on each call, so deprovisioning in the directory denies the next call. An unapproved client is refused at admission. Tool arguments and results are scanned for secrets and personal data, and tool output is inspected for prompt injection before the model reads it. The gateway holds upstream credentials centrally, so they don’t sit in config files on laptops. MCP governance covers the lifecycle of the servers themselves, from approval to retirement.

One record for every reporting audience

The same control point writes the record every audience needs. One audit event per call, tied to a directory user, streams to the SIEM for security. The same events, grouped by team, model, and server, become usage and cost reports. An administrative audit log records who changed the gateway’s own policies and when. Because everything comes from one source, the security team and the finance team are reading the same numbers.

What features does an enterprise MCP gateway need?

These are the features the challenges above turn into. An enterprise doesn’t need all of them on day one, and which ones are mandatory depends on its regulators and identity stack.

1. Shadow MCP discovery outside the gateway. Hooks in the agents people use, a device agent, MDM-delivered configuration, or network detection, feeding an inventory of servers, clients, users, and tools. Ask which clients are covered, because uncovered clients are invisible.
2. A registry with an approval workflow. Discovered servers need a path into the approved registry, filtered to approved tools, with a request link at the point of a block and a reviewer who can approve for a person, a team, or a project.
3. Directory-driven identity. SSO through the corporate IdP and SCIM directory sync, so membership and roles follow directory groups and deprovisioning carries through without a ticket.
4. Client admission. A policy for which AI clients may connect, which in practice means allowlisting Client ID Metadata Document (CIMD) URLs, with an observe-only mode before enforcement.
5. Per-tool access for people and agents. Roles granted per server and narrowed to individual tools or read-only access, assignable to registered agents as well as to people.
6. Brokered upstream credentials. The gateway acts as the OAuth client to each upstream service and stores per-user tokens, so no credential lives on a laptop.
7. Inspection with a log-only mode. Data loss prevention on tool arguments and results, and prompt injection detection on tool output, with the option to log before blocking so detectors can be tuned against real traffic.
8. Session-level response. When a session trips policy, the gateway can stop further tool calls from it and revoke the credentials it brokered.
9. A per-call audit log in the SIEM. Every call attributed to a directory user, exported over OpenTelemetry or to Datadog or Splunk, with retention and access controls on the log itself.
10. An administrative audit log. A record of who changed roles, policies, and servers, and from which surface.
11. Usage and cost reporting. Activity and spend by team, model, and server, with budgets and an API for internal dashboards.
12. Deployment that meets network and residency rules. A private network listener, tunnels to internal servers, and, where required, self-hosting or residency guarantees.
13. Vendor assurance. The gateway vendor’s own SOC 2 Type II report, ISO 27001 certificate, and penetration test results, because the gateway holds credentials for everything behind it.

The table maps each challenge to the features that address it and the page that covers it in depth.

The detail behind each row lives on those pages: MCP registry, agent access management, prompt injection, and MCP tunnels, alongside the pages already linked above.

What are the trade-offs of an enterprise MCP gateway?

A gateway concentrates risk as well as control. It holds upstream credentials for every system behind it, so a compromise of the gateway reaches all of them. It has to be run as tier-zero infrastructure, with encrypted token storage, short-lived access tokens, tight administrative access, and its own audit trail.

A gateway only governs traffic that reaches it. Local stdio servers, agents calling APIs directly with keys from environment variables, and clients that were never instrumented all bypass it, and an enterprise has more of each than a small company does. It can refuse further calls from a session but can’t end the agent’s own loop, which takes a component inside the agent such as agent hooks. It doesn’t govern model calls, which belong to an AI gateway.

Inspection has costs too. Pattern detectors are cheap, while contextual checks need a model-based judge and a model call per evaluated message. A detector that blocks legitimate work in the first week pushes people back to unsanctioned servers, so enterprise rollouts start in log-only mode. Capturing arguments and responses in the audit log means the log holds copies of the data agents touched, and it needs its own retention and access rules.

The choice of deployment model is a trade-off as well. A managed gateway removes the operational load, and a self-hosted gateway keeps traffic inside the organization at the cost of a team that runs, patches, and scales it. Which MCP gateway architecture do I need covers routing infrastructure, governance planes, and hybrids.

Does an enterprise MCP gateway need to be self-hosted?

For some enterprises it does. Buyers who can’t let prompts, tool calls, or session context transit a third party, and the few who need air-gapped deployment, have to run the gateway themselves, and open-source gateways such as Microsoft MCP Gateway and IBM ContextForge are the usual starting points.

Many requirements that sound like self-hosting are about exposure rather than operation. A requirement that the gateway have no public listener, or that internal MCP servers never face the internet, is met by a private MCP gateway and MCP tunnels, whether the gateway is managed or self-hosted. Separate the two requirements before ruling out managed options.

Speakeasy is a managed example. The gateway runs on Speakeasy-managed infrastructure and has no self-hosted option, but private network ingress on Tailscale joins it to the organization’s tailnet at a private hostname with the public path closed, and MCP tunnels let it reach MCP servers inside the private network without giving them a public address. Both are enabled per organization as they roll out. They meet exposure requirements and don’t meet residency or air-gap requirements, because prompts and tool calls still pass through Speakeasy’s infrastructure.

Which vendors offer enterprise MCP gateways?

The best MCP gateways for enterprise in 2026 scores eleven products on enablement and governance, and AI gateway vs MCP gateway vs AI Control Plane explains where adjacent layers stop.

Speakeasy. We build the Speakeasy MCP gateway, so read this entry as coming from an interested party. It is one component of the Speakeasy AI Control Plane. Shadow MCP detection uses agent hooks in Claude Code, Cursor, Codex, and OpenCode plus a device agent, and a blocked server opens an approval workflow with a request link for the person who hit the block. Sign-in works through Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML or OIDC provider, and Directory Sync provisions members and assigns roles from IdP group mappings over SCIM. Roles narrow to individual MCP servers and tools and can be assigned to registered agents. Guardrails scan tool requests and responses for secrets, personal data, and prompt injection, tool logs record every call for export over OpenTelemetry, and an admin audit log records who changed what and from which surface. Speakeasy holds SOC 2 Type II and ISO 27001 (security). MoonPay ran a 30-day proof of concept before rolling out company-wide, with more than 200 MCP servers under governance and unsanctioned shadow MCP blocked by default.

Private network support is the Speakeasy answer to most enterprise questions about self-hosting. With private network ingress on Tailscale, the gateway joins the organization’s tailnet at a stable private hostname, and each MCP server is set to public-only, dual, or private-only. In private-only mode, public hostnames return a 403 to every request, and the block stays in place if the tailnet goes down. Each request carries the Tailscale user, device, and tags alongside the OAuth identity, and access follows the tailnet ACLs the network team already maintains. MCP tunnels cover the other direction. An outbound-only connection from inside the private network lets the gateway reach internal MCP servers without an inbound port or a public address. With both in place, an agent reaches an internal MCP server without either end facing the public internet. Both features are enabled per organization on request while they roll out, and Tailscale is the only overlay network supported today. The private MCP gateway resource explains how this differs from self-hosting.

The limits matter for an enterprise evaluation. The control plane runs on Speakeasy-managed infrastructure, with no self-hosted or air-gapped option, so a buyer whose prompts and tool calls can’t leave its own cloud needs a self-hosted gateway. Discovery covers only instrumented clients. Judge-based detectors need tuning in log-only mode before they block. Directory Sync is gated by plan, and role mapping works from directory groups rather than arbitrary IdP attributes. Speakeasy doesn’t implement the Enterprise-Managed Authorization ID-JAG exchange, client admission defaults to open, and the gateway doesn’t route model traffic. If those limits fit, the Speakeasy MCP gateway page shows how it is set up.

Microsoft MCP Gateway. Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers on Kubernetes, with session-aware routing, a control plane for deploying, updating, and deleting servers, bearer-token and RBAC authentication on both planes, telemetry integration, and one-click Azure deployment. It is routing infrastructure and leaves DLP, tool-boundary inspection, and directory-to-tool mapping to other layers. It suits an Azure-centric platform team that wants to self-host. Azure API Center is a separate product that can act as an MCP registry.

IBM ContextForge. ContextForge is an open-source registry and proxy that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint, with more than 40 plugins, OpenTelemetry tracing, and multi-cluster Kubernetes deployment with Redis-backed federation. It suits a platform team that wants to self-host and bring existing non-MCP services into the same catalog. Its auto-discovery finds other gateways on the network and doesn’t detect shadow MCP, and directory integration and retention policy are the team’s to build.

Cloudflare. Cloudflare’s MCP server portals, part of Cloudflare One, became generally available on September 24, 2026. A portal gives users one endpoint for approved MCP servers, with Cloudflare Access identity policies deciding which servers each user sees, tool curation through aliases and allowlists, Code Mode to reduce tool definitions and token use, logging of tool, prompt, and resource activity, service tokens for autonomous agents, and Logpush to a SIEM. Portal traffic can route through Cloudflare Gateway for HTTP logging and DLP scanning, though DLP AI prompt profiles don’t apply to portal traffic. MCP detection in Cloudflare Gateway is in beta and can block MCP traffic that doesn’t arrive through an approved portal. It works at the network layer, so it sees remote MCP traffic that Gateway routes and TLS-inspects on managed paths and not local stdio servers, and Cloudflare notes that the absence of the signal doesn’t prove the absence of MCP. Private MCP servers can sit behind Cloudflare Tunnel or Mesh, though their OAuth endpoints still have to be public. Cloudflare AI Gateway is a separate product for model-provider traffic. Portals are a natural fit for an organization already standardized on Cloudflare One for Zero Trust.

Others. Runlayer pairs a governed MCP gateway with shadow AI discovery across agents, MCP servers, skills, and plugins. MintMCP offers role-based bundles, monitoring, and private tunnels. Kong adds MCP support to its API gateway through the AI MCP Proxy plugin. Willow (formerly Webrix), Bifrost, TrueFoundry, Docker MCP Gateway, and AWS AgentCore Gateway are also options. The shortlist covers them in more depth.

Where should you read next?

Each of these pages goes deeper on one part of the enterprise picture:

• The gateway itself: What is an MCP gateway? covers how a gateway works, the enablement loop, and the security controls.
• Vendor selection: The best MCP gateways for enterprise in 2026 has the scored shortlist.
• Identity: Enterprise MCP auth and MCP SSO.
• Server lifecycle: MCP governance.
• Network exposure: Private MCP gateway and MCP tunnels.
• Discovery: Shadow MCP and MCP inventory.
• The wider layer: AI Control Plane covers the governing layer the MCP gateway belongs to.

If you’re planning an enterprise rollout and want to compare requirements, we’d like to talk.