What is an enterprise MCP gateway?

By Nolan Sullivan, Founding Growth Engineer

·Published September 29, 2026·Updated October 6, 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 add up to a larger productivity gain than any small company can capture. But those connections are also paths from agents to company data that need governing, and adoption has outpaced governance. In the 2026 CISO AI Risk Report from Cybersecurity Insiders, cited 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 scale enterprise MCP use across an organization, including 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 20-person startup can often govern MCP with a shared document and a Slack channel. The same approach tends to fail in an enterprise. As headcount increases, three issues appear: shadow MCP (unknown, unvetted servers) becomes impractical to manage manually, behavior only changes with both a carrot and a stick, and controls and reporting become compliance requirements rather than nice-to-haves.

Shadow MCP becomes impractical to manage manually

AI adoption has been bottom-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 typically 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 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). It makes hooking up approved servers simple. 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. People 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. The agent hooks, device agent, or network controls that detect unsanctioned servers can also block the call and hand over that request link. MoonPay runs both, with more than 200 MCP servers under governance and unsanctioned shadow MCP blocked by default.

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 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 that shows 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 often 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. AI cost tracking covers the spend side.
• 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.

These reports are hard to assemble from client logs spread across thousands of laptops, and they need one record, written at one point every routed call passes through.

How does an enterprise MCP gateway address these challenges?

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 that discovers the servers in use, promotes approved ones into a registry, distributes them by role, and governs 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. As 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 like MoonPay’s, with more than 200 MCP servers under governance, would take more than 18 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.

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 routed through the gateway 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 MCP 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, as covered in agent access management.
6. Brokered upstream credentials. The gateway acts as the OAuth client to each upstream service and stores per-user tokens, so upstream credentials don’t need to live 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.

What are the trade-offs and limitations 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 can reach 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 typically 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 typically 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 reduces 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 an open-source MCP gateway such as Microsoft MCP Gateway or IBM ContextForge is the usual starting point.

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 offers private network ingress on Tailscale, which joins the gateway to the organization’s tailnet at a private hostname with the option to close the public path, and MCP tunnels, which let it reach MCP servers inside the private network without giving them a public address. Both are enabled per organization as they roll out, and Tailscale is the only overlay network supported today. Each MCP server can be set to public-only, dual, or private-only, and in private-only mode public hostnames return a 403 to every request, even if the tailnet goes down. Each request carries the Tailscale user, device, and tags alongside the OAuth identity, and access follows the tailnet ACLs. Tunnels are outbound-only, so the private network needs no inbound port. Together they meet exposure requirements.

Which vendors offer enterprise MCP gateways?

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

The table compares the enterprise options on the questions that decide most evaluations: how each finds MCP servers it doesn’t route, who the gateway treats as the caller, and where it runs. It draws on each vendor’s public documentation as of September 2026, and the profiles below go deeper.

Speakeasy. We build the Speakeasy MCP gateway, so this entry is not neutral. 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. Its private network options, Tailscale ingress and MCP tunnels, are covered in the self-hosting section above.

The limits matter for an enterprise evaluation. 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 mappings use directory groups or exact attribute values such as department. Enterprise Managed Authorization, which exchanges an Okta identity for an ID-JAG, works with Okta only. Speakeasy doesn’t route model traffic, and client admission defaults to open. 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 stateless per-request routing, a control plane for deploying, updating, and deleting servers, bearer-token and RBAC authentication on both planes, telemetry integration, and a Deploy to Azure button. It is routing infrastructure and leaves DLP and tool-boundary inspection 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 its documentation doesn’t list shadow MCP detection.

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, 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 but 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 suit an organization already standardized on Cloudflare One.

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

Where can you learn more about enterprise MCP gateways?

Each of these pages goes deeper on one part of enterprise MCP governance and gateway selection:

• 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.