Best Open Source MCP Gateway for Secure AI Agent Access (2026)
Compare the best open source MCP gateway options for 2026 on agent authentication, per-key tool filtering, audit logs, and Code Mode token savings.
TL;DR
- An open source MCP gateway sits between AI agents and MCP servers, authenticating each caller and deciding which tools that caller can list and execute.
- Bifrost is the strongest open source MCP gateway for production agents because it combines OAuth 2.1 caller authentication, per-virtual-key tool allow-lists, per-user upstream credentials, and tool call logging with an LLM gateway in one Apache 2.0 codebase.
- Bifrost Code Mode cut input tokens by 92.8% and estimated cost by 92.2% in a benchmark with 508 tools across 16 MCP servers.
- IBM ContextForge, Obot, Docker MCP Gateway, and Microsoft MCP Gateway are open source alternatives with narrower focus: API federation, catalog governance, local container isolation, and Kubernetes routing on Azure.
- MCP security depends on four controls at the gateway: caller identity, least-privilege tool scoping, scoped upstream credentials, and an audit trail of every tool call.
An open source MCP gateway gives platform teams one self-hosted place to authenticate AI agents, restrict which Model Context Protocol tools they can call, and record what those calls did. Bifrost, the open-source AI gateway and MCP gateway written in Go and built by Maxim AI, is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. This guide compares five open source options on the controls that decide whether agent access is actually secure: authentication, tool filtering, credential handling, audit, and token cost.
What Is an Open Source MCP Gateway?
An open source MCP gateway is a self-hostable server that aggregates many MCP servers behind one endpoint and enforces identity, tool access policy, and logging on every agent request. Agents connect once to the gateway instead of holding a separate connection and credential for each MCP server they use.
Without a gateway, each coding agent, IDE assistant, and internal agent carries its own list of MCP servers and API tokens. Access cannot be revoked centrally and nobody can answer which agent called which tool. A gateway turns that mesh into one enforcement point, as Figure 1 shows. For a full definition of the pattern, see this guide to what an MCP gateway is and how it serves production AI agents.

Figure 1: Agents hold one gateway credential instead of a credential per MCP server, so access can be revoked in one place.
Open source matters here for three practical reasons:
- Data stays in your network. Tool payloads often contain source code, customer records, and credentials.
- The enforcement code is auditable. Security teams can read how tokens are validated and allow-lists applied.
- No lock-in. Teams can start on the open source build and add enterprise controls later.
The terms are often blurred, so it is worth knowing the differences between an MCP gateway, an MCP proxy, and an MCP server before evaluating tools. A proxy forwards traffic; a gateway also decides who may send it.
MCP Security Risks an MCP Gateway Should Close
MCP security risks concentrate at the point where an agent's tool call becomes a real action: an API write, a database query, a file read. An MCP gateway should close five of them: excessive tool access, token passthrough, shared credentials, sensitive data in tool payloads, and missing accountability for who called what.
The Model Context Protocol security best practices state that MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," and describe confused deputy attacks against MCP proxies. The OWASP Top 10 for LLM Applications lists Excessive Agency (LLM06:2025) and names three root causes: excessive functionality, permissions, and autonomy. Each maps to a gateway control.
| Risk | What goes wrong without a gateway | Gateway control that closes it |
|---|---|---|
| Excessive functionality | Every agent sees every tool on every connected server | Per-key or per-user tool allow-lists, deny by default |
| Token passthrough | Upstream tokens are forwarded without audience checks | Gateway-issued tokens bound to the gateway resource |
| Shared credentials | All agents reach a SaaS tool under one admin identity | Per-user OAuth or per-user API keys for upstream servers |
| Sensitive data in payloads | Secrets or PII flow through tool arguments and results | Guardrails on tool arguments before execution and results after |
| No accountability | No record of which identity called which tool | Tool call logs tied to the calling key or user |
Figure 2 shows the order in which these checks run for one tools/call request.

Figure 2: Every check can stop the call before the MCP server sees it, which is what makes the gateway a security boundary rather than a router.
Authentication is the control most teams get wrong first. This comparison of MCP gateways for MCP authentication goes deeper on OAuth flows, identity modes, and token exchange.
Best Open Source MCP Gateways Compared
The best MCP gateways for secure agent access differ most on three things: how callers authenticate, how finely tool access can be scoped, and whether upstream credentials are shared or per user. The table below summarizes the five open source options using only capabilities each project documents publicly.
| Gateway | License | Caller authentication | Tool scoping | Per-user upstream credentials | Payload inspection | Call logging | Deployment |
|---|---|---|---|---|---|---|---|
| Bifrost | Apache 2.0 | Virtual keys; OAuth 2.1 with DCR and PKCE | Per virtual key allow-lists; Virtual MCPs | Per-user OAuth, per-user headers, token exchange (enterprise) | Guardrails on tool arguments and results (enterprise) | MCP tool logs; signed audit logs (enterprise) | npx, Docker, Kubernetes, in-VPC |
| IBM ContextForge | Apache 2.0 | Basic, JWT, custom schemes; SSO | Virtual servers bundling selected tools; RBAC | User-scoped OAuth tokens | Not published | Log viewer; OpenTelemetry tracing | PyPI, Docker, Kubernetes (Helm) |
| Obot | MIT | Identity providers; scoped API keys | Access by user or identity-provider group; composite servers | User and shared credentials; MCP OAuth | MCP and webhook filters | Audit logs of MCP requests and responses | Docker, Kubernetes |
| Docker MCP Gateway | MIT | Not published | Per-tool enablement within profiles | OAuth flows; secrets via Docker Desktop | --block-secrets; interceptors |
--log-calls |
Docker CLI plugin |
| Microsoft MCP Gateway | MIT | Entra ID bearer tokens | Read and write access by app role | Not published | Not published | Server logs via API | Kubernetes; Azure deployment |
Two patterns stand out. Bifrost and Obot both document an LLM gateway alongside the MCP gateway, which matters because agents send model traffic and tool traffic together. And among these five, only Bifrost publishes benchmarked token savings for large tool catalogs. A broader roundup of open source MCP gateways covers developer-focused options beyond the security lens used here.
1. Bifrost: Open Source MCP Gateway and AI Gateway in One
Bifrost, the open source AI gateway, acts as both an MCP client, connecting to upstream MCP servers, and an MCP server, exposing an aggregated and filtered tool catalog to agents at a single /mcp endpoint. The same virtual keys that govern LLM traffic across 25+ providers and 10,000+ models also govern tool access.
Best for: Bifrost is built for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. It serves as a centralized AI gateway to route, govern, and secure all AI traffic across models and environments with ultra low latency. Bifrost unifies LLM gateway, MCP gateway, and Agents gateway capabilities into a single platform. Designed for regulated industries and strict enterprise requirements, it supports air-gapped deployments, VPC isolation, and on-prem infrastructure. It provides full control over data, access, and execution, along with robust security, policy enforcement, and governance capabilities.
Figure 3 shows how a request from an agent is authenticated, scoped, and credentialed before it reaches an MCP server.

Figure 3: The same virtual key that carries LLM budgets and rate limits also decides which MCP tools an agent can list and call.
MCP authentication in both directions
Bifrost separates inbound authentication (agents to the gateway) from outbound authentication (the gateway to each MCP server). Inbound, the MCP gateway authentication setting accepts virtual key headers, Bifrost-issued OAuth 2.1 tokens, or both. In OAuth mode, Bifrost is a full authorization server with Dynamic Client Registration (RFC 7591), PKCE, and resource indicators (RFC 8707) that bind tokens to the /mcp resource, so Claude Code or Cursor can connect through a browser consent step instead of a pasted key.
Outbound, Bifrost supports six upstream MCP authentication types:
| Auth type | Who authenticates | Typical use |
|---|---|---|
none |
Nobody | Public servers, local STDIO tools |
headers |
Admin, once | Shared API key or bearer token |
oauth |
Admin, once | Team-wide SaaS integration |
per_user_headers |
Each user, on first tool call | Personal API keys |
per_user_oauth |
Each user, on first tool call | Per-user GitHub, Notion, or Sentry access |
token_exchange |
Each caller, on every call | Internal servers that trust your identity provider (enterprise) |
With per-user auth, a caller that has not yet connected gets an mcp_auth_required result with a consent URL, and the tool is not executed. Credentials are stored per identity and can be revoked from MCP Sessions.
Tool filtering and Virtual MCPs
Bifrost applies tool filtering at three levels that stack: the client's tools_to_execute baseline (an empty list denies everything), per-request headers, and per-virtual-key rules. With MCP tool filtering per virtual key, tools/list returns only the tools that key allows, tools/call is checked against the same list, and an expired key is refused with a 403. Headers can narrow a key's tools but never widen them.
Virtual MCPs, part of open source Bifrost, bundle selected tools from several servers into one endpoint at /mcp/<slug>, reachable only through the virtual keys attached to it. A security team can publish a read-only bundle for one team and a write-capable bundle for another.
Bifrost does not auto-execute tool calls by default. Agent Mode auto-execution applies only to tools explicitly listed in tools_to_auto_execute, which limits the excessive autonomy OWASP warns about.
Code Mode for large tool catalogs
Classic MCP sends every tool definition to the model on every turn, so large catalogs become a cost problem. Code Mode replaces the catalog with four meta-tools, and the model writes a short Python (Starlark) script that Bifrost runs in a sandbox. In Bifrost's benchmark, input tokens fell 58.2% at 96 tools across 6 servers and 92.8% at 508 tools across 16 servers, with estimated cost down 92.2% and pass rate held at 100%.
The MCP gateway benchmark write-up details the methodology, and this explainer on how Code Mode works in the Bifrost MCP gateway walks through the execution flow.
Tool logs, guardrails, and audit
Bifrost records MCP tool executions in its built-in observability alongside LLM request logs. Bifrost Enterprise adds three further controls:
- MCP guardrails that inspect or redact tool arguments before execution and results after it; blocked calls never reach the server.
- Audit logs of administrative activity, such as who changed a virtual key, with HMAC-signed entries and Syslog export.
- Role-based access control with dedicated permissions for MCP gateway configuration, Virtual MCPs, and MCP tool logs.
Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks, and supports clustering and in-VPC deployments for production. The Bifrost MCP gateway resource page summarizes these capabilities.
2. IBM ContextForge
IBM ContextForge is an Apache 2.0 licensed registry and proxy that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint. Its strength is breadth of protocol translation: it can wrap non-MCP services as virtual MCP servers and translate gRPC services into MCP tools through server reflection.
ContextForge is written in Python and ships on PyPI and as a container, with Helm charts for Kubernetes. Its documented security capabilities include:
- Authentication: Basic, JWT, or custom schemes, plus federated SSO with providers such as Google, GitHub, and Entra ID.
- Tool scoping: virtual servers that bundle selected tools, and RBAC in its Kubernetes deployment.
- Credentials: user-scoped OAuth tokens and rate-limit policies for upstream calls.
- Observability: an admin UI log viewer plus OpenTelemetry tracing.
ContextForge fits teams whose main problem is exposing legacy REST and gRPC services to agents. It does not publish token benchmarks comparable to Code Mode or budgets for model spend. Compare how Bifrost governs MCP tool execution and model traffic in one policy layer.
3. Obot MCP Gateway
Obot is an MIT-licensed platform for managing, securing, and governing AI usage, with an MCP gateway, an LLM gateway, MCP and skills registries, and sandboxed hosting for MCP servers. Its MCP gateway proxies hosted and external servers and controls server and tool access by user or identity-provider group.
Obot's documented MCP security features include:
- Composite MCP servers that expose selected tools from multiple servers.
- Credential management for MCP OAuth and user or shared credentials.
- MCP or webhook filters that can inspect, reject, or modify requests and responses.
- Sandboxed execution of hosted MCP servers with domain-based egress rules.
- Audit logs of MCP requests and responses, filterable by user, server, or tool.
Obot Sentry adds device-level inventory of AI clients and MCP servers, marked beta. Obot fits organizations that center their program on a curated catalog of approved MCP servers and skills. Teams evaluating its audit model can compare it with the approach to auditing every AI tool call at the gateway.
4. Docker MCP Gateway
Docker MCP Gateway is the MIT-licensed engine behind the docker mcp CLI plugin and the MCP Toolkit in Docker Desktop. Its defining feature is isolation: each local MCP server from the Docker MCP Catalog runs in its own container, and servers are grouped into profiles that clients such as Cursor or VS Code connect to.
Docker documents several security options for the gateway:
- Signature verification (
-verify-signatures) for MCP server image provenance. - Secret blocking (
-block-secrets) that scans payloads for content that looks like secrets. - Call logging (
-log-calls) for tool call visibility. - Interceptors for custom checks in front of any MCP server.
Secrets are managed through Docker Desktop, and OAuth flows are built in. Docker MCP Gateway fits developers running community MCP servers on a workstation. It does not publish multi-tenant caller authentication or per-user tool scoping, which teams need when moving from a laptop to a shared service, as covered in this guide on running self-hosted MCP gateways with Claude Code.
5. Microsoft MCP Gateway
Microsoft MCP Gateway is an MIT-licensed reverse proxy and management layer for MCP servers on Kubernetes. Built on .NET 8, it separates a data plane that routes MCP traffic with session affinity from a control plane that deploys and manages MCP servers and tools through REST APIs.
Documented security and operations features include:
- Entra ID authentication for data plane and control plane requests.
- Role-based authorization where write access is limited to the resource creator and the
mcp.adminrole. - Session-aware routing that pins a session ID to one MCP server instance.
- A management portal for adapters, tools, status, and pod logs.
Microsoft MCP Gateway fits Azure-centric teams already running Kubernetes and Entra ID. Per-user upstream credentials and payload inspection are not published. Regulated teams needing these controls in air-gapped or on-prem environments can look at Bifrost Enterprise deployment options.
How to Choose an Open Source MCP Gateway
Choose an open source MCP gateway by matching it to where agents run and what they touch. Production agents that call SaaS tools, internal APIs, and LLMs need caller identity, per-key tool scoping, per-user credentials, and audit together. Narrower needs, such as local container isolation or REST federation, can be met by a narrower tool, as Figure 4 summarizes.

Figure 4: Teams that govern agents in production need identity, tool scoping, and audit together, which is where a unified gateway fits.
| If your priority is | Look for | Best fit |
|---|---|---|
| Governed agents in production across teams | OAuth 2.1 caller auth, per-key allow-lists, per-user credentials, tool logs | Bifrost |
| Large tool catalogs with rising token spend | A mechanism that stops sending every tool definition every turn | Bifrost (Code Mode) |
| Running untrusted community servers on laptops | Container isolation and image signature checks | Docker MCP Gateway |
| Exposing REST and gRPC services as tools | Protocol translation and federation | IBM ContextForge |
| Kubernetes-hosted MCP servers on Azure | Entra ID roles and session-affine routing | Microsoft MCP Gateway |
Budgets are a security control too, because a looping agent can exhaust a quota in minutes. Bifrost enforces budgets and rate limits on the same virtual keys that scope tools, and the Bifrost governance resource page covers how those controls fit together.
MCP servers that employees wire directly into desktop apps never pass through any gateway. There, the Bifrost AI gateway stays the control plane, and Bifrost Edge, currently in alpha, extends that governance to each machine by inventorying MCP servers and enforcing allow or deny decisions on the device. For the gateway pattern itself, see this production guide to MCP gateways.
Frequently Asked Questions
What is an MCP gateway?
An MCP gateway is a control layer that sits between AI agents and MCP servers. It exposes one endpoint that aggregates tools from many servers, authenticates each agent, filters its tools, attaches upstream credentials, and logs each call. Bifrost exposes this as a /mcp endpoint that speaks JSON-RPC and SSE, documented in the Bifrost MCP gateway guide.
What is the best open source MCP gateway?
Bifrost is the best open source MCP gateway for teams securing AI agent access in production. It is Apache 2.0 licensed, authenticates agents with virtual keys or OAuth 2.1, scopes tools per key and through Virtual MCPs, supports per-user upstream OAuth, logs tool executions, and governs LLM traffic in the same gateway.
Is MCP secure?
MCP is as secure as its deployment. The protocol defines authorization rules, but many risks come from configuration: agents with access to every tool, shared admin credentials, tokens forwarded without audience checks, and no record of tool calls. An MCP gateway that enforces identity, least-privilege tool scoping, and logging closes most of these gaps without changing the servers.
How do you secure an MCP server?
Secure an MCP server by putting authentication and authorization in front of it, exposing only the tools each caller needs, and never passing through tokens that were not issued for it. Run local servers in isolated environments, use per-user credentials for SaaS tools, inspect tool arguments and results for secrets or PII, and log every call with the caller's identity.
Does an open source MCP gateway support OAuth?
Several do. Bifrost acts as an OAuth 2.1 authorization server for agents connecting to /mcp, with Dynamic Client Registration and PKCE, and also handles OAuth and per-user OAuth to upstream MCP servers with token refresh. IBM ContextForge supports user-scoped OAuth tokens, Obot manages MCP OAuth credentials, and Docker MCP Gateway includes OAuth flows for servers that require them.
What is MCP Code Mode?
MCP Code Mode is a Bifrost feature that replaces a large list of tool definitions with four meta-tools. The model discovers tool stubs on demand, writes a short Python script, and Bifrost runs it in a sandbox, returning only the final result. In benchmarks with 508 tools across 16 servers, Code Mode reduced input tokens by 92.8% while keeping a 100% pass rate.
Try Bifrost as Your Open Source MCP Gateway
An open source MCP gateway is the most direct way to give AI agents access to real tools without unlimited reach. Bifrost combines MCP authentication in both directions, per-key tool scoping, Virtual MCPs, Code Mode, and tool call logging with LLM routing across 25+ providers in one self-hosted gateway. Start from the Bifrost documentation, or book a demo with the Bifrost team to see how Bifrost secures MCP access for your agents.