Databricks governs agents built with its Mosaic AI Agent Framework primarily through Unity Catalog, which extends the same permission and lineage model Databricks already uses for data and machine learning assets to the functions an agent calls as tools. That gives an agent operating entirely within a Unity Catalog-governed workspace a genuinely strong, unified answer to who can access what. It does not extend past Unity Catalog's boundary — to an external API an agent calls directly, to a tool that was never registered as a Unity Catalog function, or to a second Databricks workspace running on a different cloud with its own separate catalog.
What Unity Catalog governance covers well
Unity Catalog is Databricks' unified governance layer, and its extension to agent tooling is a meaningful design choice rather than an afterthought: rather than inventing a parallel permission system for agents, Databricks routes agent tool access through the same catalog that already governs tables, models, and files.
- Data access control is enforced at the table, row, and column level through Unity Catalog, and an agent querying data through a registered function inherits the same permission checks a human analyst querying that table directly would face.
- Lineage tracking records what data fed into a model or an agent's output, giving a documented trail from source table to agent response for anything that flows through Unity Catalog-registered assets.
- Function governance lets teams register the functions an agent can call as tools inside Unity Catalog itself, meaning tool access, like data access, is subject to catalog-level permissions rather than being configured separately per agent.
- A consistent permission model across data, models, and tools means a security review can reason about an agent's access using the same catalog abstractions used for every other Databricks workload, rather than learning an agent-specific system.
For an agent population built entirely on Databricks, using only Unity Catalog-registered functions and data, this is a coherent and defensible governance story. The unified lineage in particular is a genuine advantage over platforms where data governance, model governance, and tool governance are three separate systems that do not share a permission model.
Where governance ends: outside the catalog boundary
The gap is structural, not a shortcoming in Unity Catalog's design: anything an agent does that Unity Catalog does not mediate is, by definition, outside its lineage and permission enforcement. Concretely:
- Direct external API calls from agent code. If an agent's logic calls a third-party API directly, rather than through a Unity Catalog-registered function, that call and any data it sends or receives is invisible to Unity Catalog's lineage graph. The governance discipline only holds if every tool call is actually routed through the catalog, which depends on how a team built the agent, not on a default Databricks enforces automatically.
- Tools that live outside Databricks entirely, including third-party MCP servers an agent connects to for capabilities outside what Databricks provides natively. MCP server vetting and registry risk covers why that population needs review independent of whatever platform invokes it.
- Multi-workspace and multi-cloud Databricks estates. Databricks workspaces run on top of AWS, Azure, or Google Cloud infrastructure, and a workspace on one cloud typically has its own Unity Catalog metastore. An organization running Databricks workspaces on more than one cloud, or more than one metastore on the same cloud, has more than one governance boundary to reconcile, not one unified view by default.
- Downstream systems that receive an agent's output. Lineage inside Unity Catalog documents what fed into an agent's response; it does not track what happens to that response after the agent hands it to an external reporting tool, a different SaaS platform, or a human who copies it elsewhere. Data residency for AI agents covers why the destination of data, not just its source, needs its own governance answer.
The practical risk is that a genuinely well-governed Unity Catalog setup can create a false sense that an agent's entire data footprint is covered, when what is actually covered is everything that was disciplined enough to be registered as a catalog asset — and agent development in practice does not always achieve that discipline consistently across every tool and API call.
A cross-boundary risk checklist
| Question | Why it matters |
|---|---|
| Are all of an agent's tools registered as Unity Catalog functions, or do some call external APIs directly from code? | Direct calls bypass catalog lineage and permission enforcement entirely. |
| Does your organization run more than one Databricks workspace or metastore? | Each additional metastore is a separate governance boundary that Unity Catalog does not automatically unify across. |
| Is there a record of what happens to an agent's output after it leaves Databricks? | Lineage inside the catalog stops at the point data leaves Databricks-governed assets. |
| Can spend attribution for agent-triggered compute be tied to a specific agent, not just a workspace or cluster? | Spend attribution and per-agent showback covers why workspace-level cost visibility is usually too coarse for accountability. |
| Is there one inventory covering Databricks agents alongside agents on other platforms? | A Databricks-only inventory misses the cross-platform picture most enterprises actually need. |
The function-registration discipline that is specific to Unity Catalog
The generic layer here — a cross-platform agent inventory, identity mapping across metastores and clouds, and a unified audit trail spanning Unity Catalog's logs and external systems — is the same shared control set covered in what is an AI control plane and building an AI agent inventory.
What is genuinely specific to Databricks is enforcing the function-registration path itself: a policy requiring every agent tool call to route through a registered Unity Catalog function, checked in code review or a build-time gate, rather than trusting that a developer under deadline pressure will consistently choose the governed path over a faster, direct API call from agent code. That single discipline is what determines whether Unity Catalog's lineage and permission model actually covers an agent's real behavior or only the subset of it that was registered properly. Cross-org agent federation and trust manifests covers the related decision of reviewing metastore and workspace trust extensions deliberately rather than letting them accumulate.
The AI governance guide covers the broader program this checklist sits inside, including how to structure ownership and review cadence for a control set that spans more than one platform.
What good looks like
- Every tool an agent can call is either a registered Unity Catalog function or explicitly documented and reviewed as an exception.
- Multiple Databricks workspaces and metastores are reconciled into a single governance view rather than treated as independently managed silos.
- Data lineage is tracked past the point it leaves Databricks-governed assets, not just up to that boundary.
- Spend attribution for agent-triggered compute is visible per agent, independent of workspace-level cost reporting.
- A cross-platform inventory covers Databricks agents alongside any agents built on other clouds or SaaS platforms.
Unity Catalog's extension to agent tooling is one of the more coherent governance stories among data platforms specifically because it reuses one permission model across data, models, and tools rather than inventing a fourth system. The work an organization still owns is making sure every agent actually stays inside that catalog boundary — and building the layer above it for the parts of the estate that, by design or by oversight, do not.
Common questions
Does registering a function in Unity Catalog guarantee an agent cannot bypass it? Registration governs the path a well-built agent is expected to take, but it does not physically prevent a developer from writing agent code that calls an external API directly instead of through a registered function. That is a code-review and architecture discipline question, not something Unity Catalog enforces on its own for every possible tool-calling path.
Is lineage the same thing as an audit trail for agent activity? No. Lineage tracks how data flowed between registered assets — which tables and models fed a given output. An audit trail for agent activity needs to capture the agent's actions, tool calls, and decisions over time, which is a broader record than data lineage alone provides, particularly for anything that happened outside a Unity Catalog-registered function.
If all our Databricks workspaces share one metastore, is the multi-cloud governance problem solved? It removes one source of fragmentation — a shared metastore does unify permissions across workspaces attached to it — but it does not address agents that call tools or APIs entirely outside Databricks, or a second, unattached metastore your organization may run for a different business unit or acquisition. Confirm the metastore topology explicitly rather than assuming a single shared one covers your whole estate.
What is the fastest way to find agents that bypass Unity Catalog governance? Review agent source code or configuration for direct API client calls or hardcoded credentials that do not route through a registered Unity Catalog function or connection. Any agent capability that was added quickly to unblock a demo or prototype is a common place to find this pattern, since registering a function properly takes more upfront work than calling an API directly from code.