What are the best MCP gateways for enterprise access control in 2026?

Last updated: October 2026

A Model Context Protocol (MCP) gateway sits between AI agents and the tools they call, which makes it the place an organization decides who may call what. By late 2026, nearly every gateway on the market can restrict a tool to a group. What separates them for an enterprise is where that group comes from, what happens to access when someone leaves or changes teams, and whether the audit trail can say who was able to reach a tool on a given day, not only who called it.

This roundup scores thirteen products on those three questions: Speakeasy, which ships its MCP gateway as part of an AI Control Plane; three dedicated governance gateways (Runlayer, Mintive, and Willow); two network and API platforms that added MCP (Cloudflare MCP server portals and Kong); three AI gateways with MCP access controls (TrueFoundry, LiteLLM, and Bifrost); and four platform and open-source options (AWS AgentCore Gateway, IBM ContextForge, Microsoft MCP Gateway, and Docker MCP Gateway). If your organization already runs Cloudflare Zero Trust, Kong, or AWS for everything else, the gateway that platform ships is a reasonable first answer, and the sections below say where each one stops.

Isn't single sign-on in front of the gateway enough?

For a proof of concept, often yes. Put single sign-on (SSO) in front of a gateway, allowlist two servers, and you have a working control that the security team can explain. Cloudflare MCP server portals make this especially direct: an Access policy can match an identity provider (IdP) group, and the portal only lists servers to users who pass it. Kong and AWS AgentCore Gateway do the same with an OpenID Connect token. None of them requires a new vendor, a new security review, or a new procurement cycle, and when MCP use means a few internal APIs and a few agents, that is decisive.

SSO answers who can sign in. It does not, by itself, answer the three questions an access review asks a few months into a rollout. The first is which tools a person can call, decided from directory data rather than from a list someone maintains inside the gateway. The second is what happens when that person moves teams or leaves: does access change on the next directory sync, at the next token refresh, or when someone remembers to edit the gateway? The third is whether the log records the access decision itself (the grant, the block, the denied attempt) or only the tool calls that succeeded. A gateway can be excellent at SSO and still leave all three to a spreadsheet.

How we evaluated MCP gateways for org-wide access

We scored each product on seven criteria. They come from the access questions we see in enterprise evaluations and security questionnaires, they don't map onto any one vendor's feature list, and we note where a vendor's documentation is silent rather than guessing.

• Directory as the source of truth. Do directory groups and attributes, synced over SCIM, decide access directly, or does an administrator mirror them by hand into gateway-local teams, keys, or Consumers? Mirrored access drifts, and drift is what an auditor finds.
• Tool-level grants and blocks. Can a grant narrow from a whole server to named tools, to tool annotations such as read-only, or to argument-level conditions? Is there a deny rule that outranks a grant from another group? Without one, removing a single person from a single server means restructuring groups.
• Agents and non-human callers. Can a registered agent, workload, or service account hold a grant the same way a person does, and is that grant held to a narrower ceiling than a person's?
• Client admission. Which MCP clients may connect at all? Dynamic Client Registration (DCR) lets any client register under any name; Client ID Metadata Documents (CIMD) give each client a URL on its vendor's domain that a policy can name. The trade-off is covered in CIMD vs DCR for MCP OAuth.
• Revocation. How does access end, and how fast? Three cases matter: offboarding through the directory, an emergency stop for one person during an incident, and revoking a client or session. Upstream OAuth tokens issued to the gateway on a person's behalf are part of this, because ending a gateway session does not always end them.
• Audit trail. Does the log name the directory user and the client on each call, and does it also record changes to access (who granted what to whom, and when) so that "who could reach this server on 3 September" has an answer? Can it be exported to a security information and event management (SIEM) tool?
• Reach beyond the gateway. A gateway only governs traffic sent to it. Does the product see AI tools and MCP servers that never route through it? See what is shadow MCP.

We left out latency and price. Vendor latency figures come from vendor-run benchmarks, and pricing for everything but the open-source options is negotiated.

MCP gateway access management at a glance

The table summarizes how each product answers the access questions. Use it to build a shortlist. Several of these products are excellent at jobs this page doesn't weigh, such as model routing or container lifecycle, and the table says nothing about those. Profiles follow, each with links to the vendor documentation behind the claims.

Where Speakeasy fits

Speakeasy is built for the evaluation where the directory has to stay the source of truth for tool access, and where the same identity data has to drive grants, emergency stops, and the audit record. The MCP gateway is one part of the AI Control Plane, so the roles that decide which tools a person can call are the same roles that decide which plugins they receive and how their spend is broken down.

Directory to tool. People sync from Okta, Microsoft Entra ID, or another SCIM provider through directory sync, and sign-in is federated to the organization's IdP, so its MFA and conditional access policies apply. Administrators map directory groups and attribute values to roles; with directory sync on, role membership is read-only in Speakeasy and marked Managed by directory sync, so nobody can quietly add a person outside the IdP. Each role carries permissions, and the role editor narrows mcp:connect to all servers, specific projects, specific servers, or specific tools. The same rules appear on each server's Team Access tab, where a grant can also be narrowed by tool annotation, so "Engineering can call everything on the GitHub server except destructive tools" is one rule that keeps covering tools the server adds later. Granting a role access to a server also adds it to that role's plugin through automatic MCP distribution, so access and installation don't drift apart.

Blocks and agents. Every read, write, and connect scope has a blocking counterpart, such as mcp:blocked_connect, and a block withdraws that scope even when another role grants it. That is what lets an administrator take one server away from one group without restructuring every role. Roles can also be assigned to registered agent identities through Assign Agents, and an agent's grants are filtered against an agent runtime scope allowlist, so a role can't hand an agent a scope it could not be granted directly.

Upstream credentials. Behind the gateway, each remote server holds either a token per end user or one shared credential for every caller, and the static-credential guide covers the shared case. For Okta organizations, Enterprise Managed Auth uses Cross App Access (XAA): a person signs in once with Okta and reaches every MCP server set up for them without a separate OAuth prompt per service, and Okta's own assignments decide which people may reach which apps. The Okta API service connection uses one read-only scope (okta.apps.read), Speakeasy never writes to the Okta org, and that connection does not issue tokens or sign anyone in. Cross App Access itself is set up separately in Okta through a checklist. The Okta use case page walks through the setup.

Revocation. Removing or suspending a person in the IdP deprovisions them, ends their memberships and roles, and blocks agents they own until an administrator reassigns them. For an incident, a killswitch stops one person's tool calls on all or selected servers, now or on a schedule, without touching their account or roles. Administrators can also revoke a single session or a whole client registration from Clients and Sessions. Client admission is a separate per-server setting: with Verified clients selected, only clients whose metadata documents are in a Speakeasy-maintained catalog, or on a list the organization adds, can start an OAuth flow, as described in OAuth client registration.

Audit. The org-wide Audit Logs feed records administrative activity with a resource:action badge, the actor, a diff of what changed, and the surface the change came from (an API key, the Platform MCP, or the Project assistant), with filters and an Audit Log Insights assistant for questions over the feed. MCP session revocations and transcript opens are audit-logged. Reading other people's agent transcripts requires chat:read, which is in no default role, Admin included. Denied requests are kept as authorization challenges, filterable by person and scope, and an administrator can resolve one by granting the custom role that covers it.

Reach beyond the gateway. Shadow AI is generally available under Guardrails for every organization. The device agent inventories the coding harnesses, assistants, and local models on enrolled devices, and each tool can be marked Approved or Blocked at the MCP gateway; a Blocked tool is refused when it authenticates, on every MCP server in the organization. Calls to MCP servers nobody registered surface as shadow MCP, with allow and block lists to act on them. Speakeasy holds SOC 2 Type 2 and ISO 27001.

The limits are as specific as the features. Speakeasy is a managed gateway on Speakeasy-operated infrastructure; there is no self-hosted or air-gapped version, and if that is a hard requirement, Willow, TrueFoundry, LiteLLM, Bifrost, or IBM ContextForge are the better fit. Private network access is covered in the next section and requires an Enterprise organization. Enterprise Managed Auth supports Okta only, and its revocation is not instantaneous: downstream tokens already issued stay valid until they expire. Revoking a gateway session invalidates the token Speakeasy issued, not the upstream OAuth token held for the person, which remains in the upstream service until it is revoked there. A killswitch covers a member's own signed-in sessions, not API keys or registered agents, and blocking rules cannot be written against agents, so an agent is taken off a server by removing its grant. Shadow AI decisions are enforced only for tools that publish a client metadata document, a decision about a tool with no MCP client of its own is recorded but never enforced, and a tool on an unenrolled device appears nowhere. Narrowing remote and tunneled servers by tool name requires the server's tool metadata to have been recorded first, and a name-based grant has to be revisited when the server gains tools.

What if MCP servers have to stay off the public internet?

This is where buyers most often ask for self-hosting, and where the answer matters more than any row in the table. Speakeasy does not self-host. It offers private network access over Tailscale for organizations on an Enterprise plan: the organization connects its tailnet once, and each hosted MCP server or gateway is set to public only, public and private, or private only. A private-only server stops serving on public URLs entirely, and there is no automatic public fallback if the tailnet is unavailable. Tailscale membership is an additional network restriction, layered on top of MCP authentication and team access rather than replacing them. If your organization is not on an Enterprise plan, private access is not available to you.

Private network access controls how MCP clients reach the gateway. For the other direction, reaching MCP servers that run inside your network, Speakeasy uses tunneled servers with an outbound-only connection from a tunnel agent you run. The private MCP gateway guide explains why "private" and "self-hosted" are different requirements, and why a self-hosted gateway on a public load balancer is as exposed as a hosted one. If your requirement is that no vendor-operated component touches the traffic at all, a managed gateway is the wrong category, and the self-hosted products below are where to look.

Dedicated MCP governance gateways: Runlayer, Mintive, and Willow

These three were built as MCP governance products first. All three sync groups from the directory, which puts them ahead of most of the field on the first criterion, and they differ in how finely a grant can be shaped and in what the log records about access changes.

Runlayer: the most expressive policy conditions

Runlayer has the most expressive per-call policy on this list, and a security-led evaluation should look at it closely. Its access rules grant a server or specific tools to users, SSO-synced groups, roles, IdP attributes such as department, or Agent Accounts, and a rule can add conditions on tool arguments, IP range, OAuth session properties, tool annotations, session history, or the MCP client, with global deny rules for the cases that must never run. Platform roles are a separate layer, assigned directly or through SCIM group-to-role mapping, so administrative rights and tool rights are decided independently. The audit log records tool calls, policy changes, access requests and approvals, authentication events, and agent account lifecycle, keeps 90 days in the viewer by default, archives older events rather than deleting them, and supports SIEM export.

The trade-off is the one that comes with expressiveness. Argument-level conditions catch cases a tool-level grant can't, and they are also policy your security team writes and maintains, and machine identities are Runlayer Agent Accounts with credentials Runlayer manages. See Speakeasy vs Runlayer and Runlayer alternatives.

Mintive: access shaped around Virtual MCPs

Mintive organizes access around Virtual MCPs: an administrator bundles the connectors and tools a team needs into one endpoint, then grants that Virtual MCP to a directory group. With groups synced over SCIM, people gain and lose tools as they join and leave teams, and Mintive's documentation says offboarding from a role removes the tools at the next SCIM sync. Virtual MCPs a user isn't granted are not listed in their store at all. The access-change record is strong: every grant and revoke of Virtual MCP access is its own entry, so an administrator can reconstruct who had access at any point, and those records export over OTLP or to Splunk alongside gateway tool calls.

The model works best when tool access differs by team. When it differs by person within a team, or by tool within a server, the answer is another Virtual MCP, and the number of bundles grows with the number of exceptions. See Speakeasy vs Mintive and Mintive alternatives.

Willow: group-based access with a full call log

Willow, which rebranded from Webrix in 2026, routes runtime access through groups: a group links users or machine users to MCP servers, toolkits, and skills, and a person receives the union of every group they belong to. Groups provisioned over SCIM are read-only in Willow, so membership follows the IdP. Its request path checks identity, then group access to the target server, then runtime guards, and every stage is logged with the user, agent, server, tool, status, and guard actions. Willow deploys as SaaS, as a hybrid with the runtime in your cluster, or fully on-premises with no runtime dependency on Willow's cloud.

Willow's documentation is explicit that there is no deny rule: access is the union of a person's groups. That keeps the model easy to reason about, and it means removing one server from one person requires changing their groups rather than writing an exception. See Speakeasy vs Willow.

Network and API platforms that added MCP: Cloudflare and Kong

Both arrive at MCP from infrastructure that many enterprises already run, which is the strongest argument for either. Neither requires a new identity integration if one already exists for the platform.

Cloudflare MCP server portals: Zero Trust policy in front of MCP

MCP server portals put Cloudflare Access in front of a set of MCP servers. Users sign in through the organization's IdP, Access policies decide who can reach the portal and which servers appear in it, and administrators choose which tools and prompts each portal exposes, with aliases and an allowlist mode that hides everything not explicitly turned on. Access policies can match IdP groups, SAML attributes, and OIDC claims. With SCIM and user deprovisioning turned on, removing someone in the IdP revokes their active Access sessions. Portal requests are logged, and routing portal traffic through Cloudflare Gateway adds HTTP logging and data loss prevention scanning on tool calls and responses. For an organization already on Cloudflare One, this is the shortest path to a governed MCP endpoint.

The access model is per portal rather than per group within a portal: a team that needs a different tool set gets a different portal. Cloudflare's documentation also notes that a user blocked by a server's Access policy can still reach that server directly by its URL unless Access is configured as the server's OAuth provider, so the portal governs the path through it. Machine access uses service tokens, which reach upstream servers through the shared admin credential rather than per-user OAuth.

Kong: tool ACLs on the API gateway you already run

Kong's MCP support runs as the AI MCP Proxy plugin on AI Gateway, converting REST APIs into MCP tools or fronting existing MCP servers. From gateway 3.13, ACLs on Consumers and Consumer Groups control which tools each caller can discover and invoke, per tool or by default, and every allowed and denied attempt is written to the plugin's audit log. Identity comes from Kong's authentication plugins: the OpenID Connect plugin can map an IdP claim to a Consumer Group, and AI Gateway 2.0 maps tokens to AI Consumers or Kong Identity principals. For an enterprise that already operates Kong well, that is a working MCP access layer with no new vendor.

The gaps are documented in Kong's own scope-of-support table: AI Guardrails are not supported on MCP plugin traffic, and Consumer and Consumer Group scoping of the plugin itself is not supported. The directory link is a claim in the token, so group changes reach Kong as tokens are reissued, and Kong has no presence outside its own gateway. See Kong MCP gateway alternatives.

AI gateways with MCP access controls: TrueFoundry, LiteLLM, and Bifrost

These three route model traffic first and extend the same gateway to tool traffic. If provider failover and cost controls on model calls are the primary job, one of them is likely already on your shortlist, and their MCP access controls have improved quickly.

TrueFoundry: directory groups mapped to teams

TrueFoundry supports SSO over SAML or OIDC with SCIM or just-in-time provisioning, and IdP groups map to TrueFoundry teams whose grants propagate to members. On the MCP gateway, roles are granted per server, individual tools can be disabled, a team can be given an approved subset through a virtual MCP server, and every tool call is traced with user attribution and exported over OpenTelemetry. TrueFoundry has also announced Cross App Access support for Okta, the same standard behind Speakeasy's Enterprise Managed Auth. It deploys as SaaS, as a gateway plane in your environment, or fully self-hosted, which matters for the buyers in the previous section.

The access model is strongest where teams are the unit of access. Its documentation describes tool control as disabling tools or curating virtual servers rather than as per-tool grants with deny rules, and it has no presence on devices or in coding agents, so AI usage that doesn't route through the gateway is outside its view. See Speakeasy vs TrueFoundry.

LiteLLM: keys, teams, and intersecting permissions

LiteLLM's MCP permission management is more layered than its reputation as a key-based proxy suggests. Server and tool permissions can be set on keys, teams, end users, agents, internal users, and organizations, and LiteLLM intersects them so that the most restrictive wins, with the organization as a ceiling. With SCIM, each IdP group becomes a LiteLLM team, and MCP servers granted to the team reach its members through keys that belong to it. An audit log of key, team, and user changes is part of the enterprise tier. It is open source and self-hosts on your own infrastructure.

Two defaults deserve attention in a review. If no level carries a list, every MCP server is reachable, and LiteLLM's own documentation recommends require_key_mcp_access_defined: true so that a key with no explicit grant gets nothing. And requests still authenticate with virtual keys, so offboarding means the SCIM update and the key both have to end.

Bifrost: deny-by-default tool allowlists

Bifrost, the open-source AI gateway from Maxim AI, attaches MCP tool allowlists to virtual keys: a key with no MCP configuration gets no tools, specific tools or a wildcard can be granted per MCP client, and the allowlist is enforced again at execution time, where inactive or expired keys are refused. Its MCP gateway authentication runs OAuth 2.1 with DCR and PKCE, and the grant can be bound to a virtual key or, with SSO and SCIM in the Enterprise tier, to the signed-in user. Enterprise adds signed audit logs of administrative activity, and tool execution logs can be filtered by key.

Directory-resolved identity is an Enterprise feature, and without it the principal on each tool call is a virtual key. Bifrost belongs on a shortlist where a self-hosted binary for model and tool traffic is the constraint, including air-gapped deployments. See Speakeasy vs Bifrost and Bifrost alternatives.

Platform and open-source MCP gateways: AWS, IBM, Microsoft, and Docker

These four are infrastructure you run or consume inside a platform you already use. They belong on an enterprise list because enterprises use them, and for a scoped deployment they are often the right amount of product.

AWS AgentCore Gateway: Cedar policy on Bedrock

Amazon Bedrock AgentCore Gateway turns APIs, Lambda functions, and existing services into MCP tools and handles inbound and outbound authentication in one managed service. Policy in AgentCore evaluates each tool invocation against Cedar policies, deny by default with forbid winning, over the caller's identity and the tool's input parameters, and interceptors run Lambda code before and after a call for checks Cedar can't express. Inbound identity is a JWT from your OIDC provider or an IAM principal, so directory groups reach the policy as token claims. For agents built on Bedrock calling AWS-hosted tools, it is the obvious first gateway.

Its boundary is the AWS account. It governs what is routed through it, its inventory is the targets you registered, and an employee's coding agent pointed at a third-party MCP server is outside its view.

IBM ContextForge: open-source teams and RBAC

IBM ContextForge is an Apache 2.0 registry and proxy that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint, deployable with Docker or Helm. Its access model has two layers: token scoping decides which resources a caller can see, by team and by public, team, or private visibility, and RBAC decides which actions they can take, such as tools.execute. SSO works with Okta, Entra ID, Keycloak, and generic OIDC, creates users on first login, and maps SSO groups to teams. Session tokens resolve team membership from the database on each request, so a revoked membership takes effect without waiting for the token to expire. IBM offers commercial support alongside the community channels.

The trade-offs are the usual ones for self-run infrastructure. Its audit trail logging, which records changes to resources, is off by default and has to be turned on, and the SSO guide describes provisioning at login, so check how a directory removal reaches ContextForge before relying on it for offboarding. The project supports only its latest release.

Microsoft MCP Gateway: Entra app roles on Kubernetes

Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers on Kubernetes, with stateless routing and a control plane for deploying and updating servers and tools. It authenticates with Entra ID and authorizes with app roles: each adapter or tool lists the roles that may read it, and writes are limited to the creator and holders of mcp.admin. That is a clean directory link for a Microsoft shop running servers on AKS. It leaves tool-level policy beyond role membership, threat detection, and an access-change audit trail to the layers around it.

Docker MCP Gateway: Cedar policy for Docker organizations

The open-source Docker MCP Gateway runs MCP servers in isolated containers and handles routing, credentials, and lifecycle for the servers in a profile. Docker has since added organization governance: MCP access policies written in Cedar control which servers developers can register and which tool calls, resource reads, and prompts the gateway allows, with forbid rules that override permits and an approval mode for sensitive calls. Policies are scoped to the organization or to Docker teams, which SCIM can sync from IdP groups, and governance audit records can be exported and forwarded to a SIEM.

The governance layer is invite-only and sold separately, and it applies to Docker sandboxes and the requests Docker's gateway handles. Docker's documentation notes that an MCP server an agent connects to directly from inside a sandbox is governed by network policy instead, so closing both paths takes two rules. For a team that already standardizes on Docker, it is a reasonable place to start; we covered the architecture in which MCP gateway architecture do I need.

Which MCP gateway should you choose for org-wide access?

The decision rule, by the constraint that dominates your evaluation:

• The directory must decide tool access, with blocks, agent grants, an emergency stop, and reach to AI tools that never touch the gateway. Speakeasy, if a managed gateway is acceptable; on an Enterprise plan if MCP traffic has to stay on a private network.
• Argument-level policy conditions are the security team's top requirement. Runlayer.
• Access differs by team, and the shortest path to a governed store matters most. Mintive, or Willow if self-serve enablement and group-based assignment fit how you work.
• You already run Cloudflare Zero Trust, Kong, or Bedrock. Start with Cloudflare MCP server portals, Kong's AI MCP Proxy, or AWS AgentCore Gateway, and revisit when a review asks for per-group tool sets, an access-change history, or visibility outside the gateway.
• Model routing is the primary job and MCP rides the same gateway. TrueFoundry for a commercial vendor with team mapping, LiteLLM for maturity and the widest integration surface, Bifrost for a self-hosted binary.
• No vendor-operated component may touch the traffic. A self-hosted option: IBM ContextForge, LiteLLM, Bifrost, TrueFoundry, Willow, or Microsoft MCP Gateway on AKS.
• A single team on Docker infrastructure is running a scoped proof of concept. Docker MCP Gateway.

What should an MCP access proof of concept test?

A proof of concept with one server and a handful of users is the right size, and the risk in that size is that it passes without exercising the controls that fail at rollout. Whatever gateway you pick, put these on the test plan:

• Offboarding. Remove a test user from the directory and confirm their next tool call is refused without anyone touching the gateway. Record how long it took.
• Team change. Move a user between two directory groups and confirm their tool list changes to match.
• Least privilege. Grant a role read-only access and confirm a write-annotated tool is refused at call time, not only hidden from the list.
• Exception. Take one server away from one person who keeps it through another group, and note whether the product needs a deny rule, a new group, or a new bundle to do it.
• Emergency stop. Stop one person's tool calls during a simulated incident and confirm everything else they use keeps working.
• Client admission. Connect from an MCP client that is not on the approved list and record what the user sees and what the log records.
• Audit question. Ask the log who could reach the test server on a specific past date, and who changed that.
• Traffic outside the gateway. Point a coding agent at an unregistered server and see whether the product notices.

If a gateway passes all eight with one server, scaling it is mostly configuration. If it fails one, you know which conversation to have with the vendor before signing.

If you're working through a shortlist like this one, or planning an access proof of concept and want to compare test plans, we'd like to talk.