Speakeasy vs Runlayer: Which AI control plane fits your enterprise?

When an engineer loses a refund permission, should the agent they own lose it too? Speakeasy removes it on the agent's next request, while a Runlayer agent on a machine-to-machine token keeps it, because the token ignores the owner's permissions.

Choose Speakeasy when tool access, agent permissions, and AI budgets should follow the identity provider you already run. Below, we compare the two on each of those, then on guardrail testing and Linux controls.

MoonPay rolled out Speakeasy company-wide after a 30-day proof of concept. It now governs more than 200 MCP servers and 60,000 agent sessions, with Okta-backed permissions by team, server, and tool and unsanctioned servers blocked by default. Read the MoonPay case study.

Speakeasy vs Runlayer comparison

Enterprise readiness and track record

Speakeasy's gateway runs in production at companies with large, security-sensitive MCP estates. MoonPay's security operations team describes the change directly:

"Employees were connecting MCP servers we had no inventory of. Now every server runs behind the gateway, scoped by team and role, and anything unsanctioned is blocked by default."

Thierry Dang, Security Operations, MoonPay

Google, Fivetran, PlanetScale, LaunchDarkly, and Polar run MCP servers built on Speakeasy:

• Google moved the Gemini API SDKs to Speakeasy after its previous generation vendor was acquired and shut down, then built the Gemini Docs MCP server with Speakeasy on the same foundation. Google chose Speakeasy for continuity, based on Speakeasy's commitment to open-source its generators so the tooling behind Gemini's SDKs and MCP server could not disappear again. The Docs MCP server gives coding agents current Gemini API documentation instead of stale training data and ships pre-bundled in Antigravity.
• Fivetran exposed its Connector SDK and platform APIs as a hosted MCP server without spending weeks on infrastructure, an OAuth server, and client compatibility testing. Fivetran's Eli Davis calls Speakeasy's AI control plane "indispensable in enabling Fivetran's AI transformation."
• PlanetScale grew usage of its MCP server 44 times over in five months.
• LaunchDarkly built an MCP server that lets agents create feature flags, configure targeting rules, and manage rollouts.
• Polar moved from a local MCP server to a hosted one that turns a plain-language pricing description into a working billing setup.

Support is measured against service-level commitments rather than best effort. Speakeasy has met every response-time commitment across its support tiers, and 90% of support requests are answered in under 24 minutes.

Why choose Speakeasy as your AI control plane over Runlayer?

Distribute approved tools by role

Both platforms can permit an MCP server an employee discovered without first migrating it to a managed connector. Runlayer's Enforce policy offers one-click allowlisting for discovered remote URLs and local packages launched through recognized package runners. Local entries match the package name and, optionally, a pinned version; they do not verify the package's contents.

Speakeasy's advantage is the access review around that decision. Reviewers see who uses the server, its declared tools and requested OAuth scopes, domain and registry history, and published advisories. An approval names the people or roles it covers and records a rationale with the evidence snapshot. Blocking policies continue to stop users outside that audience. The evidence informs the decision; it is not a certification that the server's code is safe.

Approval is not the end of the review. Speakeasy rechecks approved servers daily and flags permission-relevant changes, such as new tools, broader scopes, or changed authentication, for a new decision. A blocked employee can request access from the tool's error message or the device agent's notification. The request joins the existing review rather than creating a second, disconnected approval trail.

To distribute managed servers, Speakeasy adds them to role-assigned plugins. Once the marketplace and client setup are complete, publication keeps those bundles current; the device agent applies assignments on enrolled machines. Marketplace installation itself is not restricted by plugin assignments, and server permissions still decide what an installer can call. ChatGPT requires its own workspace-admin installation policy. Runlayer also supports centrally deployed CLI configuration sync, with managed skill sync available across macOS, Windows, and Linux.

For internal APIs, Speakeasy generates an MCP server from the OpenAPI document your team already maintains, while Runlayer needs server code scaffolded with MCP Builder and hosted as a container by Runlayer Deploy.

Bound agent authority by its owner's permissions

In Speakeasy, an agent can't do more than its owner is currently allowed to do. Every request has to pass three checks in Speakeasy's agent identity model: the credential's fixed ceiling, the agent's own policy, and the owner's current permissions. A Runlayer agent on an M2M token is limited only by its account's own policies.

If a reconciliation agent's owner loses refund permission, the Speakeasy agent loses refunds on its next request, even though its own policy and credential still allow them. The Runlayer agent keeps its refund access. If the owner leaves or is deactivated, the Speakeasy agent is blocked until someone reassigns it.

Runlayer does combine permissions for delegated calls, where an on-behalf-of token applies both the agent's and the delegating user's policies. Speakeasy applies the owner's limit to every request without switching the agent into a delegated mode.

Grant a tool without widening access to the server

An employee may need invoice lookup but not refunds. Speakeasy's permission model checks server connection access and then the requested tool. Grants can name tools or constrain their disposition, such as read-only or destructive; an explicit deny overrides overlapping allows. For remote servers, administrators can record tool annotations instead of trusting a vendor to keep its declarations unchanged.

Runlayer also authorizes individual tools. Its runtime conditions can inspect tool arguments, IP and client metadata, OAuth scopes, annotations, and session history. One policy can permit access to the first repository named in a session and deny a different repository later. Its beta Terraform provider manages access policies and scanner settings as code. That is a useful option for teams maintaining gateway policy alongside infrastructure.

Speakeasy makes the directory grant and its resolution central to the workflow. Where Authorization Challenges are enabled, a denied call records the caller, resource, and missing permission. An administrator opens the challenge and adds that permission to a role instead of broadening the whole server's audience. Runlayer's conditions are useful for exact argument restrictions; Speakeasy pairs identity-bound grants with separately authored content and contextual guardrails.

Test security policies against real sessions

Speakeasy lets a security team write a guardrail for a risk specific to their business and test it against past sessions before enforcing it. Runlayer's scanners are built in, and to see what AgentGuard would do, you run it in Alert mode on new sessions.

A finance team may need to flag refunds without prior authorization, and an engineering team may need to catch production deletes while allowing cleanup in test environments. In Speakeasy, the security team writes that rule in plain language as a prompt-based guardrail. Runlayer's topic scanning sorts sessions into fixed task categories, and its access policies match on arguments, network metadata, OAuth state, annotations, and session history.

Before rollout, Speakeasy replays the guardrail against recent sessions, shows each verdict with its confidence and rationale, and keeps a right-or-wrong scorecard as the wording changes. Runlayer's replay feature, Agent Evals, compares model and prompt changes on past hosted-agent runs.

When a guardrail fires, Speakeasy can quarantine the session, freezing its prompts and tool calls until an administrator releases it. Runlayer's AgentGuard blocks later tool calls in the session, and ending the session takes a separate setting tied to per-call scanner blocks.

Inspect definitions, returned content, and intent

A poisoned tool description, a hostile tool result, and a tool doing something other than the user requested are different threats. Runlayer's ToolGuard separates them: Tool List Guard inspects names, descriptions, and schemas at registration or re-scan; Tool Call Guard inspects execution outputs before model delivery; Tool Intent Guard analyzes inputs and outputs for semantic misalignment. AgentGuard separately monitors the session trajectory.

Runlayer's ML scanners can allow, alert, or block, with sensitivity configurable by connector or client. They default to Block. Its PII and credential scanners have additional masking actions; masking is not an action available to every ToolGuard scanner.

Speakeasy combines server evidence review with prompt-injection detection, custom rules, and contextual guardrails. A team can select the surface to inspect, target an audience, and test a business-specific rule against captured sessions. Runlayer's dedicated input/output intent-alignment scanner is a distinct capability. Speakeasy's strongest difference is that security teams can author and validate their own contextual policies in the same control plane that manages access and investigation.

Protect sensitive data at the right boundary

Speakeasy's built-in detectors cover secrets, financial information, personal identifiers, government IDs, and healthcare data. MCP-scoped policies, enabled per organization, inspect a tool request before the gateway forwards it and its result before returning it to the client. A matching Block policy rejects the request or withholds the result. Session policies additionally cover supported prompts, assistant messages, and local tool activity through hooks.

Runlayer's PII scanner supports built-in entity types and custom patterns, while credential scanning detects tokens and other secrets. PII defaults to Alert and credentials to Mask; teams can choose a different enforcement action. The useful comparison is not whether either product has a detector, but which data is scanned, where the check runs, and which action the team has configured.

Speakeasy's MCP-scoped checks inspect the first 50 KiB and allow a call through if it exceeds that limit or the scan cannot finish in time. Session prompt-based policies separately let an admin choose fail open or fail closed on judge errors. Destructive-tool, destructive-CLI, and non-corporate-account session detectors report completed activity rather than undoing it. Permission checks enforce the restrictions that must hold before execution; content policies add inspection at the selected boundary.

Separate approvals from permanent permissions

Allowing a tool and approving a particular risky action are different decisions. Runlayer's beta human-approval rules add a checkpoint on top of existing access, rather than granting access themselves. For hosted agents, a matching call pauses the run and sends the approver a Slack notification. Connector access requests and PII self-approval are separate workflows: the latter lets the caller approve and retry a PII-blocked request on a connector configured for it.

Speakeasy's session guardrails can log, require acknowledgement, deny, or quarantine. Acknowledgement has a grace period so an immediate retry does not repeat the challenge. Shadow-server access requests go through the evidence-backed review, where an exception can name people or roles and later be revoked. A quarantine holds subsequent prompts and tool calls until an administrator releases the session. MCP-scoped policies support logging and denial, not acknowledgement or quarantine, because a gateway call has no interactive confirmation step or session to freeze.

Keep client identity separate from backend credentials

Speakeasy acts as the OAuth authorization server for servers configured with user sessions. Clients use authorization-code sign-in with PKCE, while the gateway manages the credential needed by each upstream service. When proxying a remote server, Speakeasy strips the caller's authorization and browser headers before applying the upstream credential. A platform session token does not become the vendor API key.

That separation matters when one gateway endpoint combines several systems. Each upstream OAuth grant belongs to its member server; a token for one member is not forwarded to another. Administrators can also keep credentials under customer-managed AWS KMS or Google Cloud KMS keys rather than hand out long-lived secrets to agents.

Runlayer encrypts vendor access tokens, refresh tokens, and connector secrets before storage. Its agent tokens support resource audiences, but Enforce server scoping is opt-in per Agent Account, not automatic on every token. With that setting enabled, a call outside the token's audience is rejected. Speakeasy's owner-bound request checks address a different risk: a valid credential must not preserve authority its human owner has lost.

Beyond the gateway: enterprise AI governance

Reconstruct an incident without spreading the leaked data

A blocked call is only the start of an investigation. Speakeasy's Agent Sessions join the captured conversation to tool arguments and results, risk findings, tokens, and cost. An investigator can search a session, inspect the surrounding messages, and follow a finding to the relevant action. Transcript access requires its own permission, and opening one is audit-logged.

Watchdog groups repeated findings into ranked signals, with affected people and teams and redacted evidence. Revealing a sensitive match is audited. A recurring false positive can become an exclusion without removing the detector; a real exposure can lead to a tighter role grant, a blocked server, or a stronger policy. This connects detection to an administrative response rather than leaving security with a pile of tool-call logs.

Capture is deliberate: session transcripts and tool payload recording start off until an admin enables them. Stored tool logs and sessions have 90-day retention. Speakeasy's OTLP exports have separate routes for product telemetry, risk findings, and gateway tool-call logs; new destinations exclude sensitive content by default. An export of model telemetry alone is not a complete export of gateway calls.

Runlayer's audit log records tool calls, scanner outcomes, administrative changes, and access decisions, with conversations in its separate Sessions view. Its default hot audit window is also 90 days, followed by S3 archiving. Teams can export JSON or CSV, or enable continuous S3 delivery to a SIEM pipeline. Speakeasy brings the investigation back to the controls: the affected identity, server review, role grant, and guardrail are part of the same administrative workflow.

Govern the instructions shipped alongside tools

Agent instructions can change behavior as much as a new tool can. Speakeasy's Skills registry records immutable, content-addressed versions, compares changes, and tracks which versions activate on which machines. A distribution can follow the latest valid version or pin one. Teams can restore earlier content without rewriting history, then measure adoption, sampled efficacy, attributed cost, and agent feedback by version.

Plugins carry those instructions alongside approved servers. That lets a platform team investigate whether a behavior change followed a new instruction version, pin the known-good version, and manage the rollout in the same place as tool access. Runlayer also versions and distributes managed skills and restores local changes on scheduled sync. Speakeasy connects that distribution to per-version activation, efficacy, cost, and feedback, so publishing a package is not the end of the lifecycle.

Join gateway evidence with activity outside it

Tools routed through the gateway are only part of the estate. Speakeasy's AI integrations add Anthropic and OpenAI compliance data and Cursor usage and spend to the instrumented session evidence. Compliance imports support investigation after an event; they are not retroactive blocking. Anthropic inference hooks and LiteLLM integrations provide separate pre-inference enforcement points.

The device agent also supports configured Claude Code web environments and Cursor Cloud sessions, so a move off the laptop need not lose telemetry and policy checks. Those shared environments use dedicated enrollment identities, not an assumption that every cloud session automatically resolves to an individual employee. Runlayer's own client hooks, AI Watch, and browser extension also extend beyond its gateway. Speakeasy's advantage is joining supported endpoint, provider, identity, and session evidence into the governance workflow.

Set AI budgets for each employee

Speakeasy's Costs view shows employee and role breakdowns alongside client, model, and session information. The cost explorer adds drill-downs such as department, division, cost center, tools, and skills.

Budgets let an administrator give each person matching a directory condition a fixed daily, weekly, or monthly allowance. A rule can match Engineering as a department, a cost center, an IdP group, or a platform role. Each matched person gets their own allowance rather than a share of a departmental pool.

Budgets count Claude Code, Codex, and Cursor spend across all projects. A blocking rule denies over-budget users' prompts and tool calls, including native tools and MCP tools, until the window resets. Warning thresholds are configurable and default to 80%.

Budgets are in preview and require organization enablement. Spend is evaluated roughly every 30 seconds, and enforcement fails open if a rule cannot be evaluated. They are an employee spend control, not a synchronous hard cap on every charge.

Runlayer's hosted agents have daily and weekly USD budgets, set independently for each agent, that reject new runs when accumulated token cost reaches the cap. Its analytics ranks agent and model spend, and per-user, per-session, or business-unit cost analysis means exporting datasets and joining them in your reporting system.

Manage coding agents on Linux workstations

Speakeasy's device agent keeps assigned plugin and MCP configuration in place through a 60-second reconciliation cycle. On Linux, its systemd daemon works with a root helper to write managed configuration for Claude Code, Codex, and Cursor. Managed writes use root-owned paths rather than relying solely on user-editable settings.

Runlayer's Linux AI Watch package scans all user accounts for shadow AI every 15 minutes, including root and service accounts, and updates itself automatically. That covers inventory, but the Linux package does not install endpoint hooks, provide Protect or Enforce modes, capture Sessions, or install the browser extension. Those AI Watch enforcement surfaces are available on macOS and Windows.

The separate Runlayer CLI can be installed fleet-wide through .deb or .rpm packages. It supports scheduled user-context connector configuration sync, and its packaged cron jobs sync managed skills and check for CLI updates automatically. Synced MCP entries remain user-editable, with removals restored on the next scheduled configuration sync. This managed rollout is separate from the Detect-only AI Watch package.

Speakeasy's difference is the root-owned managed configuration and the device agent's reconciliation loop, deployed through the same configuration-management systems as the rest of the Linux fleet. Its Linux rollout guide covers that installation.

Speakeasy vs Runlayer feature comparison

Connect and distribute

Access control

Guardrails

Observe

Enterprise deployment and assurance

Speakeasy's platform security documentation lists SOC 2 Type II and ISO 27001 certification. It supports customer-managed AWS KMS or Google Cloud KMS keys, with keyless access to the customer's cloud account.

For private systems, internal MCP tunnels create an outbound connection from your network and forward signed caller identity to your server. That brings a private tool into the governed path without making the underlying service publicly reachable. On the client side, Tailscale private access puts selected MCP endpoints on your tailnet. Setting an endpoint to Private only closes its public route, with no automatic public fallback.

Speakeasy exposes logging controls, webhooks, and OTLP exports, with separate export sources for product telemetry, risk findings, and MCP tool logs.

When Runlayer may fit

Runlayer is a reasonable choice for a narrower set of needs:

• Self-hosting: Runlayer has a strong focus on self-hosting, with customer-operated deployments on ECS, EKS, and GKE.
• Browser prompt protection: Its managed browser extension masks or blocks sensitive input in supported web chats on macOS and Windows.
• In-process enforcement for custom agents: Its TypeScript and Python Hooks SDK wraps tools that run inside your own agent code.

If the priority is distributing approved tools by role, tying agent access to your directory, and testing policy before it reaches users, the sections above show where Speakeasy is stronger.

Why Speakeasy is the better choice

• Access follows the identity provider you already run. People's roles come from directory group mappings, and agents inherit limits from the people who own them, so one permission model covers both.
• Server approvals stay accountable as tools change. Record the evidence and rationale, approve the people or roles that need access, and re-review permission changes instead of leaving an old allowlist untouched.
• An investigation leads back to the controls. Follow a redacted finding into the captured session, identify the caller and their roles, then narrow access or update the policy that governs the next request.
• Guardrails are tested on real traffic first. Write them in plain language, replay them against recent sessions, and check the scorecard before you turn on enforcement.
• Instructions have a managed lifecycle. Compare Skills versions, pin or restore known-good content, and measure which versions employees use and how they perform.
• Cost follows the org chart. Break spend down by department and cost center, and enforce per-person budgets in the coding agents your teams use.
• Linux machines get managed controls too. The device agent writes and maintains managed coding-agent configuration on Linux.

Runlayer provides dedicated tool inspection and session protection. Speakeasy connects those security decisions to the people, permissions, instructions, and budgets behind the work. For a team operating an enterprise AI governance program, that means managing the rollout, investigating an incident, and changing the next agent request in one control plane.