Skip to main content

SpeakeasyvsLiteLLM

LiteLLM governs the model calls you route through its proxy: virtual keys, budgets, and guardrails on the request. 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, with LiteLLM kept as the model proxy.

Schedule a deep dive

Which should you pick, Speakeasy or LiteLLM?

The two usually run together, so the question is scope. Pick LiteLLM when model-call governance is the job: one OpenAI-compatible endpoint across 100+ providers, routing and fallbacks, per-key budgets and rate limits, and PII masking or provider guardrails on the prompts and responses that reach the proxy. Pick Speakeasy when the agents are coding agents on laptops, when the question is whose directory identity a tool call ran as, or when you want one control plane that governs every step of the loop and the MCP gateway, with LiteLLM kept in place as the model proxy.

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, with LiteLLM kept as the model proxy.

LiteLLM

Model-call governance is the scope: one endpoint across providers, per-key budgets, and guardrails on the prompts and responses that reach the proxy.

Governance

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

LiteLLM

A virtual key issued by LiteLLM, resolved when the request reaches the proxy: its team, budget, model list, and registered MCP servers.

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.

LiteLLM

Guardrail providers such as Presidio, Lakera, and Bedrock on the prompts and responses that reach the proxy, plus MCP guardrails for servers registered with it. The local tool call and the shell command never reach it.

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.

LiteLLM

One OpenAI-compatible endpoint in front of 100+ providers with routing, fallbacks, and per-key budgets. Speakeasy plugs in as one of its guardrails.

LiteLLM capabilities are drawn from LiteLLM's public documentation as of September 2026. We build Speakeasy, so read us as an interested party. Speakeasy ships a LiteLLM integration; this page compares scope, not a rivalry. Read AI gateway vs MCP gateway vs AI control plane.

Who is the agent, at every step?

Both decide per call whether a request proceeds. Speakeasy attaches a principal from your directory inside the loop, so the prompt, the local call, and the shell command run as someone too. LiteLLM resolves a request to the virtual key that sent it, when it reaches the proxy.

Speakeasy
  1. OktaMicrosoft Entra IDOkta or Entra
  2. Directory principal
  3. Grant checked per call
  4. 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
LiteLLM
  1. SSO and SCIM (enterprise)
  2. Virtual key, issued by LiteLLM
  3. Key's team, budget, and model list
  4. Spend logged per key and team

Identity lives in

A virtual key, at the proxy

  • Access resolves to the key: its team, budget, models, and MCP servers
  • SCIM deprovisioning blocks a departed user's keys

You can only inspect what you can see.

From the proxy, LiteLLM sees the prompt, the response, and calls to MCP servers registered with it, and runs guardrail providers on them. 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
LiteLLM4 inspection layers
  • 01Guardrail providers at the proxy: Presidio, Lakera, Bedrock, Aporia
  • 02Tool permission guardrail, at the proxy
  • 03MCP guardrails, pre and during call
  • 04Guardrail policies (beta)

Prompts before the model sees them

Hooks in five coding agents
pre_call guardrails, on traffic routed through the proxy

Local tool calls, file reads, shell commands

PreToolUse hooks, destructive-action detection
Never reach the proxy

Endpoint enforcement

macOS, Windows, Linux
No endpoint agent or in-agent hooks

Tool calls at the gateway

Inline scanners on request and response
MCP guardrails for servers registered with LiteLLM

Shadow MCP discovery

Traffic-sourced inventory
Only servers registered in LiteLLM

Natural-language guardrails with replay

Scorecard before enforcement

PII masking in flight

Redacted in Risk Events
Presidio pre_call

External guardrail providers

Lakera, Bedrock, Aporia, Prisma AIRS
  • 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. LiteLLM governs the model calls you route through it, and Speakeasy plugs in as one of its guardrails.

Speakeasy
Your agents
Claude CodeClaude CoworkCursorCodexOpenCode
Your identity
OktaMicrosoft Entra ID
Your stack
GitHubSlackLinearNotionSnowflakeJamf
  • 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
LiteLLM
Models
100+ providersRouting and fallbacks
Keys
Virtual keysBudgets and rate limits
Tools
MCP proxyToolsets and skills marketplace
  • Governance applies to traffic that reaches the proxy
  • Tools come under control by registering servers in LiteLLM
  • Runs with Speakeasy: policy before inference, usage into Costs

Speakeasy's AI control plane has been indispensable in enabling Fivetran's AI transformation.

Eli Davis

Fivetran

Fivetran

Questions

What is the difference between Speakeasy and LiteLLM?

Both apply policy to requests. The difference is where they stand. LiteLLM is a proxy in front of 100+ model providers: virtual keys, budgets, routing, fallbacks, and guardrails run on the requests you route through it, plus an MCP proxy for servers registered with it. 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 proxy, and then governs the gateway too, with identity from your directory and servers generated from your API contracts.

Can Speakeasy and LiteLLM be used together?

Yes. Speakeasy ships a LiteLLM integration. LiteLLM calls the platform through its Generic Guardrail API before each model request, so a prompt that violates policy is blocked at the proxy before a provider sees it, and a metadata-only OpenTelemetry export carries model, tokens, cost, and duration into Observe and Costs, attributed to a person by matching virtual-key emails to organization members. LiteLLM keeps model selection, provider credentials, retries, and budgets.

Does LiteLLM govern MCP tool calls?

For servers registered with LiteLLM, yes. Its MCP gateway supports per-key, per-team, and per-organization server access, tool-level permissions, access groups, cost tracking per tool call, and guardrails that run before or during an MCP call. It does not see tool calls that bypass the proxy, such as local stdio servers configured in a coding agent, and it has no endpoint agent or in-agent hooks.

When is LiteLLM a better choice than Speakeasy?

Pick LiteLLM when every model call you care about routes through one endpoint and the job is routing, fallbacks, per-key budgets and rate limits, and PII masking or provider guardrails on prompts and responses. When the agents are coding agents on laptops, or the question is whose directory identity a tool call ran as, that is the control plane's job, and LiteLLM stays in place as the model proxy.

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

vs

Speakeasy vs Runlayer

A proxy sees the request. Hooks see the agent think: the prompt, the reasoning, the local tool call, the shell command.

Read the comparisonvsMintive

Speakeasy vs Mintive

Both run hooks inside the agent. They differ on whose identity the loop runs as and who authors detection.

Read the comparisonvs

Speakeasy vs Kong

An API gateway sees the request. Hooks see the agentic loop: prompts, file reads, shell commands, and local tool calls.

Read the comparisonvsMicrosoft

Speakeasy vs Microsoft

Microsoft governs agents on its path. Hooks govern the agents your teams already run, on every OS, as the same Entra principal.

Read the comparison

AI everywhere.

Control here.

Explore the platformTalk to us