In Depth: Speakeasy vs Willow

Speakeasy and Willow both offer products for AI governance and enablement. Willow, which rebranded from Webrix in 2026, is an MCP gateway with a piecemeal enablement layer around it: a connector marketplace, endpoint sensors, and a browser extension. Speakeasy is an AI Control Plane with a two-layer architecture for agent identity, governance, and security. Agent hooks govern the prompts, shell commands, file edits, and local tool calls that never leave the agent loop, and an MCP gateway adds a second layer of control for agents accessing data.

The gateway layer is where the products overlap, and this post walks that overlap line by line. The hooks layer is where they part: Willow has no hooks architecture, so anything in an agent session that does not route through its gateway URL is outside its enforcement. The post covers architecture, then security, governance, and spend, and closes with the questions that decide the choice.

What is Willow?

Willow is an MCP gateway and enablement platform founded by former Wix engineers Eyal Ben Ezra, Shalev Shalit, and Idan Chetrit and backed by a $7M seed round led by Hetz Ventures. It calls itself an Agentic Access Platform and describes the product as a Basecamp where agents check in, receive an identity, and pick up tools scoped to their task, per its llm-info page.

The gateway is the product. Clients are configured with a Willow MCP URL instead of a direct tool URL, and every call routed through it passes four checks: identity, group-based access to the target server, runtime guards on request content, and response guards that mask PII on the way back. Around the gateway sit a marketplace of skills and plugins, a claimed library of 1,000+ pre-built connectors, endpoint sensors that surface unapproved tools and shadow MCP servers, Willow for Chrome as a browser policy layer, and an org-wide kill switch. It deploys as SaaS, self-hosted on AWS, GCP, or Azure, or on-prem and air-gapped, per the governance and compliance page.

The reference customer is Wix. Willow's case study reports roughly 5,000 weekly active users, nearly 600 governed tools, and more than 300,000 governed tool calls per week. Those are Willow's published numbers, not figures we have verified.

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 does the same job as Willow's. It 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. The difference at the gateway is identity: 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).

Agent hooks are the layer Willow does not have. 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, so coverage comes with enrollment rather than per-developer opt-in. Custom MCP servers are generated from the API contract a team already maintains, and the platform holds SOC 2 Type II and ISO 27001, per the security page.

Speakeasy vs Willow at a glance

The first block of rows is the gateway job, where both products cover the same ground. The second is the rest of the agent session, where Willow observes at best and Speakeasy enforces.

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

An MCP gateway is a URL. The agent is configured to call it instead of the tool, the gateway checks the call and forwards it, and everything that passes through gets identity, policy, and a log line. Willow's docs describe the model precisely: every call routed through the Willow MCP URL is checked for identity, group access, and content. That is a complete control for the traffic it sees.

The limit is the routing condition. Most of what happens in a coding agent session is not an MCP call to a hosted server. In a typical Claude Code or Cursor session, the agent:

• Reads a prompt that may contain a pasted API key or a customer record.
• Runs shell commands such as git push --force, rm -rf, or a psql against production.
• Edits files, including the config files that add new MCP servers or skills to the agent itself.
• Calls local stdio MCP servers launched with npx or uvx on the developer's machine.
• Calls remote MCP servers the developer configured directly in the editor.
• Sends the whole context to a model provider, sometimes under a personal account.

None of those is a call to a gateway URL, so none is visible to a gateway. Willow covers the gap from the outside: endpoint sensors inventory the unapproved tools, skills, and MCP servers installed on a machine, and Willow for Chrome applies policy in the browser. Sensors tell an admin an ungoverned server exists so it can be brought onto the gateway. They do not sit in the agent loop, so they cannot stop the shell command, scan the prompt, or block the call to the server they found.

How do agent hooks extend governance past the gateway?

Hooks are the primitive the coding agents converged on for this gap. Claude Code, Cursor, Codex, and VS Code Copilot each expose lifecycle events such as UserPromptSubmit and PreToolUse, hand the handler structured JSON about what is about to happen, and act on its decision to allow, deny, or modify. A hook runs inside the agent loop, with no proxy to route through. The AI agent hooks reference covers the event surface per client.

Speakeasy ships those hooks as managed configuration for Claude Code, Claude Cowork, Cursor, Codex, and OpenCode, and the device agent keeps them installed through MDM. With hooks in place, the same risk policies that run at the gateway run inside the session:

• A prompt injection heuristic, with an opt-in LLM judge, on prompts and tool outputs.
• Sensitive-data detectors for secrets, financial data, PII, government identifiers, and healthcare identifiers across prompts, assistant messages, tool calls, and tool responses.
• Destructive-command detection for rm -rf, git push --force, and DROP TABLE before they run.
• Shadow MCP detection built from the servers employees actually call, with an allow-or-block posture and a request-access flow.
• Budgets that meter every turn and block in Claude Code, Codex, and Cursor at a per-person limit keyed on department or cost center.

Whether hooks fail open or fail closed when the control plane is unreachable is an organization-level setting, and blocking is the default.

How does identity differ at the gateway?

Both products integrate with Okta and Entra ID. The useful comparison is what a single tool call carries when it reaches the gateway.

On Willow, the gateway is its own authorization server. Its developer documentation states that the gateway mints and validates its own tokens, that SSO providers sit upstream of it, and that an upstream identity provider's token presented at the /mcp endpoint does not authenticate. Callers present a Willow-minted OAuth token or a wxt_-prefixed API key in the MCP URL, the gateway matches it to a user record, and access follows from Willow group assignments. Machine users authenticate with a static key and secret pair. SCIM provisioning removes access at offboarding, so the directory decides who can log in, and Willow's groups decide what they can call.

On Speakeasy, the authorization handshake sends the client through your identity provider, so the session belongs to a directory principal from the first call. Grants evaluate against that principal on every call, roles map from directory groups, 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. Extending IAM to agents explains why we anchored there.

For an auditor, "who did this" resolves to a Willow user record on Willow and to the directory principal itself on Speakeasy.

How do the security capabilities compare?

At the gateway, both products inspect traffic and act on it. Willow's runtime guards stop a request or strip flagged content, response guards mask sensitive output before the agent sees it, sensitive actions can require Slack sign-off, and build-and-runtime guards apply policy when a tool is generated as well as when it runs.

Speakeasy runs its detectors on both layers. Two authoring models have no published Willow equivalent: natural-language guardrails that replay against recent sessions to produce a scorecard before enforcement, and custom detection rules written as CEL expressions. Shadow discovery is traffic-sourced rather than sensor-sourced, so the inventory is of servers in use, and blocking happens at the hook.

Where Willow is ahead: the browser is a governed surface, endpoint sensors inventory what is installed rather than only what is used, and the platform can run air-gapped. Speakeasy offers none of those. Where Speakeasy is ahead: enforcement inside the agent loop, a wider detector catalog with replayable authoring, and push-based export through webhooks and OTEL.

How do the governance capabilities compare?

Willow's permission model is groups inside Willow. A user record maps to groups, groups map to assigned MCP servers, and app-aware permissions scope what an agent can do inside each tool. SCIM keeps user records aligned with the directory, and machine users give bots service-account-style credentials that live in Willow.

Speakeasy's permission model is the directory itself. Grants pair scopes with resource selectors and evaluate against the directory principal on every call, with each tool's disposition read from its MCP annotations. A support role can connect to a billing server, succeed on a read-only tool, and be denied on a destructive one with no change to the server. Every denied call opens into the grant that would allow it, and because hooks enforce the same grants inside the coding agent, a policy written once applies to gateway traffic and the local session alike.

How do spend visibility and cost control compare?

Willow frames spend as return on AI investment. Per its llm-info page, token optimization serves agents only the tools a task needs, adoption tracking shows which teams and use cases are live, and logs record token counts per gateway call.

Speakeasy frames it as attribution and enforcement, and hooks make the enforcement possible. The costs view breaks spend down by employee, role, model, agent, and client, and cuts by department or cost center from directory attributes. Budgets warn at 80% and block in Claude Code, Codex, and Cursor. Provider compliance imports pull claude.ai, ChatGPT, and Codex activity from the Anthropic Compliance API, OpenAI Compliance Logs, and the Cursor Admin API, and personal account visibility flags sessions from personal accounts, so spend that never touched a gateway still shows up. Willow does not document per-person budget enforcement or provider imports; Speakeasy does not offer token optimization at the tool-serving layer.

When should you pick Willow?

• Enablement is the bottleneck, and a marketplace of 1,000+ connectors covers the tools your employees need on day one.
• The browser is a primary AI surface for your workforce, and Willow for Chrome blocking risky actions there matters.
• You need an inventory of what is installed on endpoints, not only what shows up in agent traffic.
• You require self-hosted, on-prem, or air-gapped deployment, which Willow offers and Speakeasy does not.
• An instant org-wide kill switch is on the requirements list.

When should you pick Speakeasy?

• Governance has to cover the whole agent session: prompts, shell commands, file edits, and the servers developers configured directly in their editors.
• One policy should apply on both layers, so a grant written for the gateway also enforces inside Claude Code, Claude Cowork, Cursor, Codex, and OpenCode.
• Agent identity must live in the identity provider you already run, with every tool call authorized against a directory principal.
• Your most important tools sit behind your own APIs, and you want governed servers generated from the contracts your teams maintain.
• Cost needs to follow the org chart, with per-person budgets enforced in the coding agent 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 Willow the command never reaches the gateway, so ask what the product does instead.
• What happens to an MCP server configured directly in the editor? Willow's sensors surface it. Speakeasy's hooks block or allow the calls to it under policy. Decide whether discovery is enough.
• How does coverage reach every laptop? Speakeasy deploys hooks through your MDM and reconciles them every 60 seconds. Ask Willow how the gateway URL and sensors get installed and kept in place.
• What does a single tool call carry as its identity? On Willow, a gateway-minted token resolving to a Willow user record. On Speakeasy, a session authorized through your IdP resolving to a directory principal. Ask to see the credential on a live call.
• Can you replay a policy before you enforce it? Speakeasy replays natural-language guardrails against recent sessions and produces a scorecard. Ask Willow how a new guard is validated before it starts blocking.
• Where must the platform run? If the answer includes on-prem or air-gapped, Willow ships it and Speakeasy does not.

Where the Speakeasy AI Control Plane fits

Willow has built a solid MCP gateway, and the Wix deployment shows its self-serve model working at scale. The Speakeasy AI Control Plane runs the same gateway with directory identity on every call, then adds hooks inside the coding agents your teams already use, deployed through the MDM you already run, so one policy covers the prompts, commands, and tool calls a gateway never sees. If your evaluation starts from what happens in the session that never touches the gateway, that is the product to test first.