Speakeasy vs IBM ContextForge: Should you run your own MCP gateway?

IBM ContextForge is the better fit when the gateway has to run inside your own infrastructure and front REST, gRPC, and agent-to-agent (A2A) services alongside Model Context Protocol (MCP) servers. Speakeasy is the better fit when access has to follow your identity provider, be granted one tool at a time, and reach AI clients that never point at a gateway, and when you would rather not operate the gateway yourself.

ContextForge is IBM's open-source MCP gateway, also known as MCP Context Forge after its GitHub repository, IBM/mcp-context-forge. Speakeasy's MCP gateway is part of the Speakeasy AI Control Plane, a managed platform. This post compares the two on deployment model, identity and directory sync, per-tool policy, client admission and Shadow AI, upstream credentials, and audit, then gives a decision rule.

What is IBM ContextForge?

IBM ContextForge is an open-source registry and proxy, licensed under Apache 2.0, that federates MCP servers, A2A agents, and REST or gRPC APIs behind one endpoint, according to its README. Teams register upstream MCP servers as gateways, then compose virtual servers that bundle selected tools into a single MCP endpoint. A REST-to-MCP adapter and gRPC reflection turn existing non-MCP services into tools without new server code. A plugin framework with more than 40 plugins adds PII filtering, deny lists, moderation, and external policy servers such as OPA, and OpenTelemetry tracing exports to Phoenix, Jaeger, Zipkin, and other OTLP backends.

ContextForge installs from PyPI or as a container, and its deployment guides cover Helm, AWS, Azure, Google Cloud Run, IBM Code Engine, and OpenShift. The project does not hold features back for a paid tier. The licensing section of IBM's gateway selection guide says there is no open-core split and no telemetry, and it lists IBM Elite Support with SLAs for v1.0.0 GA and later. The same guide says ContextForge powers IBM Consulting Advantage, which IBM puts at more than 160,000 users. It also states that only the latest release is supported, with no backports to older versions.

What is Speakeasy?

Speakeasy runs the MCP gateway for you. People sign in through company SSO, roles follow directory groups over SCIM, grants can be narrowed to a single tool, and the gateway can refuse AI clients the security team has blocked. Every MCP server, remote or built from an OpenAPI document, sits behind the same access model and the same audit trail.

Speakeasy is a managed gateway. It has no self-hosted, on-premises, or air-gapped edition. For organizations whose requirement is a private path rather than self-operation, an Enterprise organization can serve MCP endpoints over a Tailscale tailnet, covered in the deployment section below.

Speakeasy vs IBM ContextForge at a glance

Who runs the gateway?

Settle this before comparing features, because a self-hosting requirement rules Speakeasy out. ContextForge is software you operate. Before first start you generate a JWT_SECRET_KEY and an AUTH_ENCRYPTION_SECRET, and the full Compose stack runs PostgreSQL, Redis, three gateway replicas, and Nginx, per the README. The securing guide has you disable the Admin UI and Admin API in production, so day-to-day administration moves to the REST API. Upgrades, backups, and patching are yours, and because only the latest release is supported, staying current is part of the job. In exchange you get full control over where the gateway runs and what data leaves your network.

Speakeasy operates the gateway, the database, and upgrades. The trade-off is that prompts, tool calls, and session context pass through Speakeasy's infrastructure. If policy says they cannot, Speakeasy is not an option, and ContextForge or another self-hosted gateway is the right starting point.

Many requirements that sound like self-hosting are about exposure: no public listener on the gateway, and internal MCP servers that never face the internet. Speakeasy meets those two separately. Tailscale private access requires an Enterprise organization. It gives hosted MCP servers and gateways URLs on your tailnet, and each server can be set to public only, public and private, or private only. Private only closes the public route with no automatic fallback, so if the tailnet goes down those servers stay unavailable until private access returns or an administrator switches them back. The Tailscale route covers how MCP clients reach the gateway; it does not make the Speakeasy dashboard or management APIs private. For the other direction, tunneled MCP servers open one outbound connection from your network, so a private server needs no inbound firewall rule. Our private MCP gateway guide covers how these differ from self-hosting and when each one satisfies a security review.

How does each gateway follow your identity provider?

Both products sign people in through your identity provider. ContextForge's SSO guide supports GitHub, Google, IBM Security Verify, Microsoft Entra ID, Keycloak, Okta, and generic OIDC, verifies OIDC ID token signatures against the provider's keys, creates users on first login, and maps IdP groups to ContextForge teams. That covers sign-in well.

The difference is what happens between logins. ContextForge's documented path for directory sync is one provisioning API call per user, which the docs describe as "not atomic bulk provisioning, an upsert API, or SCIM synchronization." A repeat call for an existing email returns 409 and leaves the account unchanged, so deactivating someone is a separate PATCH. With role sync enabled, teams are re-derived from token claims on each provisioning pass, and the docs warn under identity caching that ContextForge cannot revoke an external IdP token early. Deactivating the local account does take effect on the next request. Offboarding is therefore a job you script against the API, and its timing depends on your script and on token lifetimes at the IdP.

Speakeasy's Directory Sync receives SCIM pushes from the directory continuously. Roles come from IdP group mappings, and role membership becomes read-only in the dashboard, marked as managed by directory sync. Removing, deleting, or suspending a person in the identity provider ends their membership and role assignments right away, without a script. For Okta, Enterprise Managed Auth, in preview, lets a person sign in once with Okta and reach every MCP server set up for them without a separate OAuth prompt per service, using Cross App Access. The Okta API connection uses read-only scopes and never writes to your Okta org. See the Okta gateway use case for the full picture.

Can you grant one tool without granting the whole server?

ContextForge has two layers, described in its RBAC guide. Token scoping decides which resources a caller can see, using each resource's visibility (public, team, or private). RBAC then decides which actions the caller can take, with permissions such as tools.read and tools.execute. Those permissions name an action across resources the caller can see, not a particular tool. To give a team three tools from a twenty-tool server, you build a virtual server containing those three tools and scope it to the team. That works, and it keeps the boundary explicit, but each distinct tool set becomes another virtual server to maintain. ContextForge's security features page lists attribute-based access control, policy-as-code beyond the optional OPA plugin, and tool-level capability grants in token scopes as in progress.

Speakeasy grants at the tool level inside a role. In the role editor, each MCP permission narrows to all servers, specific projects, specific servers, or specific tools. Remote and tunneled servers can be permissioned by tool name once their tool metadata has been recorded. Every grant scope has a blocking counterpart, such as mcp:blocked_connect, which withdraws access for the matching resources even when another role grants it, so excluding one group from a destructive tool does not mean editing every role. The same rules show up on each server's Team Access tab, and because roles come from directory groups, a tool grant follows the person when their group changes. For narrowing what a client loads rather than what it may call, tag-based tool filtering serves a subset of a server's tools.

What about AI clients that never touch the gateway?

A gateway governs the traffic routed to it. The hard case is the coding agent or desktop assistant an employee installs and connects to MCP servers directly. ContextForge's own selection guide lists shadow MCP servers as a tier-one MCP threat and recommends "automated discovery and shadow server detection" for server sprawl. Its answer to tool shadowing is a centralized registry where agents discover only vetted tools. That works for clients pointed at ContextForge; the docs do not describe a way to inventory clients or servers on employee machines that bypass the gateway.

Speakeasy's Shadow AI is generally available under Guardrails for every organization. The device agent reports the coding harnesses, assistants, and local models on enrolled machines, and an admin marks each MCP-speaking tool Approved or Blocked. A Blocked tool is refused when it authenticates, on every MCP server in the organization. The MCPs tab inventories shadow MCP servers seen in agent traffic, and a blocking policy can allow or block by default with per-server exceptions.

Shadow AI has documented limits. A tool on an unenrolled machine appears nowhere. A decision is enforced only for tools that publish a client ID metadata document, which is how the gateway recognizes them. For a tool with no MCP client of its own, the decision is recorded and not enforced. Coverage is as complete as your device enrollment.

Who holds the upstream credential?

On this dimension the two products are close. ContextForge configures OAuth per gateway, with client credentials for service integrations and authorization code for user delegation, and encrypts stored client secrets. Its security features page documents a HashiCorp Vault backend for per-user access and refresh tokens, isolated per team, server, and user. Identity propagation, off by default, forwards the caller's email, teams, and roles to upstream servers as headers or metadata, with optional HMAC signing. If you already run Vault, ContextForge fits into it directly.

Speakeasy offers the same two models on each server, described in upstream credentials. With a credential per end user, the platform holds an access and refresh token for each person, encrypted at rest and refreshed silently, so a Linear tool call runs as that person in Linear. With one credential for the whole server, a static key or a client-credentials token is used for every caller, and you can share a remote MCP server with a static credential. Who may call the server stays a separate decision on its Team Access tab. Where Okta Cross App Access is configured, the per-user token comes from Okta instead of a separate consent screen for each service.

What does the audit trail record?

ContextForge writes several audit sources to its database, per its security features page. PermissionAuditLog records permission and role activity, TokenUsageLog records each API token's use by its JWT ID, and EmailAuthEvent records logins and password changes with IP and user agent. Security event logging for authentication and authorization failures is disabled by default for performance, and the same page lists tamper-resistant, immutable audit trails as under evaluation. The page recommends shipping these logs to a SIEM, which is where cross-source investigation happens. You choose the retention and the storage.

Speakeasy's Audit Logs are one organization-wide feed of administrative activity. Each entry has a resource:action badge, the actor, a description, a diff where data changed, and the surface the change came from: the dashboard, an API key, the Platform MCP, or the Project assistant. Filters cover project, action, actor, and surface, and an Audit Log Insights assistant answers questions over the feed. MCP session revocations and transcript opens are logged too. Reading other members' session transcripts takes the chat:read scope, which no default role includes, Admin included. Tool calls themselves appear in Tool Logs. With ContextForge you choose the schema, storage, and retention and build the investigation view in your SIEM; with Speakeasy the feed exists on day one, and Speakeasy sets its schema and retention.

When to choose IBM ContextForge

• The gateway must run in your infrastructure. If prompts, tool calls, or session context cannot pass through a third party, or you need on-premises or air-gapped operation, ContextForge runs where you put it. Speakeasy is managed only.
• You need to federate more than MCP. A2A agents, REST services, and gRPC services through reflection all become tools behind one endpoint.
• You want source access and no license fee. ContextForge is Apache 2.0 with no open-core split, and you can change the code. IBM Elite Support is available if you need an SLA.
• Your platform team already runs Kubernetes, PostgreSQL, Redis, and Vault. ContextForge composes with that stack, and its plugin framework lets you add guardrails and OPA policy in-process.

When to choose Speakeasy

• Access has to follow the directory without scripts. SCIM Directory Sync maps groups to roles and deprovisions people as soon as the IdP does.
• Grants need to be per tool, not per server. Roles narrow to specific tools, and blocking rules override grants from other roles.
• You need to govern AI clients outside the gateway. Shadow AI inventories enrolled devices and refuses Blocked tools at the gateway.
• You would rather not operate the gateway. Speakeasy runs it. If private exposure is the requirement, an Enterprise organization can serve endpoints over Tailscale and reach private servers through tunnels.

Which one should you choose?

Choose ContextForge if your security policy requires that the gateway run on infrastructure you control, or if federating A2A, REST, and gRPC services is the main job. Choose Speakeasy if the main job is governing who can call which tool, from which client, with your identity provider as the source of truth, and a managed gateway with private network access is acceptable. If you are evaluating both, test the offboarding path first: remove a test user from a group in your IdP and time how long each gateway takes to stop their next tool call.