Back to Blog
· Kevin

Databricks Unity AI Gateway Just Made the Lakehouse Your MCP Firewall

Databricks extended Unity Catalog governance to agents and MCP servers in mid-April 2026. The result is a single control plane for AI tool access — and a textbook vendor lock-in for anyone whose data lives outside the lakehouse.

mcpdatabricksgovernanceai-agentsdatabasesrbac

When Databricks rebranded its AI Gateway to Unity AI Gateway in mid-April, most coverage filed it under “another LLM router.” That undersells what shipped. The release extended Unity Catalog’s permissions, audit, and policy model from data assets to two new resource classes: the LLMs your agents call and the MCP servers your agents talk to. Fine-grained MCP governance. End-to-end observability across LLM and tool calls. One catalog for tables, models, and tools.

This is the most concrete answer yet to the question every CISO has been asking since MCP servers started multiplying past 5,800 on public registries: who governs the tools? Databricks’ answer is “we do — if your data is in our lakehouse.” For everything else, the question stays open.

If you run Databricks plus a few external Postgres clusters, a SQL Server warehouse left over from an acquisition, and an Oracle EBS instance the finance team won’t migrate, you now have a clean, audited control plane for some of your agent traffic and a homemade YAML pile for the rest. That gap is the story.

What actually shipped

Unity AI Gateway is the renamed and expanded version of Databricks’ AI Gateway, which previously focused on rate limits, payload logging, and PII scrubbing for LLM calls. The April update added:

  • MCP server registration as Unity Catalog objects. A remote MCP endpoint becomes a first-class asset with an owner, a path, and grants.
  • Tool-level permissioning. Inside a registered MCP server, individual tools can be granted to specific principals — GRANT EXECUTE ON TOOL catalog.mcp.salesforce.create_opportunity TO sales_agent.
  • Policy enforcement at call time. Allowed-tools lists, payload size caps, and PII detection now apply to tool calls, not just LLM completions.
  • Unified audit. Every LLM completion, tool invocation, and intermediate trace lands in system.access.audit alongside table reads and notebook runs.

For workloads inside the lakehouse, this is genuinely good. The pattern of “an agent has access to anything its OAuth token can reach” has been the gnawing security problem of 2026. Forcing tool calls through a gateway with the same RBAC vocabulary as your data is a clean fix for the slice of traffic the gateway sees.

The catch is the slice it doesn’t see.

The slice the gateway doesn’t see

Real enterprise data layers do not sit cleanly inside one platform. The 2025 Fivetran/Wakefield survey put the average enterprise at 187 SaaS apps and 6.7 separate database engines. The 2026 numbers are worse, not better — agents are now creating databases at roughly 4x the rate humans are, per the analysis I covered last month.

Concretely, the typical Databricks customer also runs:

  • One or more operational Postgres clusters powering customer-facing apps (write path, low latency, not a candidate for lakehouse migration).
  • A legacy SQL Server instance behind an internal tool that finance, legal, or ops still depends on.
  • An Oracle EBS or Hyperion install nobody on the current team installed and nobody on the current team can move.
  • A MySQL cluster running a homegrown CRM, an open-source app, or a vendor product.
  • One or more Snowflake or BigQuery warehouses for cross-cloud analytics that predate the Databricks investment.

Unity AI Gateway can govern an agent’s access to data that exists in Unity Catalog. It cannot govern an agent’s access to data that doesn’t. If your finance copilot needs to read GL entries from Oracle and reconcile them against bookings in Postgres, the Oracle and Postgres legs of that workflow do not flow through the gateway. They flow through whatever you wired up — usually a custom backend, a hand-rolled MCP server, or a SaaS connector with a service account that has way more access than the agent should have.

The result is a governance “donut”: a clean, auditable hole in the middle (the lakehouse) surrounded by an unaudited ring of everything else.

Three patterns customers are reaching for

In conversations with teams sizing up Unity AI Gateway, the three coping strategies are:

1. Migrate everything into the lakehouse. This is the strategy Databricks’ field team will gently encourage. It works for pure analytics workloads. It does not work for OLTP, for systems with a vendor on the other end, or for data your legal team will not let you move. Even when it works, the migration is measured in quarters, not weeks.

2. Build a parallel governance layer for non-lakehouse data. Stand up a separate API or MCP layer in front of the operational and legacy databases, with its own RBAC, audit, and observability. Now you have two control planes that need to stay in sync, and the agent has to know which one to call for which data. The “unified” part of “unified governance” has quietly turned into a join across two systems.

3. Pretend the donut hole isn’t there. Govern lakehouse access through Unity AI Gateway, govern operational data through if user_id == ... checks scattered across a backend, and hope no auditor draws a Venn diagram. This is the most popular strategy. It is also why enterprise AI security incidents were up 312% year-over-year in Q1 2026.

There is a fourth strategy, which is what we’d argue for: a single, neutral API and MCP layer in front of every database — lakehouse and otherwise — with RBAC, audit, and observability that don’t depend on which vendor’s catalog the data lives in. That layer can sit alongside Unity AI Gateway for Databricks-resident data and own the rest of it directly.

Why “fine-grained MCP governance” matters more than the headline suggested

Most MCP coverage in the first half of 2026 framed the protocol as a connectivity problem: how do agents reach tools? The Unity AI Gateway release reframes it as a permissions problem: which principals can call which tools, with which payloads, against which data, with what audit trail?

That reframing is the right one. The connectivity problem was solved months ago — there are 5,800+ MCP servers in public registries and untold thousands inside corporate firewalls. The permissions problem is the real production blocker. The PocketOS incident on April 28, where a coding agent dropped an entire production database in nine seconds, was not a connectivity failure. The agent had connectivity. It had permissions it should not have had.

Databricks naming a tool “Unity AI Gateway” and then defining grants on individual MCP tools is a quiet acknowledgement that MCP servers without per-tool RBAC are net-negative for production. They expand attack surface without adding controls. The gateway model — every call mediated, every grant explicit, every trace logged — is the only credible way to ship agentic systems against real data.

The question is whether your governance layer is one your warehouse vendor owns, or one you own.

Where Faucet sits

Faucet is a single Go binary you point at any database — Postgres, MySQL, SQL Server, Oracle, Snowflake, SQLite — and it generates a REST API and an MCP server in seconds. The MCP server is not a side feature. It is the same RBAC engine, the same audit log, and the same policy layer as the REST surface, exposed to agents through the protocol they already speak.

Practical consequences for the donut-hole problem:

  • One layer for all six database engines. The Oracle EBS box, the legacy SQL Server, the operational Postgres, and the MySQL CRM all sit behind the same RBAC vocabulary and the same audit log. There is no “we govern the lakehouse but not the rest” gap.
  • Per-tool permissions out of the box. A role in Faucet maps to a set of tables, columns, and operations. The MCP tools generated for that role inherit those permissions. A sales_agent role that can read orders but not payroll produces an MCP server where read_orders exists and read_payroll does not — not one where both exist and the second returns 403.
  • Audit log keyed to agent identity, not service account. Every MCP call logs the principal that made it. No more “the integration user did it” entries.
  • Sits next to Unity AI Gateway, not against it. For data already in Databricks, Unity AI Gateway is the right governance plane. Faucet is for the operational and legacy data that does not and will not live in the lakehouse. The agent gets a single API surface across both — your governance story stops being a join.

The release also sharpens a comparison that has been quietly building. Every major data platform vendor — Snowflake (Cortex), Oracle (Heatwave + the Google Cloud announcement), Databricks (Unity AI Gateway), Microsoft (Data API Builder + MCP) — is racing to be the agent control plane for data they own. None of them has an answer for data they don’t.

That neutral, cross-vendor control plane is the gap. It is the gap Faucet is built for.

What to actually do about it this quarter

Three concrete moves, in roughly the order they pay back:

1. Map your donut. List every database your agents touch or will touch in the next two quarters. Mark each one as “in Unity Catalog” or “not in Unity Catalog.” For the second column, ask: what governs MCP and API access to this data today? If the answer involves the words “service account,” “shared secret,” or “the script Mike wrote,” that is the donut hole.

2. Pick one production agent workflow and trace its data path. Not the demo. The one finance is asking about, or the one customer support has been piloting since February. Walk it from prompt to answer and write down every database it reads, every tool it calls, and what mediates each hop. The point is to see, in one A4 page, how many control planes you currently rely on. The number is almost always higher than people expect.

3. Decide what your “ring” looks like. Unity AI Gateway covers the lakehouse middle. Something has to cover the ring. The realistic options are: (a) one custom-built backend per non-lakehouse database, with its own auth and audit; (b) a SaaS connector that you do not control; or (c) a single open-source layer with the same RBAC and audit story as your core platform. (a) is what most teams have today and most teams are unhappy with. (b) trades the lock-in problem for a different lock-in problem. (c) is what Faucet is.

Getting started

If the donut diagram in your head is starting to bother you, the fastest way to see what a neutral layer feels like is to point Faucet at one of the non-lakehouse databases on your list.

curl -fsSL https://get.faucet.dev | sh

faucet add postgres "postgres://user:pass@host:5432/orders"
faucet add sqlserver "sqlserver://user:pass@host:1433?database=finance"
faucet add oracle "oracle://user:pass@host:1521/EBSPRD"

faucet roles create sales_agent
faucet grants add sales_agent --read orders.* --read accounts.summary

faucet serve --mcp --rbac --audit

You now have one MCP endpoint with per-tool permissions across three engines and an audit log keyed to the agent identity. Point your agent’s MCP client at it. The same RBAC governs the REST and the MCP surface — the agent and the human-facing app are not negotiating two different permission models.

The lakehouse is one ring of your data. Govern the rest of it like you mean it.

Further reading: