Unity AI Gateway extends Databricks Unity Catalog to govern models, agents, and MCP services. A deep look at what it solves and where platform lock-in starts.
Databricks renamed its AI Gateway in April 2026. The new name, Unity AI Gateway, signals more than a branding refresh. It signals that AI Gateway is now part of Unity Catalog, extending the same permissions, auditing, and policy controls Databricks customers already use for data into the runtime layer where models, agents, and tools interact.
That extension solves a real problem. AI deployments are multi-model, multi-agent, and multi-vendor. Developers run coding agents. Business users query enterprise data through conversational interfaces. Internal teams launch custom agents for workflow automation. Governing all of that through scattered, siloed tools does not scale. Traditional governance tools weren't built for multi-step agentic workflows and cannot provide a unified view across an agent's full action chain.
Unity AI Gateway is Databricks' answer. It is also, by construction, a Databricks-only answer. Every capability described below assumes Unity Catalog as the substrate. That distinction matters if your AI stack spans more than one platform.
Unity AI Gateway lets teams set up a new LLM endpoint in seconds, choose a model (Claude Opus 4.6, GPT-4, Gemini, Llama, or any provider-native API), and configure governance once. The same framework applies across Anthropic, OpenAI, Google, and open-source models. One configuration, many providers, no duplicate setup per model family.
Admins can govern foundation model access through Unity Catalog using the same fine-grained access policies they use for data. Policies apply dynamically based on attributes like model provider, country of origin, or approval status. A finance team can restrict agents to approved models only. A compliance team can block models originating from specific jurisdictions. The policy engine evaluates these attributes at request time, not at deployment time, so controls adapt as model inventories grow.
Quartile, an e-commerce optimization company, uses this flexibility in production. They switch LLMs by use case through Unity AI Gateway, continuously tuning cost and quality across different pipeline types like listing optimization.
Most AI gateways track tokens. Unity AI Gateway tracks dollars. Every request gets logged to Unity Catalog system tables with actual dollar costs, calculated automatically across provisioned throughput, pay-per-token usage, and external model pricing. That distinction matters when your finance team asks what a specific agent costs per month and the answer requires reconciling three different billing models.
Two cost controls sit on top of the logging layer:
Udemy demonstrates the unified cost picture at scale. They route all foundation model traffic through the gateway as a single governance layer, from production agents running on Claude to PII detection pipelines that balance smaller and larger GPT models for cost efficiency. Everything governed consistently with unified access control and clear cost attribution.
Rigid keyword filters break agent workflows. Unity AI Gateway takes a different approach: LLM-based guardrails defined using a model and prompt, evaluated in real time. Instead of a static blocklist, you write a prompt that describes what should be caught, and the guardrail model evaluates each request against it.
The full guardrail taxonomy covers six categories:
| Guardrail | What It Does |
|---|---|
| PII Detection & Redaction | Masks emails, SSNs, phone numbers before they reach external models |
| Content Safety | Blocks toxic or inappropriate content with customizable filters |
| Prompt Injection Detection | Catches jailbreak attempts that try to override system instructions |
| Data Exfiltration Prevention | Prevents exposure of training data or proprietary content |
| Hallucination Guard | Validates responses against grounding sources |
| Custom Guardrails | User-defined rules using a custom prompt and model |
Each guardrail can be applied to inputs, outputs, or both. The custom guardrails category is where this gets interesting for domain-specific compliance. A healthcare team can define HIPAA-specific rules. A financial services team can enforce disclosure requirements. The guardrail adapts to the use case because it is a prompt, not a product feature request.
This is where Unity AI Gateway diverges most sharply from other AI gateways. MCP (Model Context Protocol) lets agents call external tools, but the protocol itself does not define who gets to call what, or how to audit those calls.
Unity AI Gateway adds three layers of MCP governance:
On-behalf-of (OBO) execution. When agents call MCP servers to access internal systems, the gateway supports on-behalf-of user execution. The MCP executes with the requesting user's exact permissions, not a shared service account. If a user cannot access a Salesforce record, neither can the agent, even with elevated privileges.
Service policies as SQL functions. Policies are defined in SQL as Unity Catalog functions and applied directly to MCPs. They are deterministic, auditable, and enforceable across all agent workflows. No YAML. No proprietary DSL. SQL that your data team already knows how to write and review.
Payload logging. Every request and response across model calls and MCP interactions gets captured and stored as system tables managed by Unity Catalog. When an agent does something unexpected, you have the full chain of calls to investigate.
Databricks also provides managed MCP services for applications including Google Drive, Jira, Confluence, Slack, GitHub, and SharePoint, so teams can connect common enterprise tools without building custom MCP servers.
Different teams need different views of the same system. Unity AI Gateway serves three:
FinOps gets system tables with dollar costs per request, per model, per endpoint. No manual mapping from tokens to spend. The cost data lands in Unity Catalog system tables automatically, queryable with SQL.
Engineering gets full payload logging. When an agent produces a bad response, engineers can trace the exact request and response chain across every model call and MCP interaction.
Platform teams get the unified governance view. CDK Global, an automotive technology company, described it this way: Unity AI Gateway gave them "one place to govern, observe, and monitor every LLM call, whether we're using Databricks foundation models or external providers", without slowing teams down.
Unity AI Gateway connects to the security and identity tools enterprises already run. The AI security integrations include CrowdStrike, Palo Alto Networks, HiddenLayer, Netskope, Zscaler, Cyera, Noma Security, Obsidian Security, Openlayer, and Alice. These protect prompts, model responses, agent actions, and MCP tool calls.
On the identity side, the gateway extends enterprise identity governance to AI agents through integrations with Okta, Ping Identity, and Saviynt. The logic mirrors how enterprises already govern traditional application access: same identity provider, same policy engine, applied to a new class of interactions.
Every capability above runs on Unity Catalog primitives. OBO identity resolution requires Unity Catalog's permission model. Service policies are SQL functions registered in Unity Catalog. Cost logging writes to Unity Catalog system tables. Payload logging stores to system tables managed by Unity Catalog. Guardrails evaluate within the Databricks runtime.
For teams fully committed to Databricks, this is a strength. One platform governs data, models, agents, tools, and costs. No integration seams. No governance gaps between layers.
For teams running multi-cloud architectures, or using frameworks and model providers outside the Databricks ecosystem, every one of those capabilities becomes a reason to migrate more workloads onto Databricks or to accept gaps in governance coverage. The gateway governs what it can see, and it can only see what runs through Unity Catalog.
That is the trade-off Unity AI Gateway presents. Deep, integrated governance if you are inside the platform. Partial governance, or no governance, if you are not. Teams that need the same primitives (routing, cost caps, guardrails, observability, MCP governance) across a framework-agnostic stack need an AI gateway that operates at the transport layer, independent of any single platform's catalog or runtime.