MCP Security Deep Dive: How Databricks Secures Tool Access for Enterprise Users

Summary

As agents expand data access beyond traditional data engineers to business users querying lakehouse data alongside external systems like Slack, SharePoint, and Google Drive via MCP, the security assumptions built for human access no longer hold and a defense-in-depth posture becomes essential.
The Databricks Data and AI platform secures MCP-based integrations through on-behalf-of authentication via Unity Catalog connections, contextual authorization that limits agent permissions to task scope, Unity AI Gateway service policies (allow/deny/ask), and ABAC content and data protection policies.
Serverless egress controls and full audit logging ensure every agent action across MCP-connected tools is traceable end-to-end, and live demos in this video contrast an ungoverned agent that can read sensitive data and delete records with a governed agent that has all policies enforced.

MCP Security Deep Dive: How Databricks Secures Tool Access for Enterprise Users

As agents connect to external tools and systems, security becomes a first-order concern. Every interaction — from authentication to tool invocation — must be governed, permissioned, and fully auditable. One leaked credential or broken audit trail can break production trust overnight.
In this deep dive, we'll show how to secure MCP-based integrations in production on Databricks. You'll learn how to implement authentication and authorization, manage fine-grained access to tools, and ensure every agent action is traceable end-to-end. We'll also share how Databricks applies these patterns internally — using Unity Catalog connections to securely grant MCP access to thousands of users — along with the key risks, design tradeoffs, and best practices.
You'll walk away with a production-ready blueprint for protecting data and systems as agents start taking real actions on behalf of your users.
Talk By: Samrat Ray, Director of Product Management, Databricks ; Sunish Sohil Sheth, Senior Software Engineer, Databricks ;

Chapters

FAQs

How does Databricks secure MCP tool access for agents?

The Databricks Data and AI platform uses a layered security model for MCP tool access that includes on-behalf-of authentication through Unity Catalog connections, Unity AI Gateway service policies that allow, deny, or require approval for tool invocations, and ABAC policies that restrict content and data access at a fine-grained level. Every agent action is logged for full audit traceability.

What is on-behalf-of authentication in Databricks agent security?

On-behalf-of authentication means an agent acts with the identity and permissions of the specific user who invoked it, rather than using a shared service account with broad access. Unity Catalog connections manage these credentials so agents only access the data and tools the originating user is authorized to use.

What is ABAC in the context of Databricks MCP security?

ABAC (Attribute-Based Access Control) refers to content and data protection policies that restrict what an agent can read or act on based on attributes of the request and the data. On the Databricks Data and AI platform, ABAC policies can prevent agents from reading sensitive fields or from taking destructive actions like deleting records, as shown in the live demo in this video.

Why do traditional security assumptions break for agentic AI?

Traditional security models assumed access came from a small set of data engineers operating from known secure locations using a defined set of tools. Agentic AI changes this by enabling business users to query data from any location and by having agents join data across the lakehouse and external systems like Slack, SharePoint, and Google Drive simultaneously, vastly expanding the attack surface.

Full transcript

[00:09] we'll kick it off. Uh thank you all for showing up on uh the last day of the conference. I know it's kind of we have had many sessions. Um we hope this is going to be u useful for you. We are going to do a deep dive on MCP security.
[00:22] As the name suggests, it's a deep dive. It's not a um you know high level product pitch. Uh so we will talk about um a few core technical concepts of that relate to um you know agentic and tools
[00:34] uh tool access security and uh we will uh both explain how data bricks helps you mitigate some of the risks and uh do a demo uh showing uh it in action
[00:47] effectively. Uh so to kick it off uh uh anyway a good performative statement any forward-looking sort of statements that we make here doesn't represent a formal
[00:59] product commitment. Uh with that we'll kick it off by looking at where we are today. Um as we all know this is not news. Agentic AI is uh driving data democratization.
[01:12] Well that sounds like a lot of marketing buzzword for a technical session. Data democratization. What does it mean actually? Um what it means is that um effectively earlier if you go back two years who would access data bricks it
[01:25] would be a select set of data engineers accessing data bricks from a secure location right maybe you had to be on a particular diva um network location and you had to access it from certain uh
[01:37] kind of devices and stuff and u you would typically access a lakehouse and a few other data sources. All of those assumptions are sort of changing very rapidly, right?
[01:49] uh data because this is the agent the whole point of the agentic uh workflows for data is to enable business users to be able to directly be able to have a queryable interface into their data and that's very important uh for driving
[02:02] some of the business transformations with AI which most of you are trying to do right so what that mean everybody needs access they need access from different locations right uh because not
[02:14] everybody can be on the most secure network right And because agents are very good at like joining data across things. So you not only have access to the lakehouse data, you uh the agents are going to reach out and get access
[02:27] from various back-end data sources like operational data sources like Slack or Office 365 like your SharePoint or Google Drive. These last bits we call tools or and the way to access them is
[02:40] MCP and that's what is we're going to cover in greater detail today which is how does how do agents access tools and what are the security risks. The thing
[02:52] is that what we described was really important for you to have uh the right kind of a business outcome. So it's not really an option for you because that's every industry is going there and if you don't it your competitors will do it. So
[03:04] you need to go through that transformation but you can't throw away security as you do that and so you need to understand the risks and there are few risks which we all commonly have heard in the newswire. Um so agents can
[03:16] leak sensitive data right uh they're not fully predictable right they're not like humans they're more autonomous uh entities and u they can perform destructive actions uh we have all heard
[03:29] possibly of the uh incident where um the agent deleted the database in uh production and then said hey I specifically gave you system prompts to not do this and the agent simply replied
[03:41] saying yes you told me not to do this but I did Right. So it just tells you that u quote unquote model alignment or uh you know
[03:53] providing system prompts or giving other kinds of nondeterministic guardrails is nondeterministic. Right? So it is basically you've got certain percentage at which it is going to work and then
[04:05] it's not going to work. So it's not cannot be the basis of your critical security needs. It cannot be the basis of protecting your most confidential information. Right? you need to protect it with more deterministic controls that are part of the scaffolding of your
[04:19] agentic system. So let's dive into that a bit. What are we talking about here specifically? So when we talked about these things, it performs a destructive action or it exfiltrated data. We're really talking
[04:32] about the connection between the agent and the various data sources, right? So securing that access in a way such that you prevent and uh or mitigate the risks
[04:44] that we just talked about is critical to successful agentic deployment and to scale that deployment across your enterprise. So I'm Samra Trey and I'm a director of
[04:58] product management and I lead uh security at data bricks uh covering various areas including agentic security and with me is uh sunish set and he is a developer on the AI platform
[05:12] and um now let's dive in a bit into the deep dive actually so the first thing from a deep dive perspective is to understand the risks what are the risks We talked about it at a high level,
[05:24] right? Like what you see on the newswire, but let's actually structure this into some technical uh um understanding of it. So let's take the baseline, right? What what do you have today before agents? You might have an
[05:37] employee on a laptop that is on your corporate network, right? um and accessing your backend systems uh including internal systems over VPN or even overVPN going over your corporate
[05:49] gateway to access your SAS systems like um drive or Salesforce right what are the properties of this system why do we why do we think it's okay for this user to be able to access this data on the laptop there's actually some built-in
[06:03] assumptions um one is that the user whatever action they're taking is intentional so if they were actually to copy a bunch of data one by one into a dock and then put it in their own hard drive or their own Google drive that
[06:16] would be malicious and intentional right it wouldn't be accidental the second thing is an assumption is they they are accountable so if they did do some action like that because you know it is intentional and they have a job to
[06:30] protect you know it can have repercussions on their employment so that makes them accountable and third is in many cases the way the access is granted is through a UI And that is a pretty slow um or narrow you can say
[06:44] bandwidth channel for you to get at data right. So yes you can get at highly confidential data sometimes a small amount of data is highly confidential like current quarters revenue for a public company but those are limited access right in many many cases it's the
[06:58] broad it is the bulk data that is actually the more sensitive piece and so the low throughput is a guardrail against something really bad happening. So overall given all of these things you generally your security team says yes
[07:10] there's a risk the user will be can turn malicious yes there's a risk they can do something bad but generally the risk is low right and therefore this is approved however now let's just replace the user
[07:23] with an agent the user actually using an agent which of these assumptions actually holds true which I just talked about the three none none of them hold true and this is something that a lot of folks that when we talk to them haven't
[07:35] actually grown Right? They haven't actually figured out that an agent running on the laptop is not the same as the user on a browser on the laptop. The reason for that is one the agent actions
[07:47] are unpredictable. No matter how much of alignment you have done, no matter how much of you know uh system prompts that you have given it, it does not matter. They're unpredictable. Second, the agents are not accountable. Like the
[07:59] example I gave you at the start of the talk, uh we told them, hey, how come you didn't follow the system instructions? and it said yes I did not follow the instructions right so you can't hold them accountable lastly agents are not
[08:13] using a UI pathway they're not going through your web server with a cookie and trying to get a web page they are going at the APIs or MCP endpoints and such access is high throughput so now
[08:25] suddenly the risk is no longer low the risk is actually high because given all of this the chances that uh the agent can leak credentials because you In order to access backends, you have to give them credentials that they can leak
[08:38] those credentials or they can actually leak the actual data is fairly high, right? We have seen various kinds of accidental quote unquote attacks on agents like we have seen things like
[08:50] where prompts have been injected because the output of the previous result it interpreted as an instruction to do something else. It was actually an error message but it the agent interpreted to do something else and it went ahead and
[09:03] deleted something in the production. In another case it could excfiltrate data. None of this was done maliciously but it happened right. So how do we mitigate against this risks and so the
[09:18] we looked at this in detail and we came up with a posture for defense and depth that helps you mitigate this risk. It is not one silver bullet but you need to do a set of things depending upon how you
[09:30] uh configure your agentic app. The first is you have to ensure that you have a secure authentication mechanism. Right? Just having the agent impersonate the user or giving the agent a service
[09:42] principle uh is no longer a good mechanism. Right? We have had customers who have come to us and said oh can I just give my user the agent a service principle and then give it access? Bad
[09:54] idea. Right? Can it impersonate the user fully? Better than giving it a service principle, but still not a great idea. Right? Uh the second is contextual authorization, which means you have to understand what you intended to do, what
[10:08] you wanted the agent to do, and make sure that your authorization is consistent with that intent. Parameter control. We just said if you have unbounded access to the internet, the agent can excfiltrate data. So there are
[10:21] some cases where it's unavoidable that the agent has to be exposed to sensitive data. In those scenarios, you want to make sure there is proper parameter control and isolation for that agent. And lastly, monitoring and tracing. Even after all these guardrails, it's still
[10:34] an unpredictable behavior. So you need to monitor it and have a mechanism of understanding what the agent is doing on a ongoing basis so that you can manage risks accordingly. So with that, let's start with secure
[10:46] authentication. So what secure authentication? What do we mean by that? So there are two types of authentications that are generally supported. The first is you can authenticate on behalf of the user. What it means is if sun uses an agent to talk
[11:02] to a back end, the agent authenticates itself as Sunish. That's on behalf of the user. But it is not strictly impersonating Sunish because that word on behalf of actually has a real
[11:14] technical meaning. it the token that is used to authenticate actually says it's an agent with this app id that is acting on behalf of sunish that is very different from taking a pack token or a token that that just says sunsh and
[11:28] replaying that right so this on behalf of authentication is an important construct here the second is in many cases the user actually doesn't have access to the backend system the user doesn't is not a thing on the backend
[11:40] system right because you must use a service principle right so Then in that case there are two options. You can either use a bearer token like a that's like a secret key like a key based access or a pat token based access or
[11:53] you can use a machine to machine oath flow right uh which is um what a service identity is an example of right uh where you're doing that. So in both cases, one of the key properties we want to enforce
[12:06] is the agent should not have access to the actual credentials to either the user credentials or the secrets because if it does have access there is the probability that it's going to leak
[12:18] those or it will use those in some ways to impersonate and escalate privileges. So introducing Unity gateway over here. So the first value proposition that unity gateway gives you is it takes care
[12:32] of this authentication problem. It takes care of secure authentication. So the way it works is the first step is the agent will authenticate to the unity gateway on behalf of the user. It'll never actually use a service principle
[12:44] or a secret like you should not do that if it's act if it's an interactive access driven by a user. You should always enable OBO in the system and make sure it acts on behalf of the user. This
[12:56] guarantees that the agentic flow will never exceed the authority of the user itself. So for example, if you give the agent an access to a sales database and the user is supposed to see some sales and not other sales, this will guarantee
[13:10] that all the way down your role level security is being enforced because if you give it a service principle, the user can through prompting or otherwise make the agent give it up all
[13:22] the records which the user should not have access to. Right? U so that's pretty key. The second thing is the MCP O is actually not handled by the agent anymore. It is handled by the gateway.
[13:34] That's a very important property because all your secrets, all your credentials that you need in order to access the back end is not accessible to the agent. It's only accessible to the AI gateway. Then the internally just to give you the
[13:46] details, the AI gateway uses a UC connection object and it is only the UC connection object that has access to the credential. So this is very important because that protects you against excfiltration of
[13:59] the credential and it prevents the agent from impersonating and having broad privileges which it's not supposed to have. So that's step one. So how do we go from this contextual sorry from this
[14:12] authentication to authorization? What does contextual authorization mean? It means what can the agent access? If you have access to end systems doesn't mean that the agent should also have
[14:24] access to all the end systems and also to all actions. Like a common example that we always hear is we want the agent to be able to access my data but not delete a table. I have the privilege to delete a table but I don't want my agent
[14:36] to ever delete a table. Right? Uh so that's what is access to enable this we provide end toend context based access control across all layers of the stack. Right. It's there
[14:51] in omni policy. Uh mate and others have demoed and uh and actually Casey showed it where if it is tainted with PII, you can restrict the action. So that's context based uh policy. We now offer
[15:04] context based uh ingress control for access to the workspace edge. Unity catalog aback. It governs data and is now has context attributes and in
[15:16] particular it one of the attributes is an agent awareness attribute in there and that relies on the OBO authentication. So there is a connection between what I talked about before and this if you don't have an OBO you will
[15:29] not be able to use that property. Uh and lastly the Unity AI gateway which is a part of Unity catalog basically and is still using the UCA back policies effectively has the construct of using those
[15:42] policies in what we call a service policies to guard access to tools and to models. So let's talk a bit about um the workspace based access. Why do we need
[15:54] context based access there? Again, as I mentioned with this data democratization um direction, you would have access from various sources and you want to make sure that a data engineer on a
[16:06] production network can have full access to the workspace. Not an issue. They're on a secure network and they are a trusted user. But at the same time, if you're on a user on an agent, maybe you want to restrict access to just the AI gateway, right? Or if you are a business
[16:18] user on a mobile device, maybe they only have access to Genie one and nothing else, right? Uh so this notion of combining the network identifier as to where they are, what is the trust of the network, what is the trust on the source
[16:32] with who is accessing and then combining that to what they have access to on the workspace is what is solved by contextbased ingress control. It's a new feature that is part of our network policy object that allows you to then decide what you want to grant access to
[16:45] based upon the network source, the identity and um the scope of access. Right? uh in this particular example we are just showing you something very simple which is that hey only human users are allowed to access via SAS via
[16:59] SAS API which is a powerbi in this particular case I think it's a powerbi and um and they can oh sorry not uh yeah you can do that in this particular case we're showing the full access actually from the corporate gateway but you can
[17:12] similarly use this attributes to um narrow down access based upon whether you're accessing from a SAS whether you're directly accessing so the context is in inbuilt in there. Now let's go
[17:24] past the workspace to the next level and act actually access to tools and data which is what we are here for right so ideally I and I mentioned this before agent shouldn't have any access on their
[17:36] own authority right all authority should be derived from the user itself this means that an agent cannot exceed my own authority right it cannot I cannot fool
[17:48] it to get me more data than I have personally access to but at the same time I might not want it to do everything that I have access to. Like GitHub commit is a good example. Maybe I want it to generate code, but I don't want it to commit that code without my
[18:00] approval. So I might want in some cases to ask for it to ask me before it commits. In other cases, I might want to deny access to PII. Like I'm like I'm trying to do an aggregate query. There's no good reason the agent should be accessing the PII. I want to deny access
[18:13] to PII. And uh there are other things which I do want to allow. So this is where service policies comes in. Service policies are effectively UCA back policies. They're not different
[18:25] except that they are attached to the tools or MCP endpoints versus to your data, right? That's the difference. They intercept all access going from the agentic harness to your backends, right?
[18:38] And it they give you two three things that you can do. You can do allow, deny or ask, right, on them. The good news about this is unlike the example I gave you before where there was a system instruction given do not do this and the agent
[18:51] simply ignored. These are deterministic policies that are enforced outside of the agent and are guaranteed to be executed. So they are mathematically provable to be executed not unlike the
[19:03] other best effort scenario. So here's an example of a um service policy where we are saying if you want to push files like commit the get commit
[19:15] piece which I just showed then you should ask right this is will be enforced anytime the git MCP endpoint is being accessed by the agent right another example here is this is on
[19:29] the data I mentioned you can govern both tool and data here's an example where on behalf of We just talked about behalf of in the authentication tying it back here. If your access is happening on
[19:43] behalf of an user and it's not the user directly accessing it in this case it's behalf of means any app but we also will support app ID equal to this. So you can say specific app like oh give if it's a
[19:55] agent that have deployed as a datab bricks app and is running in a highly isolated environment great give it PI access but if it's an agent that's actually running on a laptop in my corporate network with no isolation do not give it PI access right it's a very
[20:09] reasonable way of thinking about it so this is an example of where you can deny access it'll just mask it right on the way out so it's coming from your laptop it's an agent running on a laptop it has full internet access no PI access I'm in
[20:21] compliance the agent is running in a completely isolated environment with egress control all of that in place. I want to grant PI access. So to summarize we had uh two types of
[20:34] aback policies that we talked about. The first is content protection. We showed the example of masking but you can also do role level filtering and other kinds of policies there. Um and then the other is access which is like do you actually
[20:46] grant access to a given tool or not? Do you want to deny access to certain things and certain actions within a tool? So with contextual authorization with the AI gateway, you now are able to
[20:58] govern tool access and decide which tools can be accessed and what operations can be performed on a given tool. Second, you can do rate limiting. This might not sound like a security feature, but it's actually a security feature because you might say, I expect
[21:11] it to just read this tool a couple of times. Why is it reading 200 times? Right? So you it's actually can be thought of as a security feature as as well as a reliability feature. The third is you can protect sensitive data with
[21:23] data protection policies on the Aback. So going back to parimeter control now many of you may not have configured serverless egress controls
[21:37] and that may not have been a big deal when you are just writing Python code yourself. Maybe you trusted your developer or yourself that you are not going to excfiltrate data with agents. You can no longer have that level of
[21:49] trust. Uh please configure serverless egress control. Uh there are two reasons for that. The first is uh agents can download libraries from the internet if
[22:01] you don't have egress control and you can't they may just decide they want to download a library because it works best for them and that library may contain malware. Right? So you might have gone through a process where all libraries
[22:13] that you use are scanned and you know they're good libraries stuff like that getting it but the agent can just download it from the internet right there. So and uh we recently had the
[22:25] many of you might have had the light LLM kind of issues where the supply chain was compromised. Light LLM is very widely used in the AI space. So we had a lot number of our customers who were using light LLM. Those who had egress controls, it prevented it from phoning
[22:38] home and excfiltrating the data, right? And others who did not have it were exposed to that risk, right? Uh and so we could observe those outbound traffic going from light to those uh spaces and
[22:50] we had to shut it down and inform those particular customers who were exposed to it. So please do that uh if you haven't done it. So with serverless egress control one is you have controlled internet access. So it can only access
[23:02] the domains that you want it to access, right? It cannot just go and access box.net or something right randomly. Secondly, um it cannot download untrusted binaries, right? You you can you either explicitly give it access to
[23:14] a particular git repo or you make it you just give it access to a private repo. Do not give it access to any public git repo. Lastly, monitoring and tracing. So effectively after you have all these
[23:27] controls, you want to ensure that you are able to understand everything that the agent has done. And this is another property of just enabling the AI gateway. All the interactions are being
[23:39] logged in your audit log. And it's not just individual audit logs. We're also capturing the lineage. So the lineage you are familiar with data lineage I guess but this is also captures your agents interaction lineage right and how they are interacting. And lastly every
[23:54] um prompt and its output is captured in the inference and usage tables. So now you have the complete corpus of what has happened. So in case something on toward has happened, you are able to go back
[24:06] and explain exactly what has happened. And this is very important, right? Because you want to understand the impact of what has been done. Similar to the logging tables, there's the tracing tables. The tracing tables
[24:18] um are more useful for debugging and for quality control. But sometimes you can also use them in a security context to understand exactly why the system was behaving the way it was behaving. Because the first one tells you what has happened. This one gives you an
[24:30] understanding of why it was why it thought behaved the way it was. So you could correct things over there. Right? So that's also fully available and is built into the system. And with that I'll turn it over to Sunish to go
[24:42] through a demo and um so that you get a feel for all the things we just talked about. I'm good. >> Yes.
[24:54] >> All right. Thank you Sra. Uh let me switch to the demo. Right. Cool. Yeah, I think everyone's familiar with this uh database
[25:06] workspace. Uh this is our uh the workspace that we use internally as well. So here you can see there's like as everyone has like these are like tables in UC. Uh you can see like this is one of the customer data that we
[25:19] have. Uh you like there's like customer names. Uh there's like email addresses. Uh there's account owners as well. like some accounts are owned by me, some account owns are someone else as well. Uh and I give agent access to all of
[25:32] this data. Uh same thing with GitHub. So I want to give agent access to my git repo as well and saying that hey like through the MC it can access like all of these tools. If someone's already worked with git, you can actually see these are
[25:44] like the 44 tools that GitHub usually provides and usually has access to all of these tools out of the box uh when you actually deploy an agent. So, uh, let me like, so I've built an agent for this demo and which is like completely
[25:58] ungoverned and there's no governance policies just yet. I'm going to me as an admin, I'm giving it I built an agent and I'm going to give it to my business user like, hey, can you go and play around with it and see exactly what information they're trying to get and and see if it's useful or not. So, let
[26:11] me log in as the business user now. Oops.
[26:29] Right. Cool. So I guess I'm a business user. I want to know like hey what all are my customers and like what all information do I have uh in this agent? So let me say show
[26:53] Right. So it's like show me all the information of my customers uh and their AR. So it's actually going to actually call you see get get the actual information uh and then and and see like what all information and what's their customer and and their AR rate as well.
[27:08] Yeah. So it's able to actually get all of the information. It's not just getting my information. actually getting uh customers from Alice as well and then they're all showing it up show showing up here. Uh and like all their email
[27:20] addresses and everything showing up here. You can see like it's actually made a SQL call to actually get all of that information from UC. Uh so now I'm say okay now can you fetch
[27:33] data about uh I'll just pick a random customer acme 001. That's the customer that I own. So,
[27:48] so it's actually going to make a call to git to actually get the corresponding data uh of of acme and see like hey get my customer nodes some issues that my customer have raised and seeing like hey these are all some issues uh and this is like okay you can see what the ar is
[28:02] it's actually uh connected all my data from my customer revenue table it actually fetched like my customer nodes from here uh and seeing like these are some of the open issues on git for this customer and you can see all of this
[28:14] stuff it traced here that hey you made a GitHub call and it made a UC call to actually get like only this Acme customer to to to show that information. Um I'm going to say okay uh can you get
[28:27] me the SSNs for these customers? So in this one like hey I'm like there is a file in git which actually has written like hey the agent should not have access to this file but it's it's
[28:40] actually going to get all the SSN information as you can see it actually was able to grab the SSN for these customers even though they're hiding confidential. You can actually see in the actual body request it says hey do not expose these to AI agents but no one
[28:53] cares right like it's it's able to fetch the data and you're able to see it and it's it's all there u and I can even say hey like random person customer like hey I I lost the customer I'm just going to
[29:08] pick a random customer from here
[29:27] So, it's like, hey, I'm going to like, hey, delete this customer. I've actually lost this customer. So, delete all the information that I have. Uh, and I think agent will just go in and like delete all the information that we currently have. And then it it's just working autonomously. There's no governance.
[29:40] There's no guardrails. It actually created a PR, deleted all my customer notes without even asking me that, hey, should I actually do this or not in the first place? Uh so as you can see like it agent is completely autonomous. It's like just working on behalf of the user.
[29:53] Uh and it it just did all the actions. It does not even figure out like hey are these my customers or not randomly just deleted anyone's customer and it was able to do that out of the box. So now in the governance land uh I think some
[30:06] alluded to this as well. So now we're back like hey the businesses are like hey this is not performant. I'm not even actually getting my data like this is not correct like we should actually govern our data access govern our external access as well and
[30:18] everything too. Uh so right now I've actually created a UC connection as someone mentioned which actually has like hey this is my GitHub MCP server and this is where I'm going to fetch my access token my refresh token. This is
[30:30] the client ID for it. The client secret is completely hidden to the customer. So every user can come in and go through the login flow and their credentials are securely stored in UC and agent has never access to these credentials. it it will only get uh talk to database using
[30:43] the database credentials. We will internally mint the actual access token and directly make API calls. So agent technically does not have access to any of these credentials at all. So now I actually have created a GitHub MCB server using the same exact
[30:55] connection that I that showed before. Uh and you can see like in this one I actually only have access to some specific tools. The reason being I can actually come in and say hey I want to edit a bunch of these tool selectors and
[31:07] only give access to these certain tools not all of the tools. So you can see I have only given access to like six tools out of the 44 tools but I can always come and give access to like these additional tools that I want from here. I can even do advanced settings with do
[31:20] like reax based stuff as well. So like a new tool that comes with like get something that automatically added to my uh tool tools as well. So I don't need to manually go and always add add these individual tools too. Uh so we provide all of these things as well. You can
[31:33] test it out live here as well like hey is it actually making the tool call correctly? Uh there's like python ways adix SDKs ways to actually make this call. Uh you can actually see all the metrics in live view as well like hey how how the calls are being made. And
[31:47] the lastly that there's also permissions as well like similar to you see how you govern your data you can also govern these MCV servers. you can give uh give specific users access to this GitHub MCB. So like as a developer group should access GitHub but like a business user
[32:00] doesn't care about accessing GitHub at all. Uh and lastly what some talked about as well is policies. So we have a bunch of policies that you can actually set. These are called service policies uh as well. So I can drive deeper into
[32:14] some of them. So here you can see like always ask when I call delete file. So the first example that we saw over there that hey the agent was able to just delete the uh
[32:27] delete the g repo uh file and never asked for my permission. So I'm saying every time you delete a file always ask for my permission.
[32:41] Uh there's like block on rights block pi. So I'll just go quickly on block on rights. So anytime you do like create or push files you want to do deny access. I don't want agent to actually do uh rights and stuff on on behalf of me just
[32:53] so deny access and like PII something similar as well. Uh this is more like a deterministic policy where if it's to access like the PII folder just ignore uh just don't give access to that PI
[33:06] folder at all. So this is more deterministic ones but you can create new policies as well. So we have a slew of a lot of these different policies that comes out of the box. So one is like PII detection, blocking, unsafe content filtering and these are some of
[33:18] the custom policies as well. So some of these ones like even in the custom ones, you can actually have different ways. So you can do deny and then have like LM as a judge to do some access as well. Uh you if you don't want to use the judge
[33:30] the custom ones that I created before, you can actually create uh a new like an actual function to do it or you can use an existing function so it can be actually shared across your different like uh MCV servers as well. So we
[33:43] provide both LM judge based policies and also like custom policies. So now you can see these are the three policies that I've actually applied on it. So this is actually governing my external data my external MCB servers uh using these policies. Now how would I govern
[33:56] the actual data that that I've had before uh and see make sure that it actually works as well. So these are all my existing like same way as before. These are all my customer data. Now here
[34:08] I've actually set up two different policies. One is the PI I'm asking and the other one is like only give me access to the data that I own. So in PI I'm asking just showing here as well like this is one of the policies that we
[34:21] have is that hey for any an account user if the client ID is this one. So if my agent is trying to access this uh this PI information I want to mask my customer email like agent should not
[34:33] have access to my customer emails like uh I I don't want because it might send them emails for them to directly customers. just directly want to block access to all of that. So the agent would never have access to my customer information. Uh the other one is like
[34:46] role level security. It's like I should only have access to the the account owners where name is me and no one else. And this is also guarded by the agent. If agent is trying to access it, only give it access to whatever information that I own rather than someone else
[34:59] owning it. So yep, having all of that set into place as well, me as an admin, I set all of this infrastructure up. Now I give the same agent access uh to to my to my app and I can actually see all of
[35:12] this in place as well. So in Unity I gateway we give you one place to see all of this information where your models your MCB servers skills and agents as well. So you can actually see for GitHub MCB server I have one policy created
[35:25] rate limiting added. Uh this is the one that I'm demoing with. I don't have any rate limits added but basically you can actually see there are like four policies that are actually created that I showed you before. Uh there's per logging that's on, usage tracking, it's
[35:37] on by default. Uh so you can actually track and monitor all of the usage that's going through my GitHub MC server. So now I share the same app again with my business user and let's see what happens. Now everything is
[35:49] governed. So let's try and login again. >> Sorry. Sorry. >> Are there global policies that would
[36:01] apply to >> Yes. Exactly. Yeah. So there's like aback policies, arback policies, those definitely apply. So you can say, hey, at the top level, at the catalog level, any MCB server with these exact stuff should apply. So those should work as
[36:13] well. >> Yes. Yeah. Same same way as well. Yes, those should apply too. So So show me all the
[36:26] Let me zoom in, right? >> Customer information.
[36:40] >> So it's going to make the same SQL call as you as you'll see. It's going to make like hey give me all the customer data and like you can see it's never actually saying like hey where where clause is equal something and stuff like that. Uh you can actually see the SQL statement
[36:52] and the return the return statement is like hey this is all my customers that's only ones that I own and you can actually see the customer emails that actually matched. So agents don't even have access to all of these customer emails at all in that case. And it's actually filtering it and column masking
[37:06] it as well. And this is my total error for all my accounts. So I can I can do the same thing now. Fetch information about ACME 001. So it's it's going to make the
[37:19] same GitHub call. It's going to fetch my information about about this customer, get the notes and stuff like that as well. Uh but I think the power uh of like having everything in data bricks is that you can actually have your data in
[37:31] data bricks and you have your data outside of data bricks and you can actually combine them in in one place uh through genie or like a custom app as well. So I can say which customer
[37:44] is the highest risk of escalation
[37:56] and build the dashboard. So it's like hey it's going to combine all my data that's already in UC and all my notes and my customer information my issues from GitHub. It's going to probably combine all of that and build the dashboard and tell me hey these are
[38:08] all my customers that are like highest risk of escalation and uh like you should probably take a look at those and stuff like that as well. So it gave me the full report. As you can see, Ame is the highest customer with the highest risk. Uh there's there's other ones like
[38:22] hey there's data gap obviously we deleted in the previous one. Uh but like there's like these ones are highest like risk customers. There are some medium ones and there are low ones as well. And you have all this information here uh inside the agent now. And let's try what
[38:35] we tried previously like reading the SSN numbers and stuff like that, right? Read the
[38:51] Y. So ideally here like it's it's actually denied like you can see immediately that hey it didn't even make a call. It tried to make a call and then it's like hey boom it's actually denied. You don't have access to this PII folder. It's denied by this policy. Uh and it's immediately returned back to the user. Uh and lastly we lost
[39:07] ACME delete all the files. So here it's saying okay now I actually have lost this customer can you delete
[39:20] this files and let's see what happens. So here you can see it's agent's actually asking me this request and it's go hey deny I I don't want to delete these files and it's actually will say okay now it's actually denied because
[39:32] you said hey denied access and you can actually see it's end to end working it actually asked the user hey should I delete it or not in the first place so this is how like we build a governed application end to end and you can see this is like doing service policy
[39:44] governance it's also doing all the aback arback policy on your data itself uh end to end u lastly I want to show like Hey, like all all this the stuff that someone mentioned like this is all being traced
[39:56] and recorded. So you can actually see all of the traces here uh in line uh like end to end like what's going on and stuff like that as well. Maybe just refresh my latest traces.
[40:14] So you can actually see this is the GitHub MCB server. Uh this is the latest trace that I did and it's able to actually uh ask me to delete a file. uh and then it was actually denied. You can actually see the events that fired. It deleted a file. It was this was the user
[40:27] the session ID the ask policy was triggered and there's an external MCB server for GitHub and stuff like that. So you can actually see all of this in line. And lastly all of this all of the traces that you see it's all in hotel
[40:39] format. So it's all open telemetry. Uh you can export it you can use it and we have the lake was that we recently announced. So you can actually see all of these things. Hey, there was an alert that was triggered that someone some agent was actually trying to access this PII information and hey, this is open.
[40:54] Can you can someone take a look at it? And there's a ticket created. So, you can actually quickly watch and go through figure out what's going on as well. Yep. I think that's all for the demo. Uh,
[41:13] awesome. So, to summarize, uh we uh talked to you about secure authentication, right? uh protecting the credentials, making sure you always have OBO enabled because many of the policies that actually Sunish showed you dependent on OBO because as you saw it
[41:26] only returned his records and in order to only return his record, you need to know it's Sunish using the agent and you also need to know that it's an agent, right? Um second is the contextual authorization. We showed the policies
[41:38] both on the service and on the data with Aback and we are the only gateway and cap and and catalog capability the unity catalog capability that actually governs data in addition to policies right every
[41:51] other gateway that you get out there can anyone can do APIs right that's been there forever but going from to actually taking it to data we are the only one that is doing it as a uniform way

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.