MCP Gateway Comparison: TrueFoundry vs. IBM ContextForge vs. Lasso Security

The table reflects what each project's own documentation and repository confirm, not marketing copy about detection accuracy or performance that cannot be independently verified.

The last column is the single most important row for the "enterprise governance" use case this comparison is scoped to. Two of the three products enforce authentication and throughput limits directly. The third does not, and treating it as a drop-in substitute for the other two would leave a real gap.

All three products sit in the same physical position, between an agent and the MCP servers it calls, but they are built around different mental models of what that position is for.

TrueFoundry's MCP Gateway is architected as a centralized control plane: a managed or self-hosted service that auto-discovers registered MCP servers, exposes them behind a "virtual MCP server" abstraction so an agent talks to one endpoint instead of wiring up each backend individually, and enforces identity and policy at that single choke point. Its OAuth 2.0 identity injection feature is worth calling out specifically: it can pass the calling user's actual identity through to a downstream tool call (an on-behalf-of pattern) rather than having every call appear to originate from a shared service account, which is a direct architectural answer to the confused deputy problem.

IBM's ContextForge is built more like a federated registry and protocol translator than a single choke point. It is a Python, FastAPI, and asyncio async gateway that can convert REST and gRPC endpoints into MCP tools, bridge MCP to Agent-to-Agent (A2A) protocol traffic, and share state across a Redis-backed, multi-cluster deployment so multiple gateway instances behave as one federation. That breadth (MCP plus A2A plus REST/gRPC) is its defining architectural trait.

Lasso's MCP Gateway is the lightest-weight of the three: a plugin pipeline that a client (Cursor, Claude Desktop, or a custom agent) routes calls through via a local mcp.json configuration. Before forwarding a call, it runs the request through a chain of plugins, a pre-connection reputation scanner that checks a server's marketplace and GitHub signal before allowing a connection, a basic plugin that masks tokens and secrets, an optional presidio plugin for PII detection, and an optional lasso plugin that calls out to Lasso's hosted API for broader prompt-injection and AI-safety checks. It is architected as a content-inspection and reputation layer, not as an identity and policy control plane.

TrueFoundry offers the widest deployment spread of the three: fully managed SaaS, an in-customer-VPC model where the control plane runs inside the customer's own AWS, GCP, or Azure account so tool descriptions and prompts never leave that environment, and an on-prem or air-gapped option for teams that cannot use any cloud-hosted control plane at all.

ContextForge is self-hosted only. There is no managed IBM offering identified in its public documentation; you run it yourself as a Docker container or a Kubernetes deployment, typically with Helm charts, and you own the Redis instance and cluster operations that its federation and caching features depend on.

Lasso's open source MCP Gateway is also self-hosted, installed via pip or run as a Docker container alongside the MCP client configuration it proxies. Its broader commercial platform, the shadow AI discovery and policy management product that the open source gateway can optionally call out to, is delivered as SaaS. That split matters operationally: adopting the free gateway component does not require adopting the paid platform, but some of its more advanced guardrail checks depend on an API key to that hosted service.

TrueFoundry integrates with federated identity providers, Okta, Azure AD, and custom SSO, combined with OAuth 2.0, and its RBAC is enforced per MCP server rather than globally, so different servers can carry different access rules under one identity model. It also sits alongside TrueFoundry's existing LLM/AI gateway and model routing product, which is a natural fit if you are already standardized on that platform.

ContextForge's integration surface is protocol breadth rather than identity-provider breadth: it speaks HTTP(S), WebSocket, SSE, stdio, and JSON-RPC, supports JWT/OAuth and mTLS for authentication, and ships OpenTelemetry tracing plus an admin UI, which makes it a plausible fit for teams that already run an observability stack expecting OTel-formatted traces. Its plugin architecture also lets teams add custom auth or guardrail logic beyond what ships by default.

Lasso's integrations lean toward developer tooling and content-safety plugins rather than enterprise identity: direct configuration support for Cursor and Claude Desktop, the Presidio PII-detection library, and its own hosted guardrail API. It does not integrate with an enterprise IdP for gateway-level authentication, because the open source gateway does not perform that kind of authentication in the first place.

TrueFoundry is the lowest-operational-lift option of the three if you choose its SaaS tier, since the vendor runs the control plane and you configure policy through its interface; the VPC and on-prem options trade some of that convenience for infrastructure you have to run yourself, in exchange for keeping data inside your own environment.

ContextForge asks the most of your team operationally. Running it well in production means operating Kubernetes, managing a Redis dependency for federation and caching, and handling upgrades and incident response yourself, since it does not carry a vendor support contract or published SLA. That is a real cost even though the software itself is free.

Lasso's open source gateway is the fastest single component to stand up (a pip install or a Docker container gets the proxy running), but the true operational effort for the "enterprise governance" use case in this article is higher than it first appears, because you still need a separate mechanism for authentication and rate limiting. Budget for pairing it with an API gateway or identity-aware proxy you already operate, rather than treating the Lasso gateway alone as a complete governance layer.

TrueFoundry publishes real, current pricing: a free Developer tier, a Pro tier at $499 per month that includes 1 million monthly requests and up to 25 MCP server registrations, a Pro Plus tier at $2,999 per month that adds SSO and HIPAA/GDPR compliance certifications along with VPC and air-gapped deployment, and custom Enterprise pricing above that for 10 million-plus monthly requests with dedicated onboarding and SLAs, according to TrueFoundry's own pricing page.

IBM ContextForge has no license cost to state honestly, because it is released under the Apache 2.0 license with no paid tier of the gateway itself. There is no publicly documented commercial support contract or SLA from IBM for this project as of this writing, so budget instead for the engineering time to run and maintain it.

Lasso Security's open source MCP Gateway is likewise free under the MIT license. Pricing for Lasso's broader commercial platform, the shadow AI discovery and policy management product some of the gateway's plugins call out to, is not publicly listed and requires contacting Lasso directly. We are stating that plainly rather than guessing at a number, since no public pricing page for it exists as of this writing.

TrueFoundry's MCP Gateway fits teams that want a single vendor to own identity, access control, rate limiting, and audit logging behind one paid product, with the deployment flexibility to keep data in their own cloud account if compliance requires it. Its limitation is cost and vendor dependency: the useful tiers start at real monthly spend, and its OAuth identity injection and RBAC only cover MCP servers registered through its own control plane.

IBM ContextForge fits teams with in-house platform engineering capacity who want a genuinely open, extensible gateway with no licensing cost and broader protocol coverage (MCP, A2A, and REST/gRPC virtualization) than a narrower MCP-only tool provides. Its limitation is that you are the support contract: there is no vendor SLA, and running its Kubernetes and Redis-backed federation well requires real operational maturity.

Lasso Security's MCP Gateway fits teams whose most pressing concern is content-level risk, secret and PII leakage through tool calls, prompt injection, and connecting to a reputationally risky MCP server, and who want that guardrail layer for free with a low-friction local install. Its limitation, stated plainly from its own repository documentation, is that it does not perform authentication or rate limiting itself, so it cannot serve as your only enterprise governance control; it needs to sit alongside something that does.

None of these three products is a universal answer. The right one depends on your architecture, budget, and what specific gap you are actually trying to close.

If your organization runs fewer than roughly ten MCP servers, all internally built or from vendors with an established change-notification process, and your agents do not have standing access to production databases, financial systems, or customer data, deploying a dedicated MCP gateway product today is probably premature. An existing API gateway or service mesh you already operate can likely absorb basic rate limiting and access logging for MCP traffic with modest configuration, and manual review of tool descriptions catches most of the realistic risk at that scale for free.

A dedicated MCP gateway earns its cost once you have real MCP sprawl: multiple teams independently connecting third-party servers with no central inventory, or agents reaching sensitive systems through MCP servers your security team did not build and cannot fully vet. If the actual problem you are worried about is a poisoned tool description or a rug pull in a specific server's code rather than a lack of runtime access control, start with the MCP server security scanner comparison instead, since a gateway sitting in front of a genuinely malicious server will still forward whatever that server's tools claim to do; it enforces who can call a tool, not whether the tool's own description is honest.

Whichever of these three you evaluate, or if you evaluate a different gateway entirely, run the same PoC checklist rather than trusting a vendor demo alone.