In Depth: Speakeasy vs Rippling

Speakeasy and Rippling both ship an MCP gateway and an agent identity product, and both anchor AI governance in a system that already knows who everyone is. They started from opposite ends of the problem. Rippling is the workforce management platform. Its MCP Gateway grew out of the employee graph that runs HR, IT, and payroll, and it decides which Model Context Protocol connections and tools each employee may use, with access that tracks employment state automatically. Speakeasy is an AI Control Plane built for runtime agent governance, with a hybrid MCP gateway anchored in the corporate directory and agent hooks that enforce policy on the prompts, shell commands, file edits, and local tool calls inside the agent session that no gateway sees. If you are choosing between them, the decision turns on whether you need to govern access to one platform or agent behavior across the whole company.

What is Rippling AI Governance?

Rippling runs HR, IT, payroll, and spend on one employee graph, and its AI Governance suite applies that graph to AI adoption. Two of the four components are live. The MCP Gateway sits in the Rippling IT app as the control panel where admins manage access policies, assign tools, and review audit logs, per Rippling's MCP documentation. Access assignments target Supergroups, dynamic groups that stay current as attributes like department, location, and employment status change, and the default is deny. No employee can connect an AI client to anything until an admin creates an assignment. Agent Identity Management gives non-human actors records of their own with assigned owners and permissions, acting under a delegated employee identity or their own, revocable from one system. The other two components are waitlisted. The AI Gateway will route LLM traffic for model access control, budgets, and usage logging, and Shadow AI Detection will surface unapproved AI apps, OAuth connections, browser extensions, coding assistants, local agents, and MCP servers, per the launch announcement. A standalone AI Spend Console maps AI spend to employees, teams, and productivity signals.

Behind the gateway sits the Rippling MCP, Rippling's first-party MCP server, which lets Claude, ChatGPT, Cursor, Gemini, and any MCP-compliant client act on Rippling data. Instead of exposing dozens of endpoint-shaped tools, it exposes one tool named code. The model writes a JavaScript program against 31 typed codemode.* functions spanning people and org chart, time off, hiring, and custom objects, and the program runs in a fresh Cloudflare Worker isolate with zero network egress and no credentials inside the sandbox. Which functions the program can even see is decided by policy and permissions before a line runs. Rippling's engineering write-up reports a complex query dropping from 11,071 tokens across 22 model turns to 204 tokens in one turn, a 98% reduction. Both figures are Rippling's published claims. Writes stay inside Rippling's normal business rules, so a time-off request enters the standard manager approval queue and hiring produces a draft for human review. High-risk fields, including SSNs, pay, home addresses, personal emails, tax IDs, and EEO data, are never exposed through the MCP at all.

Rippling entered this market mid-litigation. MCP gateway startup Runlayer sued Rippling in July 2026 over an evaluation conducted under NDA, and Rippling countersued on three patents in August. We take no position on the merits.

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 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. 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). Custom MCP servers are generated from the API contract a team already maintains.

Agent hooks are the second layer. 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. The platform holds SOC 2 Type II and ISO 27001, per the security page.

Speakeasy vs Rippling overview

How do the architectures differ?

Anchors: the employee graph or the corporate directory

Rippling anchors governance in the employee graph. An access assignment targets a Supergroup whose membership recomputes as department, location, or employment status changes. Offboard a worker in Rippling and their MCP access is revoked immediately, with no orphaned keys. If Rippling is your HRIS and your IT stack, employment truth and AI access live in one system, and the classic offboarding gap closes by construction.

Speakeasy anchors governance in the identity provider. The permission subject is a directory principal synced from Okta or Entra through directory sync, with a 30-second poll and deprovisioning that removes grants, so the same offboarding property holds, anchored in the system your auditors and every downstream SaaS app already treat as the source of truth. The two anchors pull apart when your directory and your HR system are different systems, which is the common case in the enterprise. Rippling's controls key on Rippling records, and no documented path lets those grants follow Okta or Entra groups. Extending IAM to agents explains why we chose the directory as the anchor.

Chokepoints: the approved connection or the whole session

Rippling intercepts at its gateway with a dual-layer check. The MCP Gateway policy decides which tools you may use, and Rippling's own role-based permissions decide what the underlying action may touch, so you cannot see or do anything through MCP that you could not do in Rippling directly. Deny is the default, individual assignments override group ones, and admins can revoke a specific tool company-wide instantly.

The documentation describes no inspection of the traffic the policy permits. There is no documented scanning of tool calls or responses for prompt injection, no tool poisoning defense for connectors, no sensitive-data detection on content in flight, and no behavioral monitoring across a session. The gateway is also the only documented chokepoint. In a Claude Code or Cursor session, the prompts, the shell commands, the file edits, and the local stdio servers a developer configured directly never touch a gateway URL, and Rippling's answer for them, Shadow AI Detection, is a waitlisted discovery product rather than a shipped enforcement point. Speakeasy enforces on both layers from one policy. Inline risk policies run at the gateway, the same policies run inside the agent loop through hooks, and destructive patterns such as rm -rf and git push --force are blocked before execution.

Estates: the Rippling slice or the whole company

The Rippling MCP covers people, time off, hiring, and custom objects with field-level permissions, structural redaction of the most sensitive fields, and write actions that flow into Rippling's existing approval queues. For agents acting on workforce data inside Rippling, no other interface matches it.

Most of your agent activity is not workforce data. It is the billing API behind your product, the internal admin services, the data platform, the SaaS estate, and the coding agents on developer laptops. Rippling's gateway lists connectors in a catalog, but Rippling documents no way to build a governed MCP server for your own systems and no inspection for the third-party connections it allows. Speakeasy is built for that estate, with governed servers generated from the OpenAPI contract your teams maintain, curated through tool variations, any vendor's remote server behind a governed proxy, and a catalog drawn from the official MCP Registry.

Buyers: the IT admin console or the security function

Rippling's natural buyer already runs Rippling. The MCP Gateway is a tab in the IT app, administered with the same Supergroups and role model as the rest of the platform, and it requires an active Rippling AI subscription to return data. That helps a consolidation-minded IT team and constrains everyone else, because adopting it as your AI control point means adopting Rippling as the system of record underneath it. Speakeasy's buyer is the CISO or platform function accountable for every employee's AI usage, whose scope is the company rather than one vendor's platform, and whose evidence has to land in the SIEM and the systems the security operation already runs.

How do the security capabilities compare?

Rippling's shipped security model is preventive and structural. The sandbox that runs Code Mode programs has zero network egress and never holds credentials, so a malicious program cannot exfiltrate directly or steal a token. The permission set is fixed before execution. In Rippling's own phrasing from its engineering write-up, the model proposes the work and Rippling decides what is allowed. Sensitive fields are excluded from the surface entirely rather than filtered at runtime, and restricted bulk operations cap how much a single request can pull. Many MCP servers lack these defaults.

They protect Rippling's data, on Rippling's server. Across the rest of your surface, the detective layer is thinner. No documented capability scans a connector's tool definitions at registration, detects prompt injection arriving through tool outputs, catches secrets or customer data moving through agent traffic, or captures sessions for investigation. Shadow AI Detection will surface unapproved coding assistants, local agents, and MCP servers with employee and device context, and its announcement describes approving, restricting, or migrating that usage to managed paths. It is waitlisted, and inline blocking on the endpoint is not described. Its planned discovery scope is broader than Speakeasy's traffic-sourced inventory, reaching browser extensions and third-party OAuth grants that hooks never see. Speakeasy ships that layer in production, with a prompt injection heuristic and an opt-in LLM judge on tool inputs and outputs, sensitive-data detectors across prompts, assistant messages, tool calls, and tool responses, natural-language guardrails replayed against recent sessions for a scorecard before enforcement, CEL detection rules, shadow MCP detection with an allow-or-block posture and a request-access flow, and Agent Sessions with risk findings inline.

How do the governance capabilities compare?

On Rippling, a person connects through My IT, authorizes the connection explicitly, and every request runs under their live Rippling identity with the dual policy-plus-permissions check. Agents get Agent Identity Management, records with assigned owners, provisioned into third-party apps, acting under a delegated employee identity or their own, auditable and revocable from one system. Rippling's agent identity product is generally available. Speakeasy's Agent Identity is in early access.

On Speakeasy, the session is the directory principal from the OAuth handshake, grants evaluate against that principal on every call with the tool's disposition read from its MCP annotations, a deny pass always beats allow, and each call is stamped with the caller's groups, attributes, and roles at that moment. Agent Identities sync from providers that model agents natively, such as Entra Agent ID, or are created in the platform, and the same permission model and audit trail cover people and agents. An auditor asking who a principal is gets a directory record on Speakeasy, for people and agents alike, and a Rippling graph record on Rippling. The export path differs too. Speakeasy pushes audit and risk events through webhooks, project-scoped OTLP data exports, and SIEM export, while Rippling's gateway audit logs are reviewed in the IT app with no documented SIEM or telemetry export.

How do spend visibility and cost control compare?

The AI Spend Console came out of Rippling's own multi-million-dollar internal AI bill. It breaks spend down by employee, team, role, and department and maps it against productivity signals such as performance ratings and pull request volume. Speakeasy has no equivalent of that productivity mapping. Enforcement is the gap on the Rippling side. Budget and spend limits belong to the waitlisted AI Gateway, so the shipped console measures spend rather than stopping it.

Speakeasy meters where spend happens and enforces there. Hooks record every turn in the instrumented coding agents, the costs view cuts spend by employee, role, model, agent, and cost center from directory attributes, and budgets warn at 80% and block in Claude Code, Codex, and Cursor. Blocking covers three of the five hooked agents so far; Claude Cowork and OpenCode sessions are metered but not yet blocked. 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 the spend no gateway would ever meter.

When should you pick Rippling?

• Rippling already runs your HR and IT, and you want AI access governance keyed to employment state with no integration work. Supergroup assignments recompute on role changes and revoke on offboarding by construction.
• Your agents act chiefly on workforce data, where the Code Mode server with its sandbox, structural redaction, and approval-queue writes is the strongest governed interface to Rippling available.
• Generally available agent identity with assigned owners decides your evaluation, and Rippling's Agent Identity Management being live outweighs Speakeasy's early-access label for you.
• Your leadership's first question is return on AI spend, which the AI Spend Console answers by mapping cost to performance signals.
• You weight certification breadth heavily. Rippling's program spans SOC 1, 2, and 3, ISO 27001, ISO 27018, ISO 42001, and CSA STAR Level 2.

When should you pick Speakeasy?

• Your threat model includes what is inside the traffic. Prompt injection, tool poisoning, and data leakage need detection and inline blocking on any connection, not access control alone.
• Governance has to cover the whole agent session, with hooks enforcing on prompts, shell commands, file edits, and locally configured MCP servers in the coding agents your teams already run, today rather than behind a waitlist.
• Every tool call must resolve to a principal in the Okta or Entra directory you already operate, with the caller's directory snapshot stamped on the record.
• The tools you care most about sit behind your own APIs, and you want governed MCP servers generated from the contracts your teams maintain rather than a catalog of someone else's connectors.
• Your security operation needs the exhaust. SIEM export, webhooks, OTLP telemetry, and session transcripts with risk findings flow into the systems your SOC already runs.
• Budgets need to be enforced per person, inside the coding agents, with visibility into the personal-account spend no gateway meters.

The questions that decide the choice

• What inspects an allowed connection? A poisoned tool description or an injected instruction arrives over a connection the policy permits. On Speakeasy, inline scanners and server review cover this case. Ask Rippling what examines traffic after the access check passes.
• What governs the coding agent on a developer laptop today? Speakeasy's hooks block a destructive command in the loop. Rippling's coverage for coding assistants sits in waitlisted Shadow AI Detection, so ask for dates, and ask whether it will block or only report.
• Which system is the source of identity truth for your audit trail? If it is Okta or Entra, ask Rippling how gateway decisions keyed to Rippling records reconcile with directory principals. If Rippling is your identity system, its answer is coherent and you should weigh it.
• How do your own APIs become governed tools? Ask Speakeasy to generate a server from your OpenAPI document in the meeting. Ask Rippling how a server for your product's API gets built, governed, and inspected.
• What reaches your SOC? Ask both vendors for the SIEM export, the webhook events, and a sample session record. Speakeasy documents that pipeline; Rippling does not.
• What is generally available versus waitlisted? Rippling's AI Gateway and Shadow AI Detection were waitlisted at launch, and the Rippling MCP requires an active Rippling AI subscription. Price the deployment you can run this quarter.

Where the Speakeasy AI Control Plane fits

Rippling's suite is the right tool for governing how AI touches Rippling. If your agents work mostly on workforce data and Rippling already runs your HR and IT, use its controls, and nothing in Speakeasy replaces the Code Mode server on its own turf. For company-wide AI governance, Speakeasy is the stronger product. It inspects the traffic instead of only permitting it, governs the coding-agent session instead of discovering it after the fact, anchors every decision in the directory your security program already trusts, turns your own APIs into governed tools, and delivers its evidence to your SIEM. An AI governance evaluation ultimately turns on those capabilities, and most of them have no shipped Rippling equivalent.