SpeakeasyvsRunlayer

Runlayer governs the tool calls that reach its gateway and watches what runs on the device. Speakeasy runs inside the agent: hooks see the prompt, the tool call, and the shell command before they run. Then it governs the gateway too.

Schedule a deep dive

Which should you pick, Speakeasy or Runlayer?

Pick Speakeasy when AI is rolling out across the whole company and you want one control plane that plugs into the agents, identity provider, and tools your teams already use, and governs every step of the loop as well as the gateway. Pick Runlayer when every tool call you care about reliably crosses a proxy, when your custom agents are built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK, when masking prompts in browser chat apps is the priority, or when the whole control plane must run in your own AWS account.

Pick it when

AI is rolling out across the whole company and you want one control plane that plugs into the agents, identity provider, and tools your teams already use, and governs every step of the loop as well as the gateway.

Every tool call you care about reliably crosses a proxy, your custom agents are built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK, or masking prompts in browser chat apps is the priority.

Governance

Agents run as principals in the identity provider you already have, Okta or Entra, with the grant checked on every call.

An Agent Account minted inside Runlayer, with policies evaluated when a request reaches the proxy. Your identity provider is unchanged.

Security

Hooks inside the agent on the prompt, the tool call, the file read, and the shell command, plus six inspection layers at the gateway, on macOS, Windows, and Linux.

ToolGuard's three guards on the tool calls that reach the gateway, an endpoint agent that inventories clients and servers and captures sessions on macOS and Windows, and a browser extension for web chat. Tool-call policy runs at the proxy.

Enablement

Your agents, your identity, your APIs. MCP servers are generated from the API contract your teams already maintain, with evidence to Drata, Vanta, and your SIEM.

Governance for what you route through the proxy and bring onto Runlayer: containers on its infrastructure, Agent Accounts inside it, and in-process hooks for agents built on four agent frameworks.

Both products as published in August 2026. We build Speakeasy, so read us as an interested party. Every claim about Runlayer links to a primary source in the in-depth comparison. Read the in-depth comparison.

Who is the agent, at every step?

Both check a role on every proxied tool call. Speakeasy attaches a principal from your directory inside the loop, so the prompt, the local call, and the shell command run as someone too. Runlayer mints an Agent Account inside Runlayer and evaluates its policies when a request reaches the proxy.

Speakeasy

Okta or Entra
Directory principal
Grant checked per call
Call stamped with directory state

Identity lives in

Your identity provider

Directory identity attached inside the agent, on every step
People and agents share one permission model
A denied call opens the grant that would allow it

Runlayer

SSO and SCIM
Agent Account, created in Runlayer
RFC 8693 token exchange
Agent ∩ user ∩ server policies

Identity lives in

Inside Runlayer, at the proxy

Policies evaluated when a request reaches the proxy
Agents are Agent Accounts inside Runlayer; the identity provider is unchanged

You can only inspect what you can see.

From the gateway, Runlayer scans the tool call and the tool result. From the endpoint, it inventories clients, servers, skills, and plugins, captures sessions through client hooks on macOS and Windows, and lets AgentGuard end a session that drifts. Speakeasy's hooks apply policy to the prompt before inference, the local tool call, the file read, and the shell command, on macOS, Windows, and Linux, and the gateway scans the rest.

7 inspection layers

01Hooks inside the agent: prompt, tool call, file read, shell command
02Server review with evidence dossier
03Prompt-injection heuristic
04LLM judge
05Natural-language guardrails, replayed before enforcement
06CEL detection rules
07Destructive-action detection

4 inspection layers

01Tool List Guard, at registration
02Tool Call Guard, at the proxy
03Tool Intent Guard, at the proxy
04AgentGuard session drift, across the session

Prompts before the model sees them

Hooks in five coding agents

Browser extension in 14 web apps; Anthropic inference hooks in beta

Local tool calls, file reads, shell commands

PreToolUse hooks, destructive-action detection

Captured in Sessions; AgentGuard can end the session

Endpoint enforcement

macOS, Windows, Linux

macOS and Windows; Linux detect only

Tool calls at the gateway

Inline scanners on request and response

ToolGuard's three guards

Sensitive-data detectors

Secrets, financial, PII, government IDs, healthcare

13 PII types

OAuth 2.1 authorization server

PKCE, DCR, consent

OAuth Broker to vendors

Bring your own KMS key

AWS KMS, GCP KMS

AWS KMS

In-process Hooks SDK for agent frameworks

Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, Google ADK

Intent-alignment guard

Offered
Partial, beta, or detect only
Not offered or not documented

Govern what your team already runs.

Speakeasy governs the agents your teams already run, the directory you already have, and the APIs your teams already maintain, from the inside. Runlayer governs what you bring onto Runlayer: custom servers as containers on its infrastructure, agents as Agent Accounts inside it, and a catalog it curates.

Speakeasy

Your agents
Your identity
Your stack

MCP servers generated from the API contract your teams maintain
Catalog drawn from the official MCP Registry
Coverage evidence to Drata and Vanta, events to your SIEM

Runlayer

Agents: Agent AccountsHooks SDK for four agent frameworks
Servers: Docker on Runlayer DeployManaged Fargate
Catalog: Runlayer-curatedRunlayer Plugin

ToolGuard and RBAC run on what you route through the proxy
Custom servers move onto Runlayer's infrastructure
In-process enforcement needs agents built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK

Questions

What is the difference between Speakeasy and Runlayer?

Both authenticate, authorize, scan, and log MCP tool calls. The difference is where they stand. Runlayer is built around a gateway: ToolGuard and its policies run on the requests you route through it, an endpoint agent inventories clients and servers and captures sessions on macOS and Windows, and a browser extension covers web chat. Speakeasy runs inside the agent loop through hooks in Claude Code, Cursor, Codex, Cowork, and OpenCode, so the prompt, the local tool call, the file read, and the shell command are governed before anything reaches a gateway, and then governs the gateway too, with identity from your directory and servers generated from your API contracts.

Whose identity does an AI agent run as in Speakeasy vs Runlayer?

In Speakeasy, an agent runs as the directory user behind the session or as an Agent Identity, which syncs from providers that model agents natively, such as Entra Agent ID, or is created in Speakeasy when the provider has no such concept. Agent Identity is in early access. In Runlayer, an agent runs as an Agent Account, an OAuth client whose identity lives inside Runlayer rather than in your identity provider, and acts as a specific user only when on-behalf-of delegation has been set up.

Do Speakeasy and Runlayer have the same security capabilities?

On the core jobs, yes. Both inspect tool definitions at registration and tool calls in flight, detect prompt injection and sensitive data, monitor behavior across a session, discover unsanctioned MCP servers on endpoints, and enforce allow or block policies. Runlayer's reach beyond the proxy is an endpoint agent with client hooks on macOS and Windows, a browser extension for 14 web chat apps, and a Hooks SDK for agents built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK. Speakeasy's is hooks that apply policy inside the five coding agents your teams already run, on macOS, Windows, and Linux.

When is Runlayer a better choice than Speakeasy?

Pick Runlayer when every tool call you care about reliably crosses a proxy and the gateway is the whole job, when your custom agents are built on the Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK, or Google ADK and need its Hooks SDK, when masking prompts in browser chat apps is the priority, or when the whole control plane must run in your own AWS account, including air-gapped.

Why do hooks matter for governing AI agents?

A coding agent reads files, runs shell commands, edits code, and calls local tools, and none of that produces a request a proxy can inspect. Hooks are lifecycle handlers the agent itself invokes on every prompt and tool call, with the full session context, before execution proceeds. Speakeasy runs hooks in Claude Code, Cursor, Codex, Cowork, and OpenCode, which is how it sees and governs the loop rather than only the traffic that leaves it.

More comparisons

AI everywhere.

Control here.

Explore the platform Talk to us