Unity AI Gateway — MCP Governance Finally Gets Structural

Databricks rebranded its AI Gateway as Unity AI Gateway on April 15, 2026, and the rebrand is the least interesting part. The real move: MCP servers are now first-class governed objects inside Unity Catalog — registered, permissioned, audited, and cost-attributed exactly like data assets. If your agents have been calling GitHub, Atlassian, and Salesforce through shared service accounts nobody reviews, Databricks just shipped the architecture that makes that practice indefensible in any enterprise procurement conversation.

TL;DR

• What: Databricks launched Unity AI Gateway — MCP servers are now governed objects in Unity Catalog with per-user on-behalf-of access, centralized audit logs, and PII guardrails
• Why it matters: First platform where MCP governance is structural, not bolted on — agents execute with the requesting user’s exact permissions
• Lock-in risk: Once audit trails, model routing, and tool permissions all live in Unity Catalog, switching costs compound fast
• Action: Treat this as the governance reference architecture for MCP at scale, but build your abstraction layer now

What Happened

Unity AI Gateway extends Unity Catalog’s existing governance model — the one already applied to tables, models, and feature stores — to agentic AI infrastructure. External MCP servers are registered in Unity Catalog, making them discoverable and governed like any other catalog object. Fine-grained permissions control which agents can access which external systems, and all activity lands in a centralized audit table.

The headline capability is on-behalf-of (OBO) user execution. When an agent calls an external MCP server to access GitHub or Glean, it executes with the requesting user’s exact permissions — not a shared service account. Admins can further scope OAuth permissions per connection, like restricting a GitHub integration to read-only repo access. This is not a proxy that wraps calls with a service token. The identity chain flows through.

On the observability side, MLflow Tracing now captures full request/response payloads, latency, and errors across both LLM endpoints and MCP tool calls. FinOps teams get dollar-level cost attribution by model, team, and workflow — actual spend, not just token counts.

Guardrails ship built-in: PII detection and redaction (emails, SSNs, phone numbers masked before they reach external models), content safety filters, and prompt injection detection. On April 28, Databricks confirmed that GPT-5.5 and Codex are available natively on the platform, governed through Unity AI Gateway from day one — including automatic failover if rate limits are hit.

Several of these capabilities launched in Beta. Databricks notes that some features do not incur charges during the Beta period, which is generous but also means production readiness varies. Teams should validate audit coverage before treating any of this as a compliance control.

# Conceptual: MCP server registration in Unity Catalog
unity_catalog:
  object_type: external_mcp_server
  name: github-repo-access
  auth: oauth_obo          # on-behalf-of user execution
  scope: read_only
  audit: system.access.audit_log
  guardrails:
    - pii_detection
    - prompt_injection_blocking

Why This Matters

MCP proliferated through 2025 and into 2026 with essentially zero governance infrastructure. Every serious engineering org now has agents calling external APIs — GitHub for code context, Atlassian for project state, Salesforce for customer data — and the overwhelming pattern is a shared service account with broad permissions, no per-user audit trail, and cost attribution that amounts to “the AI budget line item went up.” This worked when three developers were experimenting. It does not work when 200 agents are running in production.

The fundamental problem is not that teams are careless. It is that no platform offered structural governance for MCP. You could bolt on OAuth scoping manually, build your own audit pipeline, instrument cost tracking per team — but each of those is a custom project, maintained separately, and none of them talk to each other. Unity AI Gateway is the first production offering where these capabilities are integrated into a single governance surface.

Databricks explicitly frames part of this as solving what they call “coding agent sprawl” — the security review bottleneck created when organizations need to separately vet Cursor, Codex, and other AI coding tools, each with different MCP integrations and auth models. Unity AI Gateway centralizes auth and billing across all of them simultaneously. Instead of reviewing five different tools’ security postures, you review one governance layer and route all tools through it.

This matters beyond Databricks customers. The pattern — treat MCP servers as governed catalog objects with identity passthrough — is the correct architecture for anyone deploying MCP at scale. Whether you build it yourself or buy it from Databricks, the principle is the same: agents should never have more permissions than the user who triggered them, and every tool call should produce an auditable record tied to a specific human identity.

Compare this to the MCP backlash debate from earlier this year: much of the criticism centered on MCP’s implicit trust model and the lack of governance primitives in the protocol itself. Unity AI Gateway does not fix MCP the protocol — it wraps it in an enforcement layer that compensates for what the protocol lacks. That is pragmatic, even if it is not elegant.

Several Unity AI Gateway features launched in Beta. Databricks confirms Beta features do not incur charges, but that also means SLAs, audit completeness, and edge-case behavior are not guaranteed. Do not treat Beta governance as a compliance control until GA — validate audit coverage independently.

The JetBrains approach to central agent governance tackles a similar problem from the IDE side. The Databricks approach tackles it from the data platform side. Neither alone covers the full surface. But if you are running agents that touch both code and data, Unity AI Gateway is closer to a complete answer because it governs the model layer, the tool layer, and the data layer in one place.

Even if you are not on Databricks, adopt the OBO pattern now. Map every MCP connection to the requesting user’s identity, not a shared service account. When governance platforms mature — and they will — you want your auth model to already be per-user, not retrofitted.

The Take

I would treat Unity AI Gateway as the governance reference architecture for MCP at scale. The OBO identity model, the catalog-based registration, the unified audit trail across LLM and tool calls — this is what enterprise MCP governance should look like, regardless of vendor. The fact that Databricks shipped it first means they will define the expectations that procurement teams hold every other platform to.

But I would also build an abstraction layer on day one. Once your audit trail, model routing, tool permissions, and cost attribution all live in Unity Catalog, you have built a dependency that is expensive to unwind. Databricks knows this. The governance layer is the stickiest product they have ever shipped — stickier than the lakehouse, because you can migrate data but you cannot easily migrate a compliance audit trail. The value is real. The lock-in is also real. Go in with both eyes open: adopt the patterns, use the platform if it fits, but keep your MCP server definitions and permission models portable. The moment you cannot export your governance configuration to another system, you have lost negotiating leverage you will not get back.