MCP Gateway: What It Is, How It Works, and How to Choose One

An MCP gateway is a single managed entry point between AI agents and the MCP servers they use: every agent connects to one URL, and the gateway authenticates the connection, checks each tool call against policy, and records it before forwarding the call to the server that owns the tool. It is the control point for agent tool access, the way an identity provider is the control point for human logins.

SealGate is an enterprise MCP gateway: it wraps your enabled MCP servers into one per-user endpoint and evaluates policy on every call. This guide covers how a gateway works, when you need one, what to check before you pick one, and how the main options compare.

What an MCP gateway does

The Model Context Protocol lets an agent call tools on any server that speaks it. Wired point to point, each agent holds its own connection and credentials for each server, and nobody has one place to see or stop what the agents do. A gateway collapses that mesh into one path and attaches five jobs to it:

• Aggregation. It merges the tool catalogs of many servers into one endpoint and routes each call to the owning server. This is the MCP proxy layer underneath every gateway.
• Authentication. It knows which user or agent is calling, so every action is attributable and revocable per person.
• Credential custody. Upstream API tokens and OAuth grants stay at the gateway. The agent never holds them, so it cannot call the tool around the gateway.
• Policy. Each call is allowed, blocked, or paused for a human based on the tool, its arguments, and what the session has already done.
• Audit. Every decision is logged in one place and can be streamed to the SIEM your security team already watches.

A gateway also bounds the blast radius of a bad server. A newly installed or compromised MCP server can only reach agents through the gateway, where policy applies to it like any other.

How an MCP gateway checks a call

Every tools/call an agent makes clears one checkpoint before it reaches an upstream:

The agent reaches this checkpoint through a per-user composite endpoint, with its API key carried as a segment of the URL path. Treat that URL as a credential: the key is per-user and revocable.

Because a rule sees session state as well as the current call, SealGate can catch a multi-step attack. It tracks three facts per session: whether the agent has read private data, seen untrusted content, and can communicate externally (the Lethal Trifecta). One expression covers the exfiltration pattern that prompt injection relies on:

session.has_private_data_access &&
session.has_untrusted_content_exposure &&
session.has_external_communication

SealGate tracks the trifecta on every session. Enforcement, which holds the completing outbound call for a human, is a per-organization switch that is off by default, so teams can watch where it fires before they turn blocking on. Access Control Levels run on the same engine: session.highest_acl_level == "SECRET" && resource.server == "email" keeps secret data off the mail server.

Do you need an MCP gateway?

You need one once any of these is true:

• More than one person or agent uses MCP servers, and someone is accountable for what they can reach.
• Agents touch private data (customer records, source code, internal docs) and also read untrusted content such as email, tickets, or web pages.
• Employees install MCP servers themselves, so security has no inventory of what is running.
• Compliance or incident response needs a record of which agent called which tool, and when.

A single developer running one local server for personal use can skip it. For deciding what agents should be allowed to do across an organization, see AI agent governance.

How to choose an MCP gateway

Most gateways aggregate servers and proxy calls. They differ on what happens to the call in between. Check each of these against your requirements:

• Authentication and SSO. Does each user get their own credential, so activity is attributed to a person rather than a shared connector? Can admins sign in with SAML SSO, and can you enforce SSO for your domain?
• Per-tool policy. Can you allow, block, or require approval per tool and per argument, and can a rule see what the session did earlier? Can a new rule run in log-only mode before it enforces?
• Data-leak controls. Does the gateway inspect tool arguments and results for PII and secrets, redact sensitive results before they reach the model, and block the private-data-plus-outbound pattern? This is where AI guardrails and AI data loss prevention meet the tool call.
• Local (stdio) servers. Most community MCP servers run as local processes over stdio. Find out whether the gateway hosts them in its own cloud, wraps them into HTTP services, runs them as containers, or reaches them where they already run. The answer decides where your credentials and data end up.
• Shadow MCP discovery. A gateway only governs traffic that goes through it. Can it find MCP servers that users added to their AI clients directly?
• Audit and SIEM export. Is there a per-call record with the decision and the rule that made it? Can events stream to Splunk or an HTTP collector, and what is stored by default?
• Self-hosting. Can it run in your VPC, on-premises, or air-gapped, and does that require a Kubernetes cluster?
• Client coverage. Does it work with the clients your teams use: coding agents such as Claude Code, Cursor, VS Code, and Codex CLI; cloud chat apps such as claude.ai and ChatGPT; and agent frameworks you build on?

Best MCP gateways compared

The table summarizes the main MCP gateways against the checklist, drawn from each vendor's public documentation and repositories. "Partial" means the capability exists with limits; "Not stated" means it could not be confirmed from public sources. Each name links to a full side-by-side comparison with sources.

What each is built for:

• Microsoft MCP Gateway is a reverse proxy and control plane for MCP servers on Kubernetes, with session-aware routing that pins a session to one server pod. It routes traffic and controls server access; it does not inspect tool calls.
• Docker MCP Gateway is a docker mcp CLI plugin that runs each MCP server as an isolated local container behind one endpoint, with secret management, image signature verification, and call interceptors. It is a developer tool without SSO or SIEM export.
• IBM ContextForge fronts MCP, A2A, and REST APIs behind one endpoint, with a plugin framework for guardrails, a PII filter, and federation. You self-host it and register servers into it.
• Kong AI Gateway extends Kong's API gateway to LLM, MCP, and A2A traffic through route-level plugins, and can turn existing APIs into MCP servers. It suits teams already running Kong for their APIs.
• Lasso Security is a security-first proxy with runtime behavioral analysis, prompt-injection blocking, PII masking, and tool reputation scoring.
• MintMCP is a governance-first managed gateway with SSO and SCIM-driven RBAC, virtual MCP bundles, tool-level policy, centralized audit, and compliance packaging.
• Obot is a Kubernetes-native gateway and AI platform with RBAC, a server catalog, and an endpoint agent for shadow-MCP discovery.
• SealGate is a runtime firewall for tool calls, detailed below. Its gateway core is closed source.

There is no single best MCP gateway. If you run Kubernetes and need routing, Microsoft's open-source gateway fits. If developers want isolated local servers, Docker's fits their existing workflow. If you already run Kong, extending it may be simpler than adding a product. If the requirement is stopping agents from leaking data, weight the DLP, local-server, and discovery columns most heavily. The comparison hub covers more vendors.

Open-source MCP gateways

These gateways publish their core under an open-source license:

• Microsoft MCP Gateway - MIT, Kubernetes-native routing and server deployment.
• Docker MCP Gateway - MIT, runs servers as local containers.
• IBM ContextForge - Apache-2.0, gateway, registry, and plugin-based guardrails.
• Lasso Security MCP Gateway - security-focused proxy with PII masking and injection blocking.
• Obot - Kubernetes-native gateway with a server catalog and RBAC.
• Lunar MCPX - MIT aggregator with declarative per-agent tool permissions; its DLP, SSO, audit, and SIEM features are in a closed enterprise edition.

Open source lets you read the code and run it anywhere, but you also operate it: upgrades, scaling, and the identity, audit, and alerting pieces you wire around it. SealGate's gateway is not open source. Its client-side components, the desktop app and the stdiod daemon that tunnels local MCP servers, are open source under AGPL-3.0 so security teams can review what runs on employee machines.

How SealGate works as an MCP gateway

Mapped to the checklist above:

• Identity - every user connects with their own revocable key; the admin dashboard supports SAML SSO and can require SSO for your domain.
• Policy - CEL rules run before or after a call and can block it, hold it for approval over web, desktop, Slack, or Telegram, or tag the session. Rules can run in log-only mode first. Autoconfig proposes an Access Control Level for each tool when you connect a server.
• Data-leak controls - a pii_detect rule blocks calls that send card numbers or API keys out, and PII obfuscation swaps sensitive values in tool results for tokens that are restored when passed back to a tool.
• Local servers - the desktop app tunnels local stdio servers to the gateway, so they keep running on the device.
• Discovery - with auto-quarantine on, the desktop app holds new MCP servers added to supported clients until an admin approves them.
• Audit - events stream to Splunk HEC or any HTTP endpoint; stored upstream credentials are encrypted with keys the server never stores.
• Deployment - hosted, or self-hosted in your VPC, on-premises, or air-gapped.

MCP gateway vs MCP proxy vs MCP server

These are three layers, each built on the one before it. A proxy aggregates servers; a gateway governs the proxy:

See the MCP proxy guide for the forwarding mechanics underneath.

FAQ