Building Governed Agents with Databricks

Summary

This video explains how to move AI agents from prototype to production on Databricks by addressing agent sprawl through Unity Catalog's unified governance layer, which extends discovery, access control, lineage, and consistent policies across models, agents, tools, and MCP servers.
The MCP Catalog allows administrators to register and govern third-party MCP server connections—including Atlassian Jira and GitHub—with granular tool-level access control and automated credential management, and custom security policies such as PII detection guardrails can be applied to every agent call transparently.
End-to-end observability is delivered through real-time payload logging of every request, response, token latency, and error in Unity Catalog's audit log, combined with MLflow tracing of multi-step workflows and automated evaluation alerts for latency and error monitoring.

Building Governed Agents with Databricks

Recorded at: Agentic + AI Observability Meetup | SF | April 9, 2026
Speaker: Sunish Sheth (Sr. Software Engineer, Databricks)
Moving AI agents from prototype to production requires more than just code; it requires robust data governance. this video explores how Databricks addresses "agent sprawl" by providing centralized discovery, audit logging, and fine-grained access control for AI systems.
The presentation details how Unity Catalog extends unified governance across models, agents, and tools, ensuring a single source of truth for the entire AI development lifecycle.
Key Takeaways:
-AI systems require centralized governance to prevent security risks associated with rapid agent development.
-Unity Catalog provides a unified space for discovery, lineage, and consistent policy controls.
-Managed gateways use the Model Context Protocol (MCP) to govern access to third-party apps like Jira and GitHub.
-Admins can enforce deterministic guardrails, such as read-only restrictions or PII detection.
-End-to-end observability is achieved through real-time payload logging and MLflow tracing.
-Automated evaluation and alerts ensure performance reliability by monitoring latency and errors.
0:00 — Introduction to Building Governed Agents
0:22 — The Problem of Agent Sprawl
1:21 — Balancing Developer Ease and IT Governance
2:22 — Unity Catalog for Unified AI Governance
4:31 — Managing MCP Servers and Tool Connections
6:35 — Demo: Creating a Governed Jira Connection
7:42 — Managing Access Tokens and Credential Refreshing
9:18 — Enforcing Policies and Guardrails with AI
11:10 — End-to-End Observability and Lineage
12:01 — Monitoring Traces and Automated Evaluations
Check out future Agentic + AI Observability events: https://luma.com/AgenticAIObservability

Chapters

FAQs

What is agent sprawl and how does Unity Catalog address it?

Agent sprawl is the condition where an organization has many independently built AI agents with no central place to discover them, no consistent access controls, no audit logging, and no reliable way to revoke access when an agent misbehaves. Unity Catalog extends its unified governance model to cover not just data assets but also models, agents, tools, and MCP server connections, creating a single source of truth for the entire AI development lifecycle. This video explains how this centralized registry gives IT teams visibility and control without blocking developers from building agents quickly.

How are MCP servers governed in Databricks?

The MCP Catalog in Databricks allows administrators to register MCP servers—including connections to third-party services like Atlassian Jira and GitHub—and grant developers granular access to specific tools within those servers. Access tokens are managed centrally with automatic refresh, so developers never need to handle credentials directly. This video demonstrates connecting to an Atlassian MCP server, granting access to specific Jira tools, and verifying the governed connection works correctly through a live demo.

What custom security policies can be applied to agent calls?

Administrators can define custom security policies such as PII detection guardrails that automatically scan agent inputs and outputs for sensitive data and either redact or block the call based on policy rules. Human approval gates can be configured to require manual review before an agent proceeds with sensitive operations. These policies are enforced on every agent call transparently, without requiring changes to the agent code itself.

What does end-to-end observability look like for governed agents on Databricks?

Every agent call logs the full request, response, token latency, and any errors into Unity Catalog's audit log, creating a tamper-resistant record of all agent activity. MLflow tracing captures the execution sequence of multi-step agent workflows, enabling debugging and root-cause analysis. Automated evaluations run continuously and generate alerts when agent latency degrades or error rates exceed thresholds, allowing teams to detect reliability issues before they affect end users.

Full transcript

[00:01] 20 lines of code and boom, there's an agent. But, what are we missing? There is no place to see like who accessed what information, what tool, and what data. We want a low code, no code friction way to build these agents. What do IT
[00:14] So, you can actually see the request, response, the token latency, all the errors that's happening in each individual call. So, I'm here to talk about how we are building government agents at
[00:27] Databricks. And like from prototype stage to production. As we as we all know like everyone's building agent. There's like open frameworks coming out every week. There's agent platforms as well. There are like SAS models coming
[00:39] out every other day as well. Like there are two that just came out yesterday, the big ones. And there's like coding tools that everyone started using in their day-to-day life as well. This has caused a problem called agent sprawl. That we don't know which agent's actually good, which agent's bad, which
[00:53] tools are actually good for production, which ones are just for testing, which is causing some like security issues and stuff like that. So, how do you actually know which which tools to use in production? Why is this happening in the first place? As we all know that
[01:07] everyone's like building agents nowadays. Like previously there was like only traditional ML people building ML models and like productionizing it. But now everyone like a BI engineer or anyone engineer like any engineer is just building these agents. There are
[01:19] dozens of frameworks out there like LangChain, Llama Index, like bunch more coming every every day. And there's like 20 lines of code and boom, there's an agent, right? But, what are we missing? There is no like a single place to
[01:31] discover all of these agents. There is no place to see like who accessed what information, what tool, and what data. There's like no policy, there's no guardrails, there's no audit logging there anywhere. That's like standard
[01:43] across the board. And like if agents like misbehaving, how do you I know like I need to go and revoke access. Like I don't want this agent to work for on behalf of me. And how do we solve it? It's actually needs to be a balancing act, right? Like the developers don't want to lose the ease
[01:57] of actually building an agent like in 10 minutes, right? Like we want a low-code, no-code friction way to build these agents. They just want to like, "Hey, give access to the data and then let let the agent answer for me."
[02:09] But what do IT team actually wants? Like they want like a centralized space so that they can have like consistent like policy controls, guardrails, audit logging, end-to-end observability of what the agent is actually accessing as
[02:21] well. So at Databricks, I don't know if more a lot of people are familiar about it. Like we have a thing called Unity Catalog which we've used so far to actually go on on our data at Databricks. So for the folks who don't know, Unity
[02:34] Catalog is like so far been a unified governance layer on all of your data across all the cloud providers, across workspaces. So you can have like tables, models, functions, everything in UC
[02:46] and across all all your cloud like Azure, GCP, and like AWS. And it still works like and all the governance happens through that fine-grained access control through UC. So the key features like in UC so far
[02:58] that we support is like fine-grained access policies. I can grant or revoke access to specific data. You can do like row-level filtering, column-level filtering, all of that ABAC RBAC rules. You can audit and lineage all of this
[03:10] data as well. Like who's actually accessing the data and like what like which for building this model which data was used, which connections were used and stuff like that as well. It was this easy for us to just extend this all of this to the AI landscape as well. So
[03:23] like now you can imagine like ML models like all the connections, agents, skills, MC servers, tools, they can all be in UC as well and like we get all of the benefits that we've been getting so far on the UC side to do all of the same exact stuff in AI
[03:36] AI line as well. So it becomes like a single source of truth for anything and everything that you can access not just for your data, but also for your AI products as well. You can imagine like a single place that you can like even if the data is like
[03:48] outside like people are building agents outside of Databricks or in Databricks, they can just use UC as a way to discover, to governance, to lineage across everything like models, MCP servers, skills, agents, and whatnot.
[04:01] So, it's like a unified platform for all of your AI development life cycle. You can prepare your data that's already in UC. You can actually build agents, and you can do governance on top of your agents, and you can deploy it, and then you can do like all of the lineage tracking,
[04:14] like all the payload logging that you can actually track your requests and output responses. You can do tracing. You can even evaluate all of these models as well using LLM as a judge. And when all of these tracings are already stored in UC, and then you can do like
[04:26] guardrails, like all the credential management, rate limiting, and all of that as well. So, let me dive a bit more deeper into how we actually do like tool governance using the MCP gateway. At Databricks, we have different types of MCP servers. The first one being the
[04:40] managed MCP server, which is like the first out of that is like a genie MCP server, where you can just ask like natural like send a query in natural language, will return you back a SQL, and they'll actually answer answer data for you.
[04:52] Or you can directly do like SQL calls directly using this MCP server, will execute the SQL and return the data back to you. There's things like semantic search or even like custom UC functions that you can create, and then that will just like
[05:05] execute on on your behalf. The second one, which is like more popular and I'll do a quick demo on that one, is how do I connect to like third-party SaaS applications like Slack, GitHub in a governed manner rather than just like randomly sending a
[05:17] Slack message or like randomly accessing Google on like Google Drive documents on your behalf. That's like really scary, like random like creating a new Google Doc or viewing it like a private doc that you didn't want your agent to view.
[05:30] And I'll do a quick demo on that one as well. And And the last one is like marketplace, where people can actually host their MCP servers in Databricks, and then any customer who can actually just install that marketplace MCP server
[05:42] and then start using it. So, as you can see, like UC is becoming like a single plane of glass for all of your MCV servers, not just Databricks ones, but external ones and a marketplace hosted ones as well. And then
[05:54] since it's all on top of UC, you can get by default all of the R back A back policy controls. You get all the token management like secure credential storage, permissioning and all of that as well through UC. And because of that, any ID
[06:08] that is actually MCB compatible can connect to this UC governance layer, the catalog layer, and like things like cloud code, uh agent bricks that's like way to create agents in Databricks, custom applications, IDs
[06:21] can directly connect to this MCB catalog. And this is just like a view of how our MC catalog looks like. I'll show that more in details in the demo as well. And like you can use it in Databricks and also by using like connecting to local IDs as well. So as
[06:35] you guys can see like this is like our Unity catalog page. And I'm going to create a quick create a connection over here to connect to Jira for example. I'm just going to call it Jira.
[06:51] Connection. I'm going to create the auth one. And use the Atlassian MCB server for that one. And then like I can even customize the scopes as well that I want to do, but I'll just take the default scopes that I have so far which is read only and then
[07:03] boom, I've actually created a connection. So as you can see, I can come into UC and then grant access to specific users as well. So I can come here and can say that hey, which users like should I have actually have access to? So I can tell
[07:15] like my my colleague Sid should have access to this. I can like say like use connection or like grant all privileges. You can change that and update the scopes and stuff as well. Or it's like hey, you can use the Jira MCB server by
[07:27] default. So I can grant the Sid access. I can even grant like other users access like all account users or something like that. So I can do like fine grain access control on this one too. So once I have actually have the like the connection created, I can go through
[07:39] the login flow. Uh like similar to OAuth process, I can like login through this. So, ask for consent for all the scopes that I have actually asked for. And boom, here. So, now you see it's
[07:52] actually managing all the credentials on your behalf. Uh, like you'll do the token refresh and all of that. So, it's like really seamless to the customers. Uh, they don't need to like figure out hey, the token's expired. I need to go refresh my token and all all of the
[08:04] management. Like using this OAuth, you can do all of the management on in Databricks as well. Now, as I mentioned like these are like the MCB catalog before that I just showed you before. Uh, these are all the MCB servers that yeah, we have. And if I select one of
[08:17] the external ones, there's the Jira connection that I just created. And you can see these are all the list of tools that a Jira connection MCB server has by default that we can we can start using it. Uh, and you can see like there are like list of like
[08:30] four pages of tools that we can use uh, to connect and talk to Jira. And let me quickly try that out as well. So, as you can see like I'm using like ChatGPT 4.4 of 5.4 and adding like the Jira connection tool and say hey, can
[08:42] you read read the information of this ticket? Something so really simple. Uh, and so it's able to actually get that information and I get all of that information like hey, what this ticket is about and like who's assigned to it and and stuff like that. So, you can see
[08:54] like quickly in like 10 seconds I was able to actually query a Jira, get that information that I wanted and this can scale to like GitHub and other providers as well. So, as you saw like this agent was able to actually connect to the the IDP server, get your token and all on
[09:08] user's behalf. Like it was able to actually take my access token and query directly to Jira. And then agent was actually able to carry forward all the identity to the till the end user. But, there is still something missing, right? Like you saw like there were like four
[09:21] pages of all the different tools. But, what if as an agent developer or an admin, I don't want to give access to like for example creation. I don't want to say that hey, I I cannot create uh, my ticket in this particular like fraud
[09:33] project or something like that. Or I I want to like give access to like reading Confluence data or something like that. So, the admins can actually set uh like guardrails and controls on top of it by using something like ABAC policies that
[09:45] we already have in UC. So, people can actually do like, "Hey, on every request, I want like Jira PII detection where you can say like use an LLM as a judge or something like that to directly detect, 'Hey, is this is this input or
[09:58] uh response that's coming back from the MCB server? Is it actually functional? Is it I can set up like custom uh functions as well to do like all the monitoring, detection, like access allow or deny that, or even ask saying that, "Hey, I want to ask users that, 'Hey,
[10:10] should I do this action or should I do this request uh before I even making the call?'" Or admins can even downscope and specifically say that I only want like read-only tools or get Confluence uh information as well. Or use like tags
[10:22] like MCB supports like tool annotations. We can actually use policies on top of those annotations as well and say that I only want to support like read-only tools and no destructive tools, for example. So, using these policies and fine-grained policy access controls, you
[10:34] can actually do all of that. So, how are these actually policies enforced, right? Like so, every agent call, when you actually make a call, we look up the policy and see if that uh convert that into a cell evaluation and seeing if the agent actually has access to this information or not. And then based on
[10:46] that, as I mentioned, you can actually say, "Hey, deny access or you're allowing that or hide the tool and stuff like that as well." So, once these policies are applied, now you can see like I've restricted the number of tools as well. Like rather than having like four pages of like a lot of these tools,
[10:58] I can even restrict it down to like three pages or like reduce it even like further like just two tools or something like that as well. And that even like reduces the uh context window of what the agent can actually see as well. Reduces like the cost of the LLM, too. The last thing
[11:11] that I want to talk about is overall observability. Like we've talked about like all about like governance and stuff of it so far, but what about like what's happening end-to-end when they actually make a query? UC by default provides all of this real-time lineage as well that
[11:23] you can actually see, "Hey, this is all the data that's actually used to build an agent." And then once that you can actually see like all the sources, the columns, and everything end-to-end. And this is like all real time. Like on a particular query, you can see all of
[11:35] that information as well. As we as I said, like everything in Unity gets logged as well. So, you can actually see the request, response, the token latency, all the errors that's happening in each individual call through that as well. And we store all of that. You can query like like through
[11:48] SQL dashboards, you can you can view this. You can do like jobs. You can set up alerts saying hey, if something went wrong, please alert me that hey, this So, it's like in the night you can actually sleep unless you actually get an alert. And that that should like help you like hey, like actually track the
[12:00] agent end-to-end. Lastly, like we also do like all of this through hotel like tracing into ML flow. So, you can actually log like all of these traces are actually stored into Delta tables in the hotel format. So, you can
[12:13] actually run built-in judges like open-source ML flow actually has a way to like learn all of these judges like you know, have built-in judges in Databricks as well. You can customize these rules. So, as soon as the input request comes in, you can evaluate does it did a good job? If not, you can set
[12:26] up alerts. You can do like live traffic. You can scorings on the live traffic as well. And like all of this can be governed again through UC like hey, who can actually view these traces, who can run these evaluations, and what information that a person can get as well.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.