In Depth: Speakeasy vs Runlayer

Speakeasy and Runlayer are both AI control planes: they sit on the path between AI agents and the tools those agents call, inspect every Model Context Protocol (MCP) request, and decide whether it proceeds. Both scan tool definitions and tool calls, both detect sensitive data in agent traffic, both discover unsanctioned MCP servers on employee machines, and both enforce role-based access on individual tool calls.

The differences show up in two places. On security, they differ in where the enforcement points sit and how policies are authored. On governance, they differ in how identity reaches the agent, how permissions are modeled, and how custom tools get built. This post walks each platform's security capabilities, then each platform's governance capabilities, and closes with the questions that decide the choice.

Speakeasy vs Runlayer at a glance

Speakeasy is an AI control plane built around enterprise identity. Every agent session resolves to a principal your directory already knows, either a person synced from Okta or Entra or an Agent Identity that syncs from the provider or is created in Speakeasy when the provider has no such concept, and one permission model governs both. Custom MCP servers are generated from the API contract your teams already maintain.

Runlayer is an AI control plane built around an MCP gateway and an endpoint agent. People authenticate through SSO and SCIM, agents authenticate as Agent Accounts native to Runlayer, and policies combine principals with runtime conditions evaluated at the proxy. Custom MCP servers are packaged as containers and deployed to Runlayer-managed infrastructure.

Part 1: Security

Where does each platform enforce security?

Both platforms enforce at the gateway and on the endpoint, and both extend into the agent runtime. The coverage differs at the edges.

Speakeasy enforces at three points. The MCP gateway authenticates every session, applies per-server and per-tool authorization, and runs inline scanners on every request and response. Agent hooks in Claude Code, Claude Cowork, Cursor, Codex, and OpenCode intercept prompts and tool calls inside the client, which is what makes shadow MCP detection, destructive command detection, and budget enforcement possible for traffic that never reaches a hosted server. The device agent runs on macOS, Windows, and Linux, enforces required plugin and MCP configuration every 60 seconds, and deploys through Jamf, Kandji, or Intune. A LiteLLM integration adds a pre-call guardrail for model traffic routed through LiteLLM. Whether hooks fail open or fail closed during an outage is an organization-level setting, and blocking is the default.

Runlayer enforces at four points. The gateway is a single-tenant deployment in AWS, either Runlayer-hosted or in your own account, and every MCP request is authenticated, authorized, scanned, and logged there before it reaches a server. The AI Watch endpoint agent deploys through MDM and installs hooks into 12 AI clients on macOS and Windows, with a Monitor mode, a fail-open Protect mode built on denylists, and a fail-closed Enforce mode built on allowlists. A CLI proxy wraps local stdio servers, and a Hooks SDK gives custom agents built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK in-process enforcement that fails closed when Runlayer is unreachable. Runlayer documents the limit plainly: native connectors configured directly in a client bypass the gateway, and policy, scanning, and audit do not apply to that traffic.

The practical difference is reach. Runlayer reaches further into the browser and into custom agent code. Speakeasy reaches further into Linux endpoints and into model traffic.

How does each platform inspect tool definitions and tool calls?

Both platforms scan a server's tool definitions when it is registered and scan tool calls while they are in flight. They differ in how the detection logic is authored.

Runlayer's scanner is ToolGuard, which runs three guards. Tool List Guard scans tool descriptions at registration for hidden instructions and prompt injection. Tool Call Guard inspects tool outputs before they reach the model for injection and exfiltration attempts. Tool Intent Guard compares a tool's inputs to its outputs and flags behavior that diverges from the request, such as privilege escalation or credential theft. Findings map to a ten-category threat taxonomy aligned to MITRE ATLAS, and each scanner can Block, Block with self-approval, Mask, Alert, or Allow at Strict, Balanced, or Moderate sensitivity, configurable globally, per connector, or per client.

Speakeasy inspects on the same two timelines with a different authoring model. At registration, MCP server review gathers an evidence dossier for each server (code host health, OSV advisories, domain registration, OAuth metadata, and the tool declarations probed without credentials) and requires a written rationale for every approval decision. On the live path, risk policies run a heuristic prompt injection detector on tool inputs and outputs, covering indirect injection, role hijacks, system prompt leaks, and encoding tricks, with an opt-in LLM judge as a second layer. Destructive tool detection reads the destructiveHint annotation on MCP tools and also recognizes destructive CLI patterns such as rm -rf, git push --force, and DROP TABLE in shell commands and tool arguments. Two authoring surfaces have no Runlayer equivalent: natural-language guardrail policies judged by an LLM, which can be replayed against recent live sessions to produce a scorecard before they go into enforcement, and custom detection rules written as CEL expressions and tested against a real session.

Runlayer's intent-alignment guard has no direct Speakeasy equivalent. Speakeasy's replayable natural-language policies and CEL rules have no direct Runlayer equivalent.

How does each platform detect sensitive data in agent traffic?

Both platforms detect PII and other sensitive content as it moves through prompts and tool calls. Speakeasy's detector catalog is broader, and Runlayer's masking action is more direct.

Runlayer ships 13 built-in PII types (SSN, credit card, phone, email, passport, driver's license, IBAN, IP address, date of birth, medical record number, VIN, and crypto wallet) plus custom RE2 regex rules. Detection direction is configurable as input, output, or both, and the Mask action redacts matched values before they continue.

Speakeasy scans four surfaces (user prompts, assistant messages, tool calls, and tool responses) against a detector catalog organized by category: secrets such as API keys and private keys, financial data such as cards and routing numbers, PII, government identifiers across the US, UK, EU, and APAC, and healthcare identifiers. Each policy has a detection sensitivity slider, a CEL scope that includes or exempts traffic by server, tool, or argument path, and exclusion lists that apply retroactively and come with a preset library of known-safe values. Actions are log, warn and confirm, or deny. Matched content is redacted in the Risk Events view by default, and revealing it is itself an audited action.

How does each platform monitor agent behavior across a session?

Both platforms capture full sessions and flag behavior that drifts over several turns. Runlayer adds a dedicated behavioral detector. Speakeasy adds imports from the model providers' compliance APIs.

Runlayer's Sessions capture prompts, reasoning, tool calls, and responses from client hooks in Cursor, VS Code, Claude Code, Copilot CLI, Gemini CLI, Cline, Codex, Windsurf, Goose, and others. AgentGuard analyzes the session as a whole, detecting output-steering injection, sudden reasoning pivots, and gradual task divergence, and can end the entire session on a block. It applies globally with no per-connector override. Anthropic inference hooks, in beta, let Runlayer inspect Claude prompts before inference for Claude Enterprise customers, with a shadow mode and percentage rollout.

Speakeasy's Agent Sessions capture full transcripts, tool calls, and per-turn cost from the hooks in Claude Code, Claude Cowork, Cursor, Codex, and OpenCode, with risk findings highlighted inline and a JSON export of transcript, telemetry, and risk results. Sessions from personal AI accounts or off-domain emails are flagged as non-corporate. Beyond the hooks, Speakeasy imports from the Anthropic Compliance API, OpenAI Compliance Logs, and the Cursor Admin API, so claude.ai, ChatGPT, and Codex cloud activity appears in the same view as instrumented sessions.

How does each platform handle shadow AI on endpoints?

Both platforms discover unsanctioned MCP servers and bring them under an allow or block policy. Runlayer's endpoint enforcement is deeper on macOS and Windows. Speakeasy's covers Linux and ties the request-access flow to the gateway's policy model.

Runlayer's AI Watch inventories AI clients, MCP servers, skills, plugins, and agent definitions across macOS, Windows, Linux, containers, and WSL, and classifies each as managed or shadow. Enforce mode applies deny-by-default allowlists, fails closed, and permits only npx, uvx, and uv tool run launchers, with arbitrary binaries denied. Enforcement is macOS and Windows only; Linux is detect only. A browser extension deployed via MDM captures prompts in 14 web chat apps and can mask or block a prompt before it is submitted. Incidents, in beta, group findings into a prioritized inbox with one-click remediation.

Speakeasy's shadow MCP detection builds its inventory from instrumented agent traffic, deduplicates servers by canonical URL, and shows usage and top users per server. Each organization picks a posture: block all with an allow list, or allow all with a block list. A blocked user receives a signed request-access link or a desktop notification from the device agent, an admin approves or denies, and approval writes an allow rule scoped to the policy's audience. The device agent enforces required configuration on macOS, Windows, and Linux and exports coverage evidence to Drata and Vanta.

How does each platform secure sessions, credentials, and the network edge?

Speakeasy acts as the OAuth authorization server for every private MCP server. Runlayer brokers OAuth to upstream vendors and binds agent tokens to specific servers.

Speakeasy's gateway implements the standard MCP authorization flow as an OAuth 2.1 server: protected resource metadata, dynamic client registration, PKCE with S256 only, a consent screen on every grant, one-hour access tokens, and single-use refresh tokens. Admins choose which OAuth clients a server accepts from a verified client catalog that includes Claude, Claude Code, VS Code, Zed, ChatGPT, and Codex CLI. When the gateway proxies a remote or tunneled server, it drops the caller's Authorization, Origin, Referer, and Cookie headers and never forwards platform tokens upstream. At the network edge, an IP allowlist on a custom domain is enforced before traffic reaches the application, and MCP tunnels reach servers inside a VPC over an outbound-only WebSocket with no inbound ports. Stored secrets are encrypted with AES-GCM, and organizations can bring their own keys through AWS KMS or GCP KMS.

Runlayer's OAuth Broker centralizes vendor OAuth with pre-registered applications and per-tenant bring-your-own-client registration, stores tokens in field-level encrypted columns with KMS, and masks token values in API responses. Agent tokens support RFC 8707 resource indicators, so a token bound to one server is rejected everywhere else. Deployment is single-tenant in AWS, either hosted by Runlayer or self-hosted in your account through ECS, EKS, or a Kubernetes operator, with air-gapped installs supported. GCP and Azure hosting are not offered.

Part 2: Governance

Whose identity does an agent run as?

On Speakeasy, an agent runs as a principal your identity provider knows: either the directory user behind the session or an Agent Identity. On Runlayer, a person runs as an SSO user and an agent runs as an Agent Account that lives inside Runlayer. Identity and authority are separate from the agent's working arrangement.

Speakeasy syncs users, groups, and attributes from Okta or Entra through directory sync, with a 30-second poll and deprovisioning that removes grants. When a person drives an agent, the MCP authorization handshake sends the client through your identity provider, so the session belongs to that person from the first call. For agents that need a principal of their own, Agent Identity, currently in early access, syncs from providers that model agents natively, such as Entra Agent ID, and can be created in Speakeasy when the provider has no such concept. An Agent Identity can be tied to a user or act with its own authority, and it holds its own roles and grants. Both principal types are evaluated by the same permission model and appear in the same audit trail.

Runlayer handles people and agents separately. People get SSO and SCIM group sync, and directory groups map to seven platform roles with separation-of-duty rules. Agents get Agent Accounts, in beta and requiring access approval. An Agent Account is an OAuth client created in Runlayer with a client ID and secret. Runlayer does not provision a matching identity in Okta or Entra, and the documentation states that the identity provider is unchanged. An Agent Account can use machine-to-machine tokens under its own authority, or act on behalf of a user through an RFC 8693 token exchange once that user has created a delegation. On a delegated call, the effective permission is the intersection of the agent's policies, the user's policies, and the server's policies.

The difference an auditor notices is where the answer to "who is this principal" lives. On Speakeasy it lives in the directory, for people and for agents. On Runlayer it lives in the directory for people and in Runlayer for agents.

How is RBAC enforced on a single tool call?

Both platforms evaluate permissions per tool call and fail closed on conflicts. Speakeasy models permissions as grants against a directory principal. Runlayer models them as policies with runtime conditions evaluated at the proxy.

A Speakeasy grant pairs a scope with selectors that name which resources it reaches. A session attaches to a server only when the caller holds mcp:connect for that server, and each tool call then passes a second check that carries the tool name and the tool's disposition, derived at call time from its MCP annotations (read_only, destructive, idempotent, or open_world). A support role can connect to the billing server, succeed on get_invoice, and be denied on create_refund, with no change to the server:

{
  "scope": "mcp:connect",
  "selectors": [
    {
      "resource_kind": "mcp",
      "resource_id": "<billing-server-id>",
      "disposition": "read_only"
    }
  ]
}

Deny rules evaluate in a separate pass, and a matching deny always beats a matching allow. For remote servers, an admin-recorded annotation overrides whatever the vendor publishes, so a vendor cannot quietly flip a tool from read-only to destructive. Every denied call lands in an Authorization Challenges log that opens directly into the grant that would allow it.

Runlayer policies combine principals (users, groups, roles, Agent Accounts, or identity provider attributes), a scope of servers or individual tools, and runtime conditions. The condition language has 22 operators over tool arguments, IP ranges, user agent, OAuth provider and scopes, MCP annotation hints, and session history, so a policy can deny a call that touches a second repository once the session has already accessed one. Policies are also manageable as code through a Terraform provider. Session grants decide whose upstream OAuth credentials a call uses, falling back from the caller's personal grant to a shared grant and failing when neither exists.

Runlayer's runtime condition language is richer. Speakeasy's principal on every decision is a directory identity.

How does each platform handle approvals and exceptions?

Both platforms route high-risk actions through a human before they proceed and let users request exceptions to policy.

Runlayer's human-in-the-loop approvals, in beta and enabled by the account team, pause an agent run on a matching tool call until an approver allows or denies it in Slack, with templates for destructive tools, external network access, and untrusted clients. Access requests let users ask for a connector or catalog item, and admins approve or reject with notes that land in the audit log.

Speakeasy's risk policies support a warn-and-confirm action that holds a call for acknowledgement, and approval routing sends a matching tool call to a designated approver before it executes. Policy bypass requests run through an RBAC-protected queue with requested, approved, denied, and revoked states, scoped to a single policy or a single shadow server, and every state change is attributed and revocable. MCP server review requires a written rationale on every decision.

What does each platform record, and where can it go?

Both platforms keep an organization-wide audit log, stamp tool-call records with the caller's identity, and export to a SIEM.

Speakeasy's audit log records every administrative action as a resource:action event with the actor and a diff, and tool-call telemetry carries the caller's directory snapshot (groups, attributes, and roles at the moment of the call). Events leave the platform through webhooks for audit and risk finding events, through project-scoped data exports for normalized OTLP logs, metrics, and traces, and through SIEM export. Tool logs and sessions are retained for 90 days, and capture of tool inputs and outputs is off until an admin enables it.

Runlayer's audit log records lifecycle, policy, authentication, tool-call, and security events with ToolGuard metadata attached, keeps a 90-day hot window, then archives to S3 indefinitely. SIEM export streams compressed NDJSON to an S3 bucket, with CrowdStrike, Splunk, and Sentinel named as destinations. Prompts and reasoning are excluded from the audit log and live in Sessions.

How does each platform bring tools under governance?

Speakeasy generates governed MCP servers from the API contract your teams already maintain and fronts third-party servers with a governed proxy. Runlayer curates a catalog of vetted connectors and hosts custom servers you package as containers.

On Speakeasy, a server built from your own API is generated from its contract, with the tool set curated, renamed, or re-described through tool variations and narrowed per client with tag-based filtering. Any vendor's remote server gets a governed endpoint by URL, with one-click OAuth through dynamic client registration, and the catalog draws from the official MCP Registry. Skills live in a registry with content-addressed immutable versions, diffs, and rollback, and plugins bundle servers and skills for assignment to roles, with the device agent enforcing the assignment on each machine.

On Runlayer, the catalog lists pre-tested connectors with their ToolGuard results visible before enablement, and manual connectors require admin approval. The Runlayer site claims more than 18,000 servers; the documentation describes the catalog as continuously growing and refers to an account representative for the full list. Custom servers are built as Docker images and deployed through Runlayer Deploy to managed Fargate, with an MCP Builder prompt that scaffolds TypeScript servers. The Runlayer Plugin exposes one endpoint per user with search_tools and execute_tool meta-tools, and skills and plugins sync to devices hourly.

How does each platform track cost and usage?

Speakeasy attributes spend to the directory and enforces per-person budgets. Runlayer attributes spend to agents and, in early access, proxies model traffic.

Speakeasy's costs view breaks down spend by employee, role, model, agent, and client, and the cost explorer cuts by department, division, job title, and cost center, all sourced from directory attributes. Budgets are per-person rules matched on those attributes, warn at 80%, and can block in Claude Code, Codex, and Cursor. Employee enrollment shows who is instrumented, which AI accounts are linked, and whether each is a team or personal account.

Runlayer's analytics cover active users, agents, and connectors, tool-call success rates, and agent token consumption. Agent budgets in USD alert at 75%, 90%, and 100% through Slack. An LLM Gateway, in early access and self-hosted only, adds virtual keys with per-key budgets and rule-based model downgrades. Per-user and per-team cost requires an export.

When should you pick Runlayer?

• Your agents are built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK and you want in-process enforcement through a Hooks SDK.
• Browser-based AI usage is a top concern and you want to mask or block prompts in web chat apps through a browser extension.
• You need the control plane to run in your own AWS account, including air-gapped.
• You want policies with rich runtime conditions over tool arguments, IP ranges, and session history, managed through Terraform.
• You want agents modeled as principals deliberately separate from the corporate directory, which is what Agent Accounts implement.

When should you pick Speakeasy?

• Agent identity must live in the identity provider you already run. People sync from Okta or Entra, Agent Identity syncs from providers like Entra Agent ID, and one permission model covers both.
• Your auditors ask "who did this, and why was it allowed," and the answer has to be a directory principal plus the grant that permitted the call, stamped with their directory state at the time.
• The tools that matter most sit behind your own APIs, and you want governed MCP servers generated from the contract your teams already maintain.
• You want to write guardrails in plain language, replay them against last week's sessions, and see the scorecard before turning on enforcement.
• Cost and budgets need to follow the org chart, with per-person limits keyed on department or cost center and enforced in the coding agents your teams use.
• Your endpoint fleet includes Linux and you need enforcement there, with coverage evidence flowing to Drata or Vanta.