TL;DR

An MCP gateway enforces policy on Model Context Protocol traffic, checking who called which tool and whether they were allowed. In contrast, an MCP proxy only forwards that traffic without inspecting it. Four contenders lead the field of MCP gateways:

Traefik: Best for enterprise and platform teams needing Task, Tool, and Transaction-Based Access Control (TBAC), Kubernetes-native deployment, and one gateway to manage all AI, MCP, and API traffic.
MintMCP: Best for teams wanting a governed hosted MCP setup fast without running Kubernetes.
Kong: Best for teams already standardized on Kong, adding MCP to existing AI governance.
Docker MCP Gateway and open-source options: best for cost-sensitive teams with platform engineering capacity.

No single option wins on every axis. You trade governance depth and Kubernetes-native control for setup speed and licensing cost.

What is an MCP Gateway, and How is It Different from an MCP Proxy?

An MCP gateway inspects Model Context Protocol traffic and enforces policy on it, while an MCP proxy forwards that traffic without examining its contents. A proxy sits between an AI agent and one or more MCP servers, relaying tool calls and responses. It moves the packets, and it does not decide whether a given agent should be allowed to invoke a given tool with the arguments it sent.

That decision is the key requirement of a gateway. Three concrete controls separate the two.

First, a gateway authenticates the caller, typically by validating a JWT issued by an identity provider such as Auth0, Okta, or Azure AD, so every request carries a verified identity.
Second, it applies tool-level access control, checking which specific MCP tools a client may invoke and under what conditions rather than passing all calls through.
Third, it records an audit trail that captures who invoked which tool, with what parameters, and whether the request was permitted.

An MCP proxy cannot answer the question that compliance and security teams actually ask: "Who did what, and were they allowed?" It has no identity to attribute the call to, no policy to check the call against, and no record of the call afterward. When an AI agent can trigger financial transactions, extract customer records, or delete resources, blindly forwarding traffic is no longer acceptable.

That gap sets up the rest of this comparison. Every platform here forwards MCP traffic, so routing is table stakes. The differences that matter are the depth of the policy layer above the routing, meaning how granular the access control gets, how authorization decisions are made, and how completely each option records agent activity for frameworks like SOX, HIPAA, GDPR, and PCI DSS.

MCP Gateway vs API Gateway: Which Do You Need for AI Agents?

An API gateway routes and rate-limits HTTP requests but usually cannot handle MCP traffic due to its streaming nature, or it just treats an MCP call as an opaque payload and forwards it without inspecting. It sees a POST to a backend, applies a rate limit, checks a bearer token, and moves on. What it cannot see is that the request asks an agent to invoke a specific MCP tool, that the tool transfers funds, etc.

That blindness matters because agentic traffic carries authorization questions HTTP routing was never built to answer. An MCP request names a tool and passes arguments, and the decision you actually need is whether this identity may invoke this tool with these parameters right now. A standard API gateway can allow or deny access to the entire endpoint, but it cannot say "yes to read-only tools and no to the refund tool" or "block any transaction above $5,000." Task-level authorization is encoded in the MCP payload, and a router that ignores the payload cannot enforce it.

An API gateway is enough when you expose deterministic REST endpoints to known clients, and your only concerns are routing, rate limiting, and coarse authentication. The moment AI agents call MCP tools that touch data or trigger real transactions, you need a purpose-built MCP governance layer that reads tool semantics, enforces task-level rules, and records who invoked what.

A unified gateway that handles API, AI, and MCP traffic provides that MCP policy layer without adding an additional piece of infrastructure, which suits teams that already govern their APIs at the gateway and want agent traffic under the same control point.

Comparing Traefik, MintMCP, Kong, TrueFoundry, and Docker MCP Gateway

The five options below split into three groups:

Traefik, Kong, and TrueFoundry all ship Kubernetes-native, self-hosted deployments with a broader control plane behind their MCP governance.
MintMCP is a managed SaaS platform built around compliance-first governance rather than customer-run infrastructure.
Docker MCP Gateway (and other open-source options) prioritize self-hosting and cost over turnkey policy enforcement.

Cells marked "Unconfirmed" reflect gaps in available documentation rather than a confirmed absence.

Capability	Traefik	MintMCP	Kong	TrueFoundry	Docker MCP Gateway (AI Governance)
Kubernetes-native	Yes	No (Managed cloud, Fly.io data plane)	Yes, via KIC and the Kong Operator	Yes	No, CLI plugin plus Docker Engine containers
OAuth 2.1	Yes	No	Yes	No	Not documented
Audit logging	Yes	Access grant records signed, append-only, JWKS-verifiable.	Session-grouped, per-decision detail; no signing documented	Metrics and tool usage; no signing documented	Yes (verify signing claim before qualifying)
Self-hosted	Yes. Supports fully air-gapped deployments	Not self-serve; on-prem by request."	Yes, with an AI Gateway Enterprise license	Yes	Yes for OSS gateway; governance is cloud-connected, invite-only
TBAC	Tool, Task, Transaction	Tool-level RBAC	Tool-level RBAC	Tool-level RBAC	Tool-level RBAC
Session-smart routing	Yes	Yes	Partial (session sharing across instances unsupported)	Not documented	Not documented
OpenTelemetry	Yes (metrics, traces, logs)	Partial (Logs only (OTLP/HTTP)	Yes	Yes (metrics, traces, logs)	Not documented

The table shows a clear split. Traefik leads on governance depth with three-dimensional TBAC. TrueFoundry pairs strong Kubernetes-native, self-hosted infrastructure with token-based access control that falls short of full TBAC and a thinner audit trail than its compliance-first positioning implies. MintMCP trades Kubernetes-native control for managed setup speed, open-source options trade governance for zero licensing cost. Docker MCP Gateway runs as a local process with no inbound authentication at all, securing itself through a static tool allowlist and container isolation rather than identity-based policy.

Traefik: Unified AI, MCP, and API Gateway with TBAC

Traefik distinguishes itself from other MCP gateways through three-dimensional Task-Based Access Control (TBAC), which authorizes agent activity across tasks, tools, and transactions simultaneously. Most gateways stop at RBAC, or "can this client call this tool." TBAC also asks what business operation the agent is performing and whether the transaction stays within contextual limits, such as an approval amount or a rate quota. Policies use variable substitution, so a single rule reads JWT claims and request parameters at runtime instead of being hardcoded per agent.

The authorization model relies on JWT authentication that integrates with identity providers you already use, including Auth0, Okta, and Azure AD. The gateway acts as an OAuth 2.1/2.0-compliant resource server and automatically generates the /.well-known/oauth-protected-resource discovery endpoint, so MCP clients negotiate access without custom glue. Validation is stateless and reads the signed token directly rather than calling an external service or querying a database, so each check completes in under a millisecond.

Stateless validation is also what keeps the infrastructure footprint flat. Enforcing fine-grained access requires no separate policy engine and no session store, because the gateway derives every decision from tokens your identity provider already issues. In Kubernetes, an extra stateful dependency per service is more to deploy, secure, and page someone about at 3am.

Session-smart routing keeps a long-running agent conversation on the same upstream backend, so a multi-step workflow reaches a consistent MCP server rather than being spread across instances that may not share state. Authorization is evaluated independently for every request using the signed token, so there is no cached decision that can go stale mid-workflow.

Every authorization decision produces an audit record capturing the full three-dimensional context: which tool ran, under whose identity, and against which transaction limits. Those records map to what SOX, HIPAA, GDPR, and PCI DSS auditors ask for, and the same events flow through OpenTelemetry as metrics and traces, so compliance evidence and operational observability come from one instrumentation path rather than a separate logging pipeline.

Traefik Hub MCP Gateway runs within the same binary as the gateway, so a single control plane governs AI, MCP, and API traffic.

Traefik is the clearest choice for platform teams already running Traefik as ingress in Kubernetes. MCP governance arrives as part of the gateway you operate, with transaction-level authorization and audit trails suited to regulated environments, and without a policy engine or second gateway to stand up. Teams that only need a hosted MCP endpoint for a prototype, with no Kubernetes footprint, will find this heavier than a managed option warrants.

MintMCP: Managed Simplicity for Compliance-Conscious Teams

MintMCP is a managed cloud service, with no published Helm chart, operator, or self-serve Kubernetes path. On-premises and self-hosted deployments require a conversation with the company. If running the gateway inside your own cluster is a requirement rather than a preference, MintMCP is out before the evaluation starts.

For teams without that constraint, MintMCP removes the most operational work among the options here. Hosted connectors run on Fly.io Machines inside MintMCP's private managed data plane, reachable only over Fly's private network with no inbound routing from the internet. There is no cluster to size, no gateway to upgrade, and no connector infrastructure to keep alive.

MintMCP grants access through Virtual MCP servers mapped to SCIM-synced directory groups, so a role's toolset follows IdP group membership and offboarding takes effect at the next sync. Administrators can disable individual tools and require manual approval before newly added tools become available, with an org-wide policy that enforces that approval across every server. MintMCP treats the Virtual MCP toolset rather than the individual tool as the unit of access, and positions per-tool enable and disable as refinement within a server rather than as the way roles are handed out. That is a deliberate design position, and it means access reviews happen at the toolset level by default.

MintMCP's audit design is the strongest in this list for access review. The service signs access grant history records at write time, stores them append-only, and publishes a JWKS endpoint, so an auditor can verify exported records offline without trusting the database or the export pipeline they came through. The service also records credential creation, rotation, removal, revocation, and invalidation without logging credential values. MintMCP publishes SOC 2 Type 2, HIPAA, and CASA Tier 2 on its trust center, with the SOC 2 report available on request.

Observability is narrower than the audit story suggests. MintMCP exports activity logs in real time over OTLP/HTTP, or to a Splunk HEC endpoint, covering tool calls, prompts, gateway requests, and policy changes. It documents the logs signal only, so traces and metrics have to come from elsewhere in your stack. MintMCP can also pin a session to a specific Fly.io Machine, which keeps a conversation on one instance but is a routing mechanism rather than an authorization one.

MintMCP is the best option for teams that need governed, hosted MCP quickly and have no appetite for running gateway infrastructure. Its audit and credential lifecycle evidence is well ahead of what most gateways in this category document, making it a strong fit when a compliance reviewer, not a platform team, must be satisfied.

Kong: MCP Governance Layered Onto an Existing AI Gateway

Kong delivers MCP governance through Kong AI Gateway and Konnect rather than a standalone MCP product. Both MCP plugins require AI Gateway Enterprise, and the OAuth2 plugin is still in Tech Preview, so this is not an option for teams evaluating on an open-source budget or with a policy against preview software in production.

If those constraints are acceptable, the deployment story is the strongest in this list. Kong supports Kubernetes through both Kong Ingress Controller and a Kubernetes Operator that manages custom resources, and the MCP plugins run in traditional, hybrid, or DB-less self-hosted topologies. Everything is configured as plugins, so MCP endpoints inherit the authentication, rate-limiting, and logging plugins you already run.

The AI MCP OAuth2 plugin validates that each token targets the requested MCP server and complies with MCP authorization requirements per OAuth 2.1. Kong does not forward access tokens upstream by default, which limits token theft and confused-deputy risks, though passthrough can be enabled where an upstream requires the original token.

Per-tool access control arrived in AI Gateway 3.13. Standard Kong authentication plugins establish a Consumer identity, and ACL rules allow or deny tools for that consumer, with denied invocations returning HTTP 403 and tool discovery filtered to what the consumer can call. One behavior to plan around: a per-tool ACL replaces the default rule rather than merging with it, so adding a single exception to a tool silently drops everyone the default rule had allowed. Every tool with its own ACL has to list its allowed subjects in full.

Audit records are grouped by MCP session ID, and each access decision records the affected primitive, the allow or deny outcome, and the Consumer identity. Logging plugins ship these to external systems, and the OpenTelemetry plugin exports metrics, traces, and logs in OTLP format. Kong's documentation does not describe cryptographic signing or tamper-evidence for these records.

Kong tracks session IDs in logs, but its documentation lists session sharing between instances as unsupported, so a stateful MCP session stays bound to the gateway node that started it. That shapes how you scale out, drain nodes, and roll deployments. Active notifications on tool changes and AI Guardrails for MCP traffic are also listed as unsupported.

Kong is the easiest choice for teams already running Kong Gateway. The MCP controls are the same plugin model, the same declarative config, and the same telemetry pipeline you already operate, which is worth more in practice than any individual capability on this list.

TrueFoundry: Kubernetes-Native Infrastructure with a Thinner Audit Trail

Aside from Traefik, TrueFoundry offers the strongest Kubernetes-native, self-hosted infrastructure model. The platform ships as OpenTofu/Terraform code plus Helm charts, and the gateway plane is a single stateless Helm chart that can be deployed on any Kubernetes cluster, with no dependencies beyond a secure connection back to the control plane. Both the control plane and the gateway can run in your own environment.

TrueFoundry enforces meaningful per-tool access control through identity resolution. Configurable claims map identity provider tokens to TrueFoundry users, teams, or virtual accounts, and the resolved identity determines which MCP servers a user reaches and which tools within a server they can invoke. For upstream calls, RFC 8693 token exchange mints narrowly scoped on-behalf-of tokens so the user's broad SSO token never leaves the gateway perimeter, though that path currently requires Okta authorization servers with the Token Exchange grant and assumes the inbound token comes from the same Okta org. These controls do not extend to tasks and transactions as a unified model.

TrueFoundry's documentation describes compliance with OAuth 2.0 rather than OAuth 2.1 across its MCP auth guidance. Buyers with a hard OAuth 2.1 requirement should verify against the deployed release.

TrueFoundry documents request attribution and tool usage through its metrics and analytics dashboard, and markets audit logs for every tool invocation. What the documentation does not describe is a signed or tamper-evident audit trail, comparable to that of more audit-focused products, which is worth noting for a platform positioned around SOC 2, HIPAA, and ITAR workloads. Self-hosting also carries a cloud dependency by default: the central authentication and licensing server brokers SSO and receives user emails and gateway request counts. Removing that dependency and having the control plane talk to your IdP directly is documented, but it is on-prem only and gated to a higher-tier Enterprise plan.

TrueFoundry is the best choice for teams that want Kubernetes-native, self-hosted MCP infrastructure with real per-tool permissions, and it is the only option here advertising ITAR alongside SOC 2 and HIPAA. Buyers should account for thinner audit evidence and confirm which plan tier they need for fully self-contained identity. Session-aware execution for multi-step workflows is associated with TrueFoundry's separate Agent Gateway, not its MCP Gateway.

Docker MCP Gateway and the Open-Source Landscape: Cost-Sensitive, Self-Managed Control

Docker's MCP Gateway comes in two forms, and they govern very differently. The open-source gateway is a Docker CLI plugin that runs MCP servers in isolated containers with restricted privileges, network access, and resource usage, with built-in logging and call tracing. It is a local developer tool rather than an authenticated network service, and it ships as a binary in your Docker CLI plugins directory rather than as a Kubernetes deployment.

The governance layer is a separate, invite-only product. Docker AI Governance adds Cedar-based MCP policies that organization administrators write to control which MCP servers developers can register and what agents can do through the gateway. Rules apply at two points: registration, matching the chosen server name and resolved identity URL, and use time, matching the registered server name, tool annotations, resource URI, or prompt name. A @requireApproval annotation triggers per-request confirmation through MCP elicitation.

Two caveats matter more than the feature list. Enforcement is per-user: if MCP policy enforcement is not active for a user, the gateway does not evaluate Cedar policy and permits MCP activity, so this fails open rather than closed. And Docker explicitly states that elicitation is a confirmation guardrail for human-driven clients, not administrator approval or separation of duties, because an autonomous MCP client can respond to an in-protocol elicitation programmatically. For anything that must never run, Docker directs you to forbid rather than approve.

Docker MCP Gateway is the best choice for teams already standardized on Docker Desktop who want container isolation and policy over locally run MCP servers. It is not a network gateway, and the governance layer requires a sales conversation.

How to Evaluate an MCP Gateway

Most MCP gateways look similar in a demo. They diverge on five considerations, and the wrong answer on any of them shows up in production rather than in the evaluation.

Where the MCP Gateway Runs and Who Operates It

This is the first crucial question, and it eliminates the most options fastest. Fully managed means no cluster to size and no gateway to upgrade, at the cost of running your control plane in someone else's infrastructure. Self-hosted means Helm charts, operators, and an upgrade path you own. Some options sit in between: a self-hosted data plane with a vendor-hosted control plane, or a self-hosted deployment that still defaults to calling out to a licensing or authentication service. Ask specifically what still leaves your environment in the self-hosted configuration, because "self-hosted" rarely means fully self-contained.

The Unit of Authorization

Every gateway will tell you it has access control. The question is what it scopes to. Some grant access at the server or toolset level, on the grounds that access reviews occur at the role granularity. Some grant tool-by-tool, with allow and deny lists tied to a consumer identity. Fewer bind authorization to the task a call belongs to or to the transaction's properties, such as an amount or a rate ceiling. Decide which granularity your actual review process needs before you score anyone, because more granular is not automatically better: tool-by-tool grants fragment governance across dozens of servers, and that is a real cost.

The Evidence You Can Hand an Auditor

There is a wide gap between logging every tool call and producing records an auditor will accept. Ask whether audit records are signed at write time, whether they are append-only, and whether a verification key is published so exports can be checked offline without trusting the database or the pipeline they passed through. Ask what the signing covers, since a gateway may sign access grant history while leaving tool call logs unsigned. Then ask how records reach your SIEM, and in what format.

What Happens When Enforcement is Misconfigured

This is the question most evaluations skip and the one most likely to bite. Does policy fail open or closed when enforcement is inactive for a user? Does disabling a tool remove it from the advertised list, actually reject calls to it, or both? Is an approval gate something a human confirms, or something an autonomous client can satisfy programmatically on its own behalf? Read the vendor's own caveats here rather than the feature list, since several document these limits plainly, and they rarely appear in marketing.

Included Capabilities vs Required License Upgrades

MCP capabilities are frequently gated behind enterprise licensing, invite-only access, preview status, or a higher plan than the base product. This determines whether an evaluation is a download or a procurement cycle, so establish it early.

Observability sits alongside these rather than above them. Confirm which OpenTelemetry signals are actually supported, since some gateways export logs only and you will need traces and metrics from elsewhere in your stack.

Finally, match the answers to your situation rather than to a total score. A team already running a given gateway as ingress should prioritize consolidation heavily, because inheriting an existing plugin model, config format, and telemetry pipeline is worth more in practice than any individual capability. A regulated environment weights audit evidence and authorization granularity. A prototype weights setup time and nothing else.

Frequently Asked Questions

What authentication standards does an MCP gateway use?

MCP gateways typically authenticate agents with JWTs validated against an existing identity provider, and act as OAuth resource servers exposing discovery endpoints such as /.well-known/oauth-protected-resource. Compliance with OAuth 2.1 specifically is less common than the category's marketing suggests: several gateways document OAuth 2.0 in their published materials, and where OAuth 2.1 support exists, it may be behind an enterprise tier or a tech preview. Verify the version against the release you plan to deploy rather than the product page. Traefik acts as an OAuth 2.1/2.0-compliant resource server and validates JWTs statelessly against providers including Auth0, Okta, and Azure AD, which means no separate policy engine or credential store to operate.

What does tool-level access control mean in practice?

Tool-level access control decides which specific MCP tools an agent can invoke and under what conditions, rather than granting blanket access to an entire MCP server. Implementations differ in what they scope to. Some grant access at the server or toolset level on the reasoning that roles map to toolsets rather than individual tools. Others grant tool by tool, with allow and deny rules tied to a consumer identity. Traefik extends this into Tool, Task, and Transaction-Based Access Control (TBAC), which authorizes access across three dimensions: the business task, the individual tool, and transaction limits such as approval amounts and rate quotas. In practice, that means you can allow an agent to read records but block it from a delete tool, or cap the dollar value of a transaction it can approve.

What is session-smart routing, and why does it matter for AI agents?

Session-smart routing keeps a multi-step agent conversation on the same upstream backend rather than scattering requests across replicas that may not share state. It is a routing property rather than an authorization one. Gateways that validate a signed token on every request evaluate authorization independently each time, so there is no cached decision to drift mid-workflow. Implementations vary in how far the guarantee extends. Traefik and MintMCP both pin a session to a consistent backend. Kong tracks session IDs in its logs but documents that session sharing between instances is unsupported, so a stateful MCP session remains bound to the gateway node that started it, which shapes how you scale out and drain nodes.

Do MCP gateways run on Kubernetes?

Several do, though the deployment models differ more than the category implies. Traefik runs as a Kubernetes-native gateway across any deployment model. Kong's MCP plugins support traditional, hybrid, and DB-less self-managed topologies, run on Kubernetes via the Kong Ingress Controller and Kubernetes Operator, and are also available on Konnect, Kong's hosted platform; note that both MCP plugins require AI Gateway Enterprise. TrueFoundry ships as OpenTofu/Terraform code plus Helm charts, with a stateless gateway plane deployable on any cluster. MintMCP is a managed cloud service with on-premises available by request and documents no self-serve Kubernetes path. Docker's MCP Gateway is a CLI plugin running containers on Docker Engine rather than a Kubernetes deployment.

How does audit logging support compliance frameworks?

Audit logging records which tools an agent invoked, who requested them, and whether the request was authorized, producing the evidence trail that SOX, HIPAA, GDPR, and PCI DSS reviews expect. The gap worth understanding is between logging tool calls and producing evidence an auditor will accept without qualification. Stronger implementations sign records at write time, store them append-only, and publish a verification key so exports can be checked offline without trusting the database or the pipeline they came through. MintMCP provides access grant history and publishes a JWKS endpoint for offline verification. Kong captures per-decision details grouped by session ID but does not document signing or tamper-proof evidence. Traefik captures the full three-dimensional authorization context for every MCP operation, recording which tool ran, under whose identity, and against which transaction limits, and exports metrics and traces through OpenTelemetry. When evaluating, ask not just whether audit records exist but what the signing covers, since a gateway may sign one class of records and leave others unsigned.

Comparisons

Best MCP Gateways 2026: Traefik vs MintMCP vs Kong vs TrueFoundry vs Docker MCP Gateway