In One Minute
The Databricks AI gateway is now called Unity AI Gateway. It went generally available on 4 August 2026 and puts models, agents, coding agents and MCP servers behind one governed layer. That gives you Unity Catalog permissions, spend caps, runtime guardrails and cost attribution for each call. Smart Routing is still Beta.
- What it governs: who can call which model, agent or tool, how much they can spend, and what gets logged.
- GA today: the core control plane, cost tracking and attribution, runtime guardrails and policies, budgets and spend caps.
- Still Beta: Smart Routing. Treat MCP-specific controls as Beta until your cloud’s release notes say otherwise.
- Effort: an inventory of AI assets and owners comes first. The gateway configuration is the short part.
On most mid-market lakehouse platforms I review, nobody decided to run fifty AI integrations. They accumulated. A finance analyst wired a model into a notebook, a developer connected a coding agent to the repo, someone in support stood up a chatbot, and each one carries its own API key and its own bill. Nobody can say what all of it costs per month, or which identity read which table.
Databricks answered that problem in June at Data + AI Summit, when it announced Unity AI Gateway, and made it generally available on 4 August 2026. The announcement frames it as cost, control and choice levers across coding agents, MCP servers, external agents, skills and models. That is marketing language. This article translates it into the operational controls a data team actually configures, and it is explicit about which pieces you can run in production today.
The underlying problem is old. Every AI call is a request from an identity to a resource. If you cannot answer who made it, what it touched and what it cost, you do not govern it, whatever the product page says.
What Is Unity AI Gateway, and What Happened to the Old Name?
Unity AI Gateway is a governance layer that sits between callers and AI services. Callers are people, applications, agents and coding assistants. AI services are foundation models hosted on Databricks, external models from other providers, MCP servers and custom tools. Every request passes through the gateway, which checks permissions, applies policy, enforces limits and records what happened.
Older Databricks material and many third-party posts use the name Mosaic AI Gateway. When you check feature status, search for the current name, Unity AI Gateway, which current documentation also shortens to Unity Gateway. Older pages describe an earlier, narrower scope, and planning from them will mislead you about what the product covers now.
The design choice that matters is the word Unity. According to the gateway documentation, AI assets are registered as Unity Catalog securable objects, so you grant and revoke access to a model or an MCP service with the same privilege model you already use for tables, views and volumes. Your AI governance and your data governance stop being two systems with two sets of admins.
What Does “Governed” Mean Operationally?
Strip away the adjectives and governance comes down to four mechanics. If a vendor cannot show you each one in a live workspace, it is not governance yet.
Identity and permissions
Every caller authenticates as a known principal, and every AI asset carries grants. A support agent’s service principal can be granted one model and one MCP tool, and nothing else. Because those grants live in Unity Catalog, the same access review that covers your gold tables can cover your models and tools. Revoking an agent becomes one grant change instead of a hunt for API keys in config files.
Routing
Routing decides where a request goes. The documentation describes traffic splitting across destinations and failover configurations for availability, which lets you move a workload from one provider to another without changing application code. Smart Routing goes further and picks a model per request based on quality, cost, performance, availability and budget. That automatic selection is the part still in Beta.
Caps and limits
The GA announcement says teams can set proactive budgets and enforce hard spend caps, and the documentation describes rate limits on model services and MCP services plus per-user budget thresholds. In plain terms: a runaway agent loop hits a ceiling instead of your invoice. Set caps per team or per application, so one experiment cannot spend another team’s quarter.
Logging and attribution
The community GA announcement lists cost tracking and attribution across users, teams, applications, models and providers. The documentation adds usage tracking through system tables and inference table logging of requests and responses to Unity Catalog Delta tables. That is the piece that turns governance from a policy document into evidence. Request, identity, cost and response land as rows on the lakehouse, next to the data the agent read.
Which Parts Are GA and Which Are Still Beta?
Status labels move fast, and the GA announcement does not cover every documented feature by name. The table separates what Databricks has stated as GA from what is Beta or unlabelled, as of 8 October 2026.
| Capability | Status as of 8 Oct 2026 | Where it is stated | What it means for planning |
|---|---|---|---|
| Core gateway and unified control plane | GA since 4 Aug 2026 | Databricks GA blog and community announcement | Safe to design production access around it |
| Cost tracking and attribution by user, team, app, model and provider | GA | Community announcement | Use it for chargeback and budget reviews now |
| Runtime guardrails and policies on prompts, responses, agent actions and tool calls | GA | Community announcement | Build PII and injection policies into the first rollout |
| Budgets and hard spend caps | GA | Databricks GA blog | Set caps before you widen access, not after |
| Smart Routing across models | Beta | Databricks GA blog and community announcement | Pilot on low-risk workloads; do not depend on it for a cost forecast |
| MCP-server specific governance controls | Treat as Beta; MCP servers are named in the GA scope | Reported Beta in an April 2026 release note; docs carry no label | Check your cloud’s release notes before calling an MCP control production-grade |
| Traffic splitting, failover, inference table logging | Documented; no status label on the overview page | Gateway documentation | Confirm the label on the feature’s own docs page for your cloud |
One discipline from Lean Six Sigma applies here directly: plan on the measured state, not the announced one. If a control is Beta, write it into the plan as Beta, with a named fallback, and revisit it at the next release cycle.
What Goes Wrong When Teams Switch On a Gateway Without a Plan?
The most common failure is turning the gateway on before anyone knows what sits behind it. A team registers the three models it remembers, sets a generous budget, and declares victory, while the coding agents and the chatbot built last spring keep calling providers directly with personal keys. The gateway then governs the traffic that was never the problem. Spend keeps leaking through side doors, and the dashboard shows a reassuring number that is simply incomplete.
The second failure is shared identities. If every agent runs as one service principal, cost attribution collapses into a single line and the logs cannot tell a support bot from a finance agent. You have bought observability and configured it to see nothing. The third is guardrails with no owner. A PII policy blocks a legitimate request, a business user complains, someone loosens the policy for everyone, and nobody records why. In AIM-IT terms, each of these is skipping Assess: automating access before you have mapped the process and the people who own it.
How Does the Gateway Fit With Agent Bricks and Unity Catalog?
Think of three layers. Unity Catalog governs the data: tables, views, volumes, lineage and grants. Agent building tools, including the ones we cover in our guide to Databricks Agent Bricks, are where you assemble and evaluate agents. The gateway governs the calls those agents make outward, to models and tools, and records them.
The value is that all three share one identity and permission model. An agent’s service principal holds grants on the gold views it may read and on the model and MCP tools it may call. Both sets of grants sit in one catalog, so one access review covers the whole path from prompt to table. If your catalog is not yet in that shape, start with our walkthrough of Unity Catalog, because a gateway inherits whatever permission sprawl sits underneath it.
On a lakehouse, the logs complete the picture. Gateway usage records, inference tables and Unity Catalog lineage can be joined on identity and time. When an auditor or your CFO asks which agent read customer data last Tuesday and what it cost, the answer is a query, not a project.
Where Should You Start This Quarter, in Order?
Run these in sequence. Each step produces the input the next one needs.
- Inventory every AI caller and service. List models, agents, coding assistants, chatbots and MCP servers, each with an owner, an identity and a monthly cost estimate. Include the ones calling providers directly.
- Give each agent its own service principal. Retire personal tokens and shared keys. Without separate identities, attribution and logs are blind.
- Register assets in Unity Catalog and grant narrowly. One model and the specific tools each agent needs, pointed at curated gold views rather than raw tables.
- Set budgets and spend caps per team. Start tight, then raise caps on evidence from the usage data, not on request.
- Write guardrail policies with named owners. PII and prompt-injection policies first, each with a person who approves exceptions and a log of every change.
- Close the side doors. Revoke direct provider keys once traffic flows through the gateway, so the dashboard reflects reality.
- Baseline, then pilot the Beta features. Collect a few weeks of usage, then test Smart Routing on a low-risk workload and compare cost and quality against the baseline.
If you want that sequence designed and built on the platform you already run, our AI on the lakehouse practice sets up agent identities, gateway policy, spend caps and the logging that proves all three.
Frequently Asked Questions (FAQs)
Is Mosaic AI Gateway the same as Unity AI Gateway?
Mosaic AI Gateway is the older name you will find in earlier Databricks material and third-party posts. The product Databricks made generally available on 4 August 2026 is Unity AI Gateway, also shortened to Unity Gateway in current docs. Use the current name when you check what is GA.
Is the Databricks AI gateway generally available?
Yes. The core gateway reached general availability on 4 August 2026, including cost tracking and attribution, runtime guardrails and spend caps. Smart Routing remains in Beta, and MCP-specific controls should be treated as Beta until your cloud’s release notes confirm otherwise.
Does Unity AI Gateway work with external models?
Yes. Databricks describes it as governing both Databricks-hosted and external AI services, including external agents, coding agents and MCP servers. Policies, limits and attribution apply through the same control plane regardless of provider.
Do we need a gateway if we only run a few models?
A small estate is the cheapest time to add one, because the inventory is short and the policies are simple. Retrofitting identities and caps after dozens of direct integrations exist takes far longer than starting with one governed path.