Databricks Unity AI Gateway: MCP and Agent Governance Guide 2026

Every enterprise AI team in 2026 is facing the same silent crisis: AI agents are proliferating faster than governance can keep up. Coding agents spin up MCP servers. Product agents query internal APIs with service accounts that bypass row-level security. Data agents pull from Delta tables without audit trails. The tools are moving at startup speed; the compliance requirements are not.

Databricks’ answer, announced in mid-April 2026, is the Unity AI Gateway — a rebranding and significant expansion of the existing AI Gateway product that brings AI agents and MCP servers directly under the Unity Catalog governance umbrella. If you already govern your data with Unity Catalog, you can now govern everything your agents do with that data — including every LLM call, every tool invocation, and every external MCP server interaction — through the same permissions, audit logs, and policy engine.

This guide covers what Unity AI Gateway is, what changed from the previous AI Gateway, how MCP governance works technically, what AgentBricks adds to the stack, and how to get started if you are running agents on Databricks today.

What Changed: AI Gateway Becomes Unity AI Gateway

The previous Databricks AI Gateway was primarily a proxy — a layer that sat in front of LLM endpoints and enforced rate limits, logged requests, and provided basic guardrails. It was useful but scoped: it governed the LLM call, not the broader agent workflow.

Unity AI Gateway fundamentally expands this scope in three directions:

• From LLM endpoints to MCP servers: External tools (GitHub, Jira, Salesforce, your internal APIs) are now first-class governed objects registered in Unity Catalog, with the same access control primitives as tables and volumes.
• From service accounts to user identities: On-behalf-of (OBO) execution means agents act as the requesting user, not a shared service account. A user without access to a record cannot get that record through an agent.
• From request logging to end-to-end observability: MLflow Tracing captures every LLM call, every tool invocation, and every MCP interaction in a single trace, with Unity Catalog audit logs showing identity and access patterns across the full agent session.

The result is that the governance model for a governed Databricks Delta table — role-based access, column-level masking, row filters, attribute-based policies, audit logging — now extends all the way to the tools an AI agent uses to read or write that data.

The MCP Governance Problem Unity AI Gateway Solves

The Model Context Protocol has grown from an Anthropic specification to a de facto standard for tool use in AI agents. With 97 million MCP server installs worldwide, agents can now connect to virtually any external system — from GitHub repositories to Salesforce CRM to internal databases — through a standardized protocol.

That growth created an enterprise governance vacuum. When an agent calls an external MCP server, several things happen that traditional security controls were not built to handle:

1. Identity loss: Most MCP implementations run under a shared service account. An agent executing on behalf of a sales rep has the same data access as an agent executing on behalf of a database administrator — and there is no distinction in the audit log.
2. Inventory blindness: There is no centralized registry of which MCP servers exist, which agents use them, or which data they touch. Sprawl is invisible until it causes an incident.
3. Observability gaps: When an agent misbehaves — leaks data, makes unauthorized calls, incurs unexpected costs — there is no single place to see what it did. LLM calls logged in one place, tool calls logged elsewhere, database access not logged at all.

Unity AI Gateway addresses each of these directly. Every external MCP server is registered in Unity Catalog as a governed catalog object. Agents connect to MCP servers through the gateway, which enforces identity, logs every interaction, and applies the same guardrails as LLM calls.

How On-Behalf-Of Execution Works

On-behalf-of (OBO) execution is the technical mechanism that makes per-user identity enforcement possible in multi-agent workflows. It is worth understanding how it works under the hood, because it changes what is architecturally safe to build.

Without OBO, the typical agent flow looks like this: a user triggers an agent; the agent runs under a service principal with broad permissions; the agent calls an MCP server using that service principal’s credentials; the MCP server executes with full service account access regardless of what the triggering user is actually authorized to see.

With OBO through Unity AI Gateway, the flow becomes: a user triggers an agent; the gateway intercepts the agent’s outbound MCP call; the gateway exchanges the agent’s service credential for a short-lived, scoped credential bound to the triggering user’s identity; the MCP server receives a call authenticated as that specific user and enforces their exact permissions.

The practical result: an MCP server connecting to your internal customer data system cannot retrieve records the requesting user cannot see in the UI. Row-level security and column-level masking that govern direct database access apply equally to agent-mediated access. The agent cannot exceed the authorization of the human who triggered it.

Databricks handles OAuth app registration, token exchange, and token refresh automatically. From the agent developer’s perspective, you register the external MCP server in Unity Catalog and select “Per-User OAuth” as the auth mode — Databricks takes care of the plumbing.

AgentBricks: The Governed Agent Platform

Unity AI Gateway is one component of Databricks’ broader AgentBricks platform, which the company positions as the governed enterprise agent platform. Understanding where the gateway fits within AgentBricks clarifies what you actually get at each layer.

Data Intelligence

Agents built on AgentBricks have access to Unity Catalog’s data intelligence capabilities: automatic semantic tagging, table relationship inference, and query optimization for natural language-to-SQL workflows. An agent asked to “find customers who churned last quarter” can navigate your catalog’s schema, find the right tables, apply row filters that respect the user’s data access, and generate an accurate query — without ever seeing data it should not see.

Unity AI Gateway

The governance and enforcement layer. Every LLM call, every MCP server interaction, and every coding agent action passes through Unity AI Gateway, which enforces permissions, applies guardrails, logs audit events, and tracks costs. It is the enforcement plane for everything an agent does.

MLflow Tracing

End-to-end observability. MLflow Tracing instruments every step of an agent’s execution — including the model call, the tool selection, the MCP server invocation, and the final response — into a single queryable trace. Combined with Unity Catalog audit logs, you can reconstruct exactly what an agent did, why it did it, and what data it touched, down to the individual request.

Mosaic AI Agent Framework

The agent development framework that ties everything together. It handles agent memory, tool registration, multi-agent coordination, and deployment, with native integrations to Unity AI Gateway and MLflow Tracing so governance and observability are automatic rather than opt-in.

Setting Up Governed MCP Servers: A Developer Walkthrough

If you have existing MCP servers you want to bring under Unity AI Gateway governance, the setup process is straightforward. Here is the step-by-step.

Step 1: Register the External MCP Server

Navigate to AI Gateway → Connections → Register MCP Server → External MCP in the Databricks workspace UI. You will need the server’s base URL, an authentication mode, and the OAuth scopes the server requires. Choose Per-User OAuth for any connection that touches user-specific data — Databricks handles OAuth app registration, token exchange, and token refresh automatically. Choose Shared Principal for system-level tooling where user identity is not relevant to access decisions.

Once registered, the MCP connection appears in Unity Catalog under the system.ai schema alongside your existing model endpoints — a single namespace for all governed AI resources in the workspace.

Step 2: Grant Access in Unity Catalog

The registered MCP server is now a Unity Catalog object with standard privilege semantics. Grant access using familiar SQL:

GRANT USE_CONNECTION ON CONNECTION my_github_mcp TO "data-analysts";
GRANT USE_CONNECTION ON CONNECTION my_salesforce_mcp TO "sales-team";
REVOKE USE_CONNECTION ON CONNECTION my_prod_db_mcp FROM "contractors";

Groups, service principals, and individual users are all supported. The same role-based access model that governs table access now governs which agents — and more specifically which human identities behind those agents — can call external tools.

Step 3: Configure Guardrails

Unity AI Gateway guardrails apply at the LLM and MCP layer equally. Available guardrails include PII detection and masking (automatic for common patterns, configurable for custom entity types), prompt injection detection (flags attempts to override agent instructions through injected content in tool responses), data exfiltration prevention (blocks attempts to route sensitive data through MCP calls to unauthorized destinations), and response validation (ensures tool responses conform to expected schemas before being passed to the LLM).

Step 4: Enable MLflow Tracing

If you are using the Mosaic AI Agent Framework, tracing is automatic. For custom agents, you can instrument traces directly through the MLflow SDK. Once enabled, every request appears in the MLflow Experiments UI with latency breakdowns, cost attribution by LLM provider, and full drill-down into each tool call and MCP server interaction. Unity Catalog audit logs capture the identity behind each action, making the trace both operational and compliance-ready.

Coding Agent Sprawl: The Problem Unity AI Gateway Targets

One of the less-discussed dimensions of the April 2026 announcement is Databricks’ specific treatment of coding agent sprawl. Coding agents — tools like Claude Code, Cursor, and GitHub Copilot — are being adopted at scale in enterprise engineering organizations, and each connects to MCP servers to access code repositories, CI/CD systems, internal APIs, and documentation.

The governance problem: each agent instance creates its own OAuth tokens, its own tool connections, and its own audit trail (or more often, no audit trail at all). After a few months of team-wide adoption, a typical enterprise has dozens of shadow MCP servers that IT has no visibility into. Security teams cannot tell whether a coding agent is accessing production secrets. Finance teams cannot attribute AI infrastructure costs to projects. Compliance teams cannot produce audit logs when asked by a regulator.

Unity AI Gateway addresses this through a central MCP registry. Any MCP server accessed through a governed coding agent must be registered in Unity Catalog. The gateway enforces which engineering identities can access which repositories and systems, and every tool call — including code reads, API queries, and test runs — is logged with full identity attribution. Managers can see which engineers used which agent capabilities; security teams can audit for anomalous access patterns; finance teams can attribute AI infrastructure costs to teams and projects with the same granularity as cloud compute costs.

What This Means for AI Teams in 2026

The Unity AI Gateway announcement reflects a broader shift in enterprise AI adoption: the question is no longer whether to adopt AI agents but how to adopt them safely at scale. The governance gap between what agents can technically access and what they should be permitted to access has been the primary blocker for security-conscious enterprise deployments in 2025 and early 2026.

By integrating agent and MCP governance directly into Unity Catalog — which many enterprises already use as their data governance layer — Databricks is making a bet that data governance and AI governance should converge rather than remain siloed. Security teams that already understand Unity Catalog permissions do not need to learn a new system to govern AI agents. The same RBAC model, the same audit log queries, the same policy engine now applies to everything an agent does.

For developers, the practical implication is that governed agent deployments no longer require a separate governance layer to be bolted on after the fact. If you build your agent using the Mosaic AI Agent Framework and route its tool access through Unity AI Gateway, you get identity enforcement, audit logging, cost attribution, guardrails, and end-to-end observability as default behavior — not as an afterthought.

The competitive framing is also worth noting. Google Cloud announced the Gemini Enterprise Agent Platform at Cloud Next 2026, and Microsoft has developed its Agent Governance Toolkit as an open-source project. Databricks’ differentiator is the depth of its data governance integration: Unity Catalog already governs petabytes of enterprise data at thousands of organizations, and Unity AI Gateway extends that existing trust boundary to AI agents rather than introducing a parallel governance system that teams must learn, configure, and maintain separately.

Getting Started

Unity AI Gateway is generally available to all Databricks workspace users as of April 2026. The migration path from the previous AI Gateway is non-breaking: existing LLM endpoints and configurations carry over automatically. MCP governance is additive — you opt external servers in by registering them, without changes to agents that use servers you choose not to govern centrally.

The recommended starting point for most teams: identify your three highest-risk MCP connections first — typically the ones with access to production databases, customer data, or internal financial systems — register them with Per-User OAuth, and monitor their audit logs for one week. You will likely discover access patterns that were previously invisible, and that discovery alone justifies the integration. Build your governance coverage incrementally from there rather than attempting to govern everything on day one.

The Bottom Line

The Databricks Unity AI Gateway represents the clearest enterprise answer to date to the question of how AI agent access to external tools should be governed at scale. By treating MCP servers as first-class Unity Catalog objects, enforcing per-user identity through OBO execution, and providing end-to-end observability through MLflow Tracing, it closes the governance gaps that have made security teams hesitant about wide-scale agent deployments.

For developers building enterprise agents on Databricks, the practical message is straightforward: register your MCP servers in Unity Catalog, enable Per-User OAuth for any connection that touches user-specific data, and enable MLflow tracing. Those three steps add minimal complexity to your development workflow and eliminate the most significant enterprise security objections to production agent deployment. In 2026, governed agents are deployable agents. Ungoverned agents are pilot projects waiting to become incidents.