In Depth: Speakeasy vs Bifrost

Speakeasy and Bifrost both sit on the path between AI agents and the systems those agents reach, and both sell an MCP gateway. They are built around different jobs. Bifrost, by Maxim AI, is an open-source AI gateway: a Go runtime that unifies 20+ model providers behind one OpenAI-compatible API, with failover, load balancing, semantic caching, and an MCP gateway inside the same process. Speakeasy is an AI Control Plane built for runtime agent governance: a hybrid MCP gateway anchored in enterprise identity, plus agent hooks that enforce policy on the prompts, shell commands, file edits, and local tool calls inside the agent session that no gateway ever sees.

In the architecture buckets from our MCP gateway chooser, Bifrost's MCP gateway is routing infrastructure with governance features layered on, packaged inside a broader LLM gateway. Speakeasy is the hybrid: a governance gateway that also generates and hosts the servers being governed. This post walks the overlap and the gaps: architecture first, then identity, security, governance, and spend, and closes with the questions that decide the choice.

What is Bifrost?

Bifrost is an AI gateway built by Maxim AI and open-sourced under the Apache 2.0 license at github.com/maximhq/bifrost. The core product is model routing: applications point their OpenAI, Anthropic, or other SDK at a Bifrost base URL, and the gateway routes each request across 20+ providers with automatic fallbacks, weighted load balancing, and semantic caching. Performance is the headline. Bifrost publishes benchmarks claiming 11 µs of added overhead per request at 5,000 requests per second on an AWS t3.xlarge against mocked provider calls, and markets itself as 50x faster than LiteLLM at P99 latency on identical hardware. Those are Bifrost's numbers, not figures we have verified.

The governance entity is the virtual key: a Bifrost-issued credential that carries access permissions, hierarchical budgets and rate limits across keys, teams, and customers, routing rules, and per-key MCP tool allow-lists. The MCP gateway runs in the same process: Bifrost acts as an MCP client to upstream servers over STDIO, HTTP, or SSE, and as an MCP server that exposes the aggregated tools at a single /mcp endpoint to clients such as Claude Desktop and Cursor. Upstream server auth spans six types, including per-user OAuth and token exchange, and Code Mode has the model write Python to orchestrate tools, which Bifrost says cuts input tokens by up to 92.8%.

A licensed Enterprise tier adds OIDC SSO and SCIM provisioning from Okta, Entra ID, Keycloak, Zitadel, Google Workspace, and Auth0, access profiles that auto-allocate virtual keys to directory users, RBAC, signed audit logs, guardrails with a native LLM judge, Gitleaks-backed secrets detection, and integrations for Presidio, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Gray Swan, Patronus, Check Point, and Repello, plus clustering and in-VPC, on-premise, and air-gapped deployment. A separate endpoint product, Bifrost Edge, is in alpha: it runs on macOS, Windows, and Linux machines, routes AI traffic from chat apps, browsers, and coding agents through Bifrost, and inventories and allows or denies MCP servers across a fleet, deployed through Jamf, Intune, or Kandji.

What is the Speakeasy AI Control Plane?

Speakeasy is an AI Control Plane anchored in enterprise identity, with enforcement on two layers.

The MCP gateway authenticates every session with OAuth 2.1, dynamic client registration, and PKCE, checks per-server and per-tool grants on each call, scans requests and responses inline, and logs every call. Sessions authenticate through your identity provider, so each call resolves to a principal synced from Okta or Microsoft Entra ID through directory sync, and one permission model covers people and Agent Identities (in early access). Custom MCP servers are generated from the API contract a team already maintains.

Agent hooks are the second layer. Inside Claude Code, Claude Cowork, Cursor, Codex, and OpenCode, a hook sits between the agent deciding to act and the action executing: it sees the prompt as it is submitted, the shell command before it runs, the file edit before it lands, and the tool call before it goes out, whether or not that call was ever pointed at a gateway. The device agent deploys those hooks through an MDM such as Jamf, Kandji, or Intune and reconciles them on macOS, Windows, and Linux every 60 seconds. The platform holds SOC 2 Type II and ISO 27001, per the security page.

Speakeasy does not route LLM traffic. There is no multi-provider model router, no failover between providers, and no semantic cache; a LiteLLM integration adds a pre-call guardrail for teams that already route model traffic through LiteLLM. If the job is an LLM router bake-off, Speakeasy is not in the race, and this post is not scored as one.

Speakeasy vs Bifrost at a glance

The first rows are the jobs where one product simply does not compete with the other. The rest is the MCP gateway overlap, where the useful comparison is what each product enforces and against whose identity.

What does an AI gateway govern, and what does it miss?

Bifrost's enforcement point is its own URL, twice over. Model traffic is governed because the application's SDK points at Bifrost instead of the provider, and MCP traffic is governed because the client points at /mcp instead of the tool server. Everything routed that way gets a virtual key check, tool filtering, guardrails on the Enterprise tier, and a log line. For the traffic it sees, that is a real control, and because Bifrost fronts the model call itself, it can enforce things Speakeasy cannot, such as provider failover and token-level budget enforcement on inference.

The limit is the same routing condition every gateway has. Most of what happens in a coding agent session is not a call to a gateway URL. In a typical Claude Code or Cursor session, the agent reads a prompt that may contain a pasted credential, runs shell commands such as git push --force or a psql against production, edits the config files that add new MCP servers to the agent itself, and calls local stdio MCP servers launched with npx on the developer's machine. None of that routes through a base URL, so none of it is visible to an AI gateway. Bifrost's answer is Edge, an endpoint agent that intercepts and re-routes AI traffic from apps, browsers, and coding agents through Bifrost and inventories the MCP servers configured across a fleet. It is a credible design, and it is in alpha as of September 2026.

Speakeasy's answer is hooks inside the agent loop. Claude Code, Cursor, Codex, and their peers expose lifecycle events such as UserPromptSubmit and PreToolUse, and Speakeasy ships managed handlers for them, kept in place by the MDM-deployed device agent. The same risk policies that run at the gateway run inside the session: prompt injection detection, sensitive-data detectors across prompts, tool calls, and responses, destructive-command detection before execution, shadow MCP detection with an allow-or-block posture and a request-access flow, and budgets that block per person. A hook does not depend on traffic being re-routed; it fires where the action originates.

How does identity differ on a tool call?

Both products can put your identity provider in the loop. The useful comparison is what a single tool call carries when policy is evaluated.

On Bifrost, the unit of access is the virtual key. A client presents x-bf-vk or a bearer token at /mcp, and the key determines which MCP clients and tools the call may reach, per its tool filtering allow-lists. On the Enterprise tier, OIDC SSO with SCIM brings directory users, teams, and roles into Bifrost, access profiles auto-allocate scoped virtual keys to those users, and gateway auth supports a browser-based OAuth flow so a session can belong to an SSO user. Upstream, per-user OAuth and token exchange can carry a caller-specific credential to the tool server, which is a genuinely strong part of the design.

On Speakeasy, the session is the directory principal from the first call. The authorization handshake sends the client through your identity provider, grants evaluate against that principal on every call with the tool's disposition read from its MCP annotations, deny beats allow, and each call is stamped with the caller's groups, attributes, and roles at that moment. Agent Identity, in early access, gives agents a principal of their own under the same model, and extending IAM to agents explains why we anchored there.

For an auditor, "who did this" resolves on Bifrost to a virtual key and, with Enterprise SSO, the user it was allocated to. On Speakeasy it resolves to the directory principal itself, with the directory snapshot attached to the call.

How do the security and governance capabilities compare?

At the gateway, the two products converge more than the architecture difference suggests. Both scan traffic in flight and both let you write custom policy.

Bifrost Enterprise's guardrails run on LLM and MCP inputs and outputs: prompt guardrails enforce natural-language policies through a configured LLM judge, secrets detection is backed by Gitleaks, custom regex covers organization-specific patterns including a PII template, and a wide external catalog (Presidio, Azure AI Language PII, AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor, CrowdStrike AIDR, Gray Swan Cygnal, Patronus, Check Point, Repello) plugs the classifier your security team already runs into the same path, with configurable redaction. Alerting is CEL-based over governance metrics, and audit logs are signed and exportable.

Speakeasy runs its own detector catalog (secrets, financial data, PII, government and healthcare identifiers) across prompts, assistant messages, tool calls, and tool responses, adds a prompt injection heuristic with an opt-in LLM judge, and offers two authoring surfaces Bifrost does not document: natural-language guardrails that replay against recent live sessions to produce a scorecard before enforcement, and custom detection rules as CEL expressions. The larger difference is where policy applies. A Speakeasy grant or risk policy written once enforces at the gateway and inside the coding agent session, on traffic that never routed anywhere. Bifrost's guardrails and tool allow-lists apply to traffic that reached Bifrost.

On bringing tools under governance, Bifrost aggregates existing MCP servers and can bundle them into Virtual MCPs assigned to virtual keys, and tool hosting registers custom Go tools in the process. Speakeasy generates governed MCP servers from the OpenAPI contract your teams already maintain, proxies any remote server by URL, and draws its catalog from the official MCP Registry, so internal APIs come under governance without anyone writing a server.

How do spend visibility and cost control compare?

This is the cleanest illustration of the two architectures, because both products enforce budgets and they meter different things.

Bifrost meters inference. Budgets and rate limits attach to virtual keys and roll up hierarchically through teams and customers, enforcement happens at the gateway before the provider is called, model-level limits narrow further, and semantic caching cuts the bill outright. If your AI spend problem is "which team is burning tokens against which provider," Bifrost answers it at the point the tokens are spent, on every request routed through it.

Speakeasy meters people. Hooks record every turn in the instrumented coding agents, the costs view cuts spend by employee, role, model, and cost center from directory attributes, budgets warn at 80% and block in Claude Code, Codex, and Cursor, and provider compliance imports pull claude.ai, ChatGPT, and Codex activity from provider APIs, so spend that never touched any gateway still shows up, including personal-account sessions. If the question is "which person exceeded their budget in a coding agent, on which account," that is the Speakeasy shape.

When should you pick Bifrost?

• You need a multi-provider LLM gateway. Failover, load balancing, semantic caching, and an OpenAI-compatible API are Bifrost's core product, and Speakeasy does not offer them.
• Open source and self-hosting are requirements. Bifrost is Apache 2.0 and runs in your infrastructure, with in-VPC, on-premise, and air-gapped options on the Enterprise tier. Speakeasy is a hosted platform.
• Gateway latency at high request rates is a hard requirement, and Bifrost's published benchmarks match your own testing.
• Cost control should live at the credential and inference layer, with hierarchical budgets across keys, teams, and customers enforced before the provider is called.
• Your security team already runs an external guardrail classifier such as Bedrock Guardrails, Model Armor, or Presidio and wants LLM and MCP traffic screened by it through Bifrost's integrations.

When should you pick Speakeasy?

• Governance has to cover the whole agent session: prompts, shell commands, file edits, and the MCP servers developers configured directly in their editors, enforced today rather than through an alpha endpoint product.
• Every tool call must resolve to a directory principal, with grants evaluated against groups and attributes at call time and agent identity living in the identity provider you already run.
• Your most important tools sit behind your own APIs, and you want governed MCP servers generated from the contracts your teams maintain.
• Policy authoring should not require operating infrastructure: natural-language guardrails with replay scorecards and CEL rules, written in the platform, applied at the gateway and in the session from one definition.
• Cost needs to follow the org chart, with per-person budgets enforced inside the coding agents and visibility into personal-account usage no gateway sees.

The questions a CISO should ask both vendors

• What happens when a developer runs git push --force or pipes a secret into curl? On Speakeasy a hook blocks it before execution. On Bifrost the command never reaches the gateway; ask what Edge will cover at general availability.
• What identity does a single MCP tool call carry? On Bifrost, a virtual key, with SSO users behind it on Enterprise. On Speakeasy, a directory principal with its group and attribute snapshot. Ask to see the credential on a live call.
• Can a policy be written once and enforced both at the gateway and inside the coding agent session? Speakeasy's grants and risk policies apply on both layers. Bifrost enforces on traffic routed through Bifrost.
• Do you need LLM routing at all? If provider failover and token spend are the problem, Bifrost solves it directly and Speakeasy does not. If agent actions and tool access are the problem, the router is not the control.
• How is a new guardrail validated before it blocks production traffic? Speakeasy replays natural-language guardrails against recent sessions and produces a scorecard. Ask Bifrost how a new guardrail profile is staged.
• Where must the platform run? If the answer includes on-premise or air-gapped, Bifrost ships it and Speakeasy does not.

Where the Speakeasy AI Control Plane fits

Bifrost has built a serious open-source AI gateway, and if provider routing, failover, and inference cost control are the problem in front of you, it is a strong answer. The Speakeasy AI Control Plane is built for the problem that starts after the model responds: what the agent does with its answer, which tools it calls, as whom, and under whose policy. It runs an MCP gateway with directory identity on every call, generates governed servers from your API contracts, and puts hooks inside the coding agents your teams already use, so one policy covers the prompts, commands, and tool calls no gateway URL ever sees. If your evaluation starts from agent governance rather than model routing, that is the product to test first.