In Depth: Speakeasy vs Databricks Unity AI Gateway

Speakeasy and Databricks Unity AI Gateway both govern enterprise AI, but they started in different places. Unity AI Gateway grew out of an AI gateway: it began as governed routing for model traffic and is now expanding toward agents, MCP servers, and tools. Speakeasy started as an MCP gateway, sitting between agents and the tools they call over the Model Context Protocol (MCP), and has grown into a full AI control plane. If those three categories are new to you, AI gateway vs MCP gateway vs AI control plane walks through them properly. The short version: an AI gateway routes model traffic, an MCP gateway governs the MCP layer, and an AI control plane governs every surface on the path between agents and systems.

This post starts with how each product is architected, compares their security, governance, and cost capabilities, and ends with the questions we would ask when evaluating Unity AI Gateway alternatives.

What is Databricks Unity AI Gateway?

Unity AI Gateway is the Databricks governance product for enterprise AI, and it became generally available on August 4, 2026. It routes model and MCP traffic through a central gateway, registers the AI assets behind that traffic as Unity Catalog securables, and attributes usage and cost to principals, teams, and budgets. Some pieces are still in Beta per the release notes, including service policies and agent services.

The model layer is the core of the product. Databricks serves frontier models natively through Foundation Model APIs, and the GA announcement describes pay-per-token access to Anthropic, OpenAI, Gemini, Kimi, and GLM models through a single query API. External providers connect with bring-your-own-key. The gateway applies rate limits, budgets, traffic splitting, and fallbacks to that traffic, and Smart Routing (in Beta) picks a model for each request based on quality, cost, performance, availability, and budget. External coding agents like Claude Code, Cursor, Codex, and Gemini CLI come under the same governance when their model traffic routes through a Databricks model service, and a launcher CLI called ucode writes each agent's configuration.

Around that core, Unity Catalog registers models, agents, MCP services, and skills as securables, governed with the same privileges and ABAC grant policies a Databricks team already uses for tables and volumes. Service policies (in Beta) can allow, deny, or require approval on individual requests and responses, and inference tables log raw request and response payloads to Delta tables. The GA announcement reports thousands of customers, including Rivian, Asana, and Edmunds, and says over a quadrillion tokens passed through the gateway in the past year. Zepto, quoted in the announcement, reports production scale above 100 billion tokens per month.

What is the Speakeasy AI Control Plane?

Speakeasy is an AI Control Plane anchored in enterprise identity. Every agent session resolves to a principal the directory already knows, synced from Okta or Entra, and one permission model covers humans and agents across every platform they touch. Enforcement runs on two surfaces: the MCP gateway, which sits between agents and the systems they act on, and agent hooks, which govern the agent loop from inside the client.

The gateway authenticates every session with OAuth 2.1, dynamic client registration, and PKCE, even when the upstream server supports none of that, and checks per-server and per-tool grants on each call. Hooks are the second surface, and they are what make the architecture more than a gateway. Inside Claude Code, Claude Cowork, Cursor, Codex, and OpenCode, a hook sits between the agent deciding to act and the action executing, so it can inspect, allow, or block a prompt, a retrieval, a shell command, or a tool call before anything happens, including traffic that never reaches a hosted gateway. The device agent keeps those hooks in place: it deploys fleet-wide through an MDM such as Kandji, Jamf, or Intune, sets identity and enrollment centrally with no per-user setup, and reconciles required configuration on macOS, Windows, and Linux every 60 seconds. Across both surfaces, risk policies scan prompts, responses, and tool calls inline, shadow MCP detection builds an inventory of the servers nobody registered, and costs and budgets key on directory attributes.

One thing the platform does not do is broker or route model traffic. A LiteLLM integration adds a pre-call guardrail for model traffic an organization already routes through LiteLLM, and the Speakeasy Agents API is in early beta without rate limiting, caching, or failover. Neither counts as an LLM gateway, and this post does not treat them as one.

How do the architectures differ?

Four differences separate the products: what governance is anchored to, where traffic gets intercepted, how much of the AI estate each one covers, and who inside the organization ends up running it. Everything in the capability sections below traces back to these four.

Anchors: the catalog or the directory

Unity AI Gateway anchors governance in the data platform. Models, agents, MCP services, and skills are Unity Catalog securables, so a Databricks team governs them with the same privileges and ABAC grant policies it already uses for tables and volumes (see the AI governance guide). If your team lives in Unity Catalog, that is exactly the appeal: there is no second access model to build for AI.

Speakeasy anchors governance in enterprise identity. The permission subject is a directory principal, either a person synced from Okta or Entra, or an Agent Identity (currently in early access) synced from the provider or created in the platform. Joiner, mover, and leaver events flow straight from the identity provider, so a deprovisioned user loses agent access automatically, with no catalog to reconcile. For a security team the trade cuts the opposite way: grants live in the system the directory already governs, and there is no second permission model to learn, but there is also no lakehouse lineage attached to them. Extending IAM to agents explains why we chose identity as the anchor.

Chokepoints: the model call or the tool call

Unity AI Gateway intercepts the model call. It began life as a governed LLM proxy, applying rate limits, logging, and guardrails at inference time, and it governs external coding agents by routing their model traffic through a Databricks model service. MCP Services extend the same interception to tool calls, as long as the servers are registered in Unity Catalog. In other words, governance follows from re-pointing traffic: an agent is governed once its model requests, and optionally its registered tool calls, flow through Databricks.

Speakeasy intercepts the action, at two points. On the network path, the MCP gateway sits between every agent and every system the agent acts on. Inside the client, agent hooks govern the agent loop itself, seeing each prompt, retrieval, shell command, and tool call at the moment the agent decides to act, and MDM deployment is what makes that surface dependable at fleet scale rather than a per-developer opt-in. Because the coding agent is itself an enforcement point, governance never requires re-plumbing where inference happens. An organization keeps its existing model contracts and routers, and the control point is the moment intent becomes action: the tool call that reads the customer table, files the ticket, or pushes the branch.

Estates: the lakehouse slice or the whole company

Unity AI Gateway is strongest on the Databricks-shaped slice of an AI estate: agents acting on lakehouse data, teams already operating Unity Catalog, and model consumption the platform can meter. Within that slice, permissions, lineage, audit, and runtime policy all live in one system.

Speakeasy is built for everything else. Employees run AI clients against SaaS applications, internal APIs, and databases, and most of that activity never touches the lakehouse. The support agent calling a billing API, the developer with an unsanctioned MCP server in an editor config, and the analyst on a personal AI subscription all sit outside a catalog-scoped perimeter. They are exactly what an identity-anchored control plane is built to see.

Buyers: the data platform team or the security function

The natural Unity AI Gateway buyer is the data platform team, which already owns Unity Catalog and can extend it to AI assets without bringing in a new vendor. The natural Speakeasy buyer is the CISO or the IT function responsible for all AI usage, whose scope is every employee and agent rather than a single platform.

That asymmetry matters for adoption, and it is not a flaw in either product. A team with no Databricks relationship is unlikely to adopt a lakehouse vendor as its company-wide AI control point. Routing all prompt traffic through a data platform vendor also raises data sovereignty questions a security review will surface, because inference tables log full request and response payloads into storage the vendor operates. In the other direction, a Databricks-first organization gets meaningful governance from a platform it already trusts, and mainly needs to ask whether its AI estate really ends at the lakehouse boundary.

How do the security capabilities compare?

Both products can inspect AI traffic and block policy violations in flight. The difference is where they stand while doing it. Unity AI Gateway enforces at the gateway, on traffic routed to it, with service policies in Beta and a partner ecosystem for deeper detection that is announced but not shipped. Speakeasy enforces natively at the gateway, in MDM-deployed agent hooks inside the agent loop, and on the device, and it can detect the servers and clients nobody registered.

On Databricks, service policies (in Beta) evaluate each request before a service is invoked and each response after it returns. Built-in policies use an LLM judge to block unsafe content, jailbreak attempts, and hallucinated responses, and a deterministic sensitive-data policy blocks or redacts matches like Social Security and credit card numbers. Contextual service policies, launched in Beta at Data + AI Summit 2026, are genuinely strong. They allow, deny, or require approval on individual actions based on the user, agent, model, MCP service, tool, or the content of the request, so an admin can require human approval before a coding agent pushes code to GitHub or restrict writes to sensitive folders. Databricks has also announced a partner ecosystem of upcoming integrations with AI security vendors, including CrowdStrike, Palo Alto Networks, and Zscaler. Those are announced integrations, not shipped product.

Speakeasy ships detection and enforcement as one system, and its security properties come from sitting in the traffic path rather than from a scoring layer bolted on beside it. Risk policies run a prompt injection heuristic, with an opt-in LLM judge, on tool inputs and outputs. Sensitive-data detectors block secrets, financial data, and PII in real time across prompts, assistant messages, tool calls, and tool responses, rather than only logging them. Natural-language guardrails can be replayed against recent live sessions to produce a scorecard before enforcement is turned on, and CEL rules cover the precise cases. There is also one capability a catalog-based model structurally cannot offer: shadow MCP detection. Agent hooks see the MCP servers employees configured directly in their editors, build an inventory from live traffic, and apply an allow-or-block posture with a request-access flow. That is governance of what was never registered. Every action lands in an audit trail correlating the prompt, the directory identity, the tool call, and the downstream API behavior in one record, and the platform holds SOC 2 Type II and ISO 27001, per the security page.

How do the governance capabilities compare?

Governance is where the anchor choice shows up most clearly. Unity AI Gateway governs through Unity Catalog, so assets are securables, access is grants and ABAC policies, and audit lands in system tables next to the data lineage. Speakeasy governs through the identity provider, so access is granted to directory principals, policy follows the org chart, and every call carries the caller's directory state into the audit log.

A Speakeasy session resolves to a principal from Okta, Microsoft Entra ID, Auth0, WorkOS, Google Workspace, Ping Identity, or any SAML or OIDC provider. Directory sync keeps users, groups, and attributes current, and deprovisioning removes access. Agent Identity, in early access, gives agents principals of their own, synced from providers that model them natively or created in the platform, and the same permission model that evaluates people evaluates them. Role-based access applies at the server, the toolset, and the individual tool, with each tool's disposition derived from its MCP annotations and a deny pass that beats allow.

On Databricks, the permission subject is a workspace user or service principal, and the permission object is a catalog securable. You grant EXECUTE on an MCP Service the same way you grant it on a table, filter which tools the service exposes, and audit invocations in system tables. Managed MCP services for Google Drive, Jira, Confluence, Slack, GitHub, and SharePoint were announced at Summit 2026, and their integration with Unity AI Gateway is in Beta per the August release notes. For a security team whose source of truth is the IdP, though, this is a second permission system to learn and reconcile, and it reaches only as far as what is registered in the catalog. Databricks has announced upcoming identity integrations with Okta, Ping Identity, SailPoint, and Saviynt in its partner ecosystem blog; for now, that is an announced ecosystem rather than shipped IdP-native agent identity.

How do cost visibility and spend control compare?

Unity AI Gateway has the deeper cost model for routed traffic, and Speakeasy has the wider one. Databricks meters tokens at the gateway with hard budget caps, and it sees nothing that does not route through it. Speakeasy sits on the client side of the path, so spend is visible in real time across personal licenses, enterprise seats, provider APIs, and model routers, including the spend nobody routed anywhere.

The Databricks cost stack is a real strength. Token-level attribution spans models, providers, teams, and applications. Budgets enforce per-user thresholds and hard caps that stop requests once exceeded. Dashboards and Genie-powered analysis come out of the box, and inference tables hold the payloads behind every number, per the GA announcement. Smart Routing (in Beta) goes a step further and picks a route for each request on quality, cost, performance, availability, and budget. For model consumption an organization routes through Databricks, this is as good as gateway-side cost control gets.

The catch is the routing condition. A personal Claude subscription, a Cursor seat billed to a team card, or an agent pointed straight at a provider API never touches the gateway, so the gateway never sees it. Shadow spend and shadow AI are the same blind spot: the usage you cannot meter is also the usage you cannot govern. Speakeasy watches from the client side of the path, where that usage actually happens. Agent hooks meter sessions and per-turn cost in real time instead of reconciling invoices after the month closes. 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 sessions from personal or off-domain accounts. Budgets are per-person rules keyed on directory attributes like department and cost center, warning at 80% and blocking in Claude Code, Codex, and Cursor. An enrollment view shows who is instrumented and which of their AI accounts are team accounts versus personal ones.

Where is each product the better fit?

Choose Unity AI Gateway when the estate is Databricks-shaped:

• Your agents mostly act on lakehouse data, and you would rather keep permissions, lineage, audit, and runtime policy in one Unity Catalog system than stitch together separate tools.
• You want model routing and token economics from the platform vendor you already run: Foundation Model APIs, fallbacks, Smart Routing (Beta), and hard spend caps on metered traffic.
• Your governance scope is the Databricks estate, and pointing coding agents at a model service through ucode is not a source of friction.
• Contextual approval on registered actions matters to you, and you can accept the Beta label on contextual service policies while they mature.

Choose Speakeasy when the frame is company-wide AI governance:

• Your AI usage spans clients and systems well beyond any one platform: SaaS, internal APIs, and databases that never touch a lakehouse.
• The buyer is the security or IT function, and governance has to anchor in the IdP you already run rather than in a second permission system.
• You need shadow-AI discovery and personal-license visibility, meaning the MCP servers and AI subscriptions nobody registered or routed.
• Every action needs a directory identity behind it, for people now and for agent identities as they arrive.

The two can also coexist, and the split is clean because the chokepoints differ: Unity AI Gateway routes and meters model traffic for lakehouse agents, while Speakeasy acts as the identity-anchored control plane across every client and system. That arrangement works well until the question becomes company-wide AI governance. At that point one product has to own the whole path, and that is the control-plane role.

The questions that decide the choice

• Where does your AI usage actually live? If most agent activity touches lakehouse data, Unity AI Gateway governs it where it happens. If most of it runs against SaaS, internal APIs, and coding tools, the estate is wider than any catalog.
• What is your source of truth for who may act? If the answer is Unity Catalog, Databricks extends it to AI assets. If the answer is Okta or Entra, Speakeasy makes the directory the permission system for agents too.
• Can you see the AI usage nobody routed? Ask each vendor how a personal Claude license, or an MCP server added straight to an editor config, shows up. On Databricks it does not, until it is routed or registered. On Speakeasy, that discovery is the product.
• Are you willing to re-plumb model traffic? Unity AI Gateway governs agents once they point at a Databricks model service. Speakeasy governs the agents you already run, through hooks your MDM deploys, with model contracts unchanged.
• Who signs off, and on what scope? A data platform team consolidating its estate and a CISO answering for every employee's AI usage are different buyers with different perimeters, and each product is built for one of them.
• Which Beta labels can you live with? Smart Routing, service policies, contextual service policies, and agent services are Beta on Databricks; Agent Identity is early access on Speakeasy. Match the labels against the controls your rollout depends on.

Where the Speakeasy AI Control Plane fits

Unity AI Gateway governs the Databricks estate well, and for lakehouse-native agents it is the obvious starting point. The Speakeasy AI Control Plane is built for the rest of the map: every client, every system, every principal, governed through the identity provider you already run. If the question on your desk is company-wide AI governance rather than platform-scoped governance, that is the product to evaluate.