Databricks Data + AI Summit 2026: Unity AI Gateway governs agents and MCP

Two weeks after Snowflake, it was Databricks’ turn. At Data + AI Summit in San Francisco in mid-June, the message was that agents are moving from experiments to production, and that the data platform should be where they are governed. The tool for that is Unity AI Gateway, which extends Databricks’ data catalogue to models, agents and MCP services.

What Databricks announced

Unity AI Gateway builds on Unity Catalog, which many companies already use to govern tables and files. According to Databricks, it now also covers:

• Models, agents, MCP services and skills as governed assets, with the same kind of access control as data.
• Cost control, with spend visible across models and providers, costs split by user, team, tool and use case, hard spend caps and routing based on quality and cost.
• Runtime controls, such as approval steps and guardrails for sensitive actions like pushing code or reading data. The most advanced policy type, Contextual Service Policies, is in beta.
• Detection of personal data and prompt injection, and full traces of what agents do.

At the same time, Databricks expanded Agent Bricks, its platform for building agents. It supports open-source frameworks such as LangGraph, Agno and CrewAI, as well as the agent SDKs from Anthropic and OpenAI. MCP support in Unity Catalog lets agents connect to services such as Google Drive, Jira, Slack and GitHub. Databricks says more than 100,000 agents have been built on Agent Bricks.

Why it matters

Like Snowflake, Databricks wants to be more than the place where data is stored. It wants to be the control plane for the agents that use the data, and for the tools those agents call. The choice to put models, agents and MCP services in the same catalogue as data is logical: many access questions for agents are really data access questions.

For integration teams, the overlap is clear. MCP gateways, cost control for AI and guardrails are also offered by iPaaS vendors, API management vendors and cloud providers. A company that uses Databricks for data and an iPaaS for integration may soon have two places that both claim to govern the same agent.

How it compares

Databricks’ strength is where the data already is. An agent that mostly reads and analyses data in the lakehouse is natural to govern there. An agent that mostly acts in ERP, CRM and HR systems is more naturally governed where those connections live, which is often in the integration platform.

What to ask

1. Where does the agent do most of its work? Place governance where the agent’s most important access is, and let the other platforms report to it.
2. Who sets the spend caps? Decide whether AI budgets are set in the data platform, in the gateway or both, so they do not conflict.
3. Do the MCP connections overlap? Check whether agents in Databricks reach the same business systems through their own MCP services that the iPaaS already governs.