How to Govern and Audit Your Coding Agent Usage with Databricks
Summary
- This video addresses coding agent sprawl — where enterprises run multiple competing tools like GitHub Copilot, Cursor, and Claude Code without centralized governance — and demonstrates how the Databricks Data and AI platform enables end-to-end oversight.
- Coding agents generate 10 to 100 times more tokens than other AI applications, making cost tracking, usage auditing, and cross-provider policy enforcement critical requirements at enterprise scale.
- The Unity AI Gateway provides a unified control plane for enforcing permissions, applying budget controls, automating model switching, and capturing complete audit trails of prompts, responses, and tool interactions across all coding agent providers.
How to Govern and Audit Your Coding Agent Usage with Databricks

As coding agents like GitHub Copilot, Cursor, and Claude Code become embedded in daily development workflows, enterprises face a new challenge: how to govern and audit AI-assisted code generation at scale. Without centralized visibility, organizations risk exposing sensitive data, losing track of usage, and failing to meet security and compliance requirements.
In this video, we'll show how Databricks enables end-to-end governance for coding agents across the enterprise. You'll learn how to enforce fine-grained permissions, track usage and costs across teams, and capture complete audit trails of prompts, responses, and tool interactions. We'll also cover how to apply consistent policies across providers — so developers can move fast with coding agents while maintaining the control, visibility, and compliance production environments demand.
You'll walk away with the patterns to unlock coding agents safely across your organization — without creating a new compliance liability.
Talk By: Aarushi Shah, Software Engineer, Databricks ; Rohit Agrawal, Senior Staff Software Engineer, Databricks ;
Chapters
00:00Introduction00:36Coding agents generate 10-100x more tokens than other AI apps01:32Coding agent sprawl: every enterprise runs multiple competing tools02:13Multi-AI strategy: why locking into one model or harness is risky03:32Databricks internal workflow: plan with Opus, build with Sonnet, review with Codex04:11The incompatibility problem: auth, MCP formats, and non-portable skills13:19Admin policies: budget controls and automatic model switching13:57Demo: OmniAgent with Unity AI Gateway25:25Databricks at scale: 2,000 engineers running all traffic through AI Gateway27:26Recommendation: OmniAgent plus Unity AI Gateway
FAQs
What is coding agent sprawl and why is it a problem for enterprises?
Coding agent sprawl refers to the situation where enterprises end up running multiple coding agents — such as GitHub Copilot, Cursor, and Claude Code — across different teams without centralized governance. This creates security risks, inconsistent policies, hidden costs, and gaps in audit trails for AI-assisted code generation at scale.
How does Unity AI Gateway govern coding agents on Databricks?
Unity AI Gateway provides a single control plane that enforces fine-grained permissions, tracks token usage and costs per team, applies consistent policies across providers, and captures complete audit trails of every prompt, response, and tool interaction. This video demonstrates OmniAgent — Databricks' internal approach — where all developer AI traffic is routed through the AI Gateway.
How does Databricks use coding agents internally?
Databricks operates as customer zero for its own AI governance tools, routing all engineering team coding agent traffic through Unity AI Gateway. This video describes their internal workflow of using different models for planning, building, and reviewing — while maintaining centralized oversight across all 2,000 engineers.
How can enterprises control AI costs from coding agents?
The Databricks Data and AI platform supports admin budget controls and automatic model switching to keep token costs within bounds. This video explains how to configure per-team spending caps and policies that automatically route to more cost-efficient models when usage exceeds defined thresholds.
Full transcript
[00:09] Hi everyone. Uh firstly thank you for being here and thank you for attending data summit. Um I'm Rohit and I work on the data bricks AI gateway product and uh with me is Arushi. She'll be joining us later to give us a demo as well. Um
[00:23] first just a quick show of hands. How many of you use coding agents regularly? Awesome. How many of you have coding agents working right now for you? Awesome. Awesome. Right. Awesome. So,
[00:36] uh, you know, everybody's been talking about agents. Every billboard you see in San Francisco is about agent. Every SAS app has an agent. Your favorite finance app has an agent. You book flights using an agent. Everything is about agents, right? But I personally believe that the
[00:49] biggest breakthrough in the last one year has been coding agents. By most estimates, coding agents roughly contribute to about 10 to 100x more token usage than every other agentic application out there. And I think this
[01:03] makes sense because coding agents are increasingly being used by everybody and not just for writing code. We're using coding agents to debug production incidents, write runbooks. In my case, I use coding agents to build slides
[01:15] because I couldn't figure out how to make a certain animation work in Google Slides. And these jumps are quite real. I feel people have realized that with coding agents, you can become extremely productive. Now
[01:32] over the last one year, we've also seen the rise of coding agents lead to coding agent sprawl in every enterprise. Every enterprise has now at least one coding agent that they have procured. There is one more coding agent that like some select group of developers have access
[01:45] to and there's a third one that's like being procured right now. So in this talk we'll be going over some of the challenges that we see developers face. We we'll see some challenges that admins face. We'll walk through a
[01:57] solution that we are rolling out that we think solves these problems. And then finally we'll see how data bricks leverages these products internally as customer zero. So let's get started.
[02:13] Okay. So let's start with how this thing works. And this is I think where it gets super interesting. This space is moving extremely quickly and the frontier changes every single week. There is a new state-of-the-art agentic harness. There is a new state-of-the-art model.
[02:27] I remember in September, October last year, Geminy 31 Pro had come out, state-of-the-art. I went for winter break quickly followed up with Opus 46, state-of-the-art model. Sometime mid this year, GPD 55 came out, again, excellent model was followed up with
[02:40] Opus 48, great model. Geminy 35 flash, again great model. And then for two days we had fable amazing model. In the world where this thing is moving so quickly and the jumps are quite
[02:52] significant with every agentic harness in every model. We believe that you have to be multiAI. Locking yourself into a single agentic harness or a limited set of models is a bad strategy and risks you drifting away
[03:06] from the frontier. In fact, we see that the best engineers at data bricks are using the right agent and the right tool for the task they
[03:19] have at hand. I almost feel like some these models have started to develop personalities and there is no one model that can do everything. For example, I personally reach out to codecs when I want to do large
[03:32] refactorings. I use clot code when I want to decompose a large task into smaller subtasks. A very common workflow we see at data bricks is people plan using clawed code
[03:46] with an expensive and slower model like opus 48. Once they have the plan in markdown then they build using a cheaper faster model like sonnet 46 and then finally do a full code review and write
[03:58] tests with codecs. The power users at data bricks are going a step further and orchestrating a swarm of sub aents using custom skills MCPs that run over long time horizons think
[04:11] overnight. But reaching this end state is actually not easy because these tools actually don't play well with each other. All these agent harnesses are like a
[04:24] little world garden. They have their own authentication mechanisms. They have their own ways of defining MCPs. The skills are not transferable between the two and this is by design. These agent
[04:37] harnesses want you want to lock you in. And there is a real friction to move from one to the other.
[04:51] In addition to this, these agentic harnesses are only as good as the context and tools you provided. You should think of your coding agent as the most privileged user. It has access to Slack, Jira, company
[05:05] docs, cloud, infra, CI/CD, every single thing that you have access to and it should. This is how it becomes productive and it can operate over long time horizons. But this is also a nightmare for a lot of admins. This is
[05:17] the security and governance risk. And we believe that one of the major reasons why coding agents have have not had a lot of success in enterprises is AI governance.
[05:33] We've been talking about the developer, but let's think about it from an admin perspective. Every new agent that your company procures is a headache for the admin. There is a new admin portal to manage. There is fragmented billing.
[05:45] There is no one place where you can define policies. Someone is asking for a claw rate limit bump. Somebody's asking for a cursor rate limit bump. And the admin is just trying to run from one place to the other time to manage this
[05:58] thing. So where does that leave us? In most organizations we talk to, there is an IT leader or an engineering leader who's been tasked with rolling out coding
[06:10] agents. And we see them on either of these islands. The first one is when they have spent a lot of effort trying to procure one tool and a lot of effort to make it
[06:22] productive in their organization. But as these agentic harnesses are launching new features and new models, there is a slow approval process. They're constantly stuck behind the frontier and there's a loss on productivity.
[06:35] On the other side, in some organizations, we see procurement very easy. People can use any tool they want. Developers are token maxing. Costs is going through the roof. There is no security in governance. People are
[06:47] running clawed with flags like dangerously skip permissions. Running codeex with full auto. And so you're having to choose between freedom or safety.
[07:02] So how do we bridge this gap? This is the problem that we've been working on for the last couple of months where we want to give developers freedom and admin safety. So what's the ideal end state? We believe that the ideal NC8 is developers
[07:15] have freedom. They have access to multiple coding agents, not just one. They have access to the latest state-of-the-art models. There is no switching friction. So, you can go from one agentic harness to the other. All your MCP skills and everything works.
[07:30] And you can do this over long time horizons without constantly being interrupted for permissions. For the admins, what does this look like? We we see admins want to set one budget policy that's applicable across
[07:44] all coding agents, have one unified billing, have observability to see who their power users are, what tools are they using, how can they be effective, and then finally set guard rails and policies to
[07:57] make sure that PII data does not leak. We believe that this Omnient along with Unity AI gateway is the solution that will help us reach there.
[08:11] So what does this mean? So on the left you see Omnient which we believe is a developer open-source tool. If you saw the keynote today, Mate described this as a meta harness. So it
[08:25] wraps over popular harnesses like claw code, codeex, gemini and ensures that you can easily switch between these two or three and all your MCP skills everything works across all of it.
[08:38] For the admins every single request going from omni whether it's inference traffic whether it's MCP traffic all goes through the gateway. Unity gateway is a place where admins can set policies, budgets,
[08:53] enroll everybody in tracing to have all the data logged in Unity catalog and from the gateway the inference traffic can either go to models that are hosted in data bricks or external models that could be hosted in your cloud
[09:06] provider like bedrock, vertex, foundry, openiropic. Similarly for MCPs they could be hosted within data bricks or they could be MCPS hosted elsewhere. And then finally all the tracing and all
[09:18] the usage data gets logged in open formats in Unity catalog where the rest of your data lives. We believe that this architecture gives developers the freedom and admins the
[09:30] governance that they want. So what does this look like for developers? There is one login.
[09:42] All your tools get authenticated with the same oat token whether it's access to models or access to MCPs. You can easily switch using Omni Cloud, Omni Codeex, Omni Gemini.
[09:56] All your MCPs and skills work across all of these things. Okay, this is great. So I want to call on Arushi, my colleague, who's going to give us a demo of what does this look like in practice.
[10:18] Okay. So, I'm going to go over a few workflows on how you can integrate Omni Agent with our Unity AI gateway to help simplify the setup, governance, and observability of your coding agents. So, let's start from scratch on a fresh
[10:31] terminal. And getting started with Omnient is as simple as just downloading the GitHub repo um from our data bricks oss repo and then running this omnigent configure command to get everything set
[10:44] up. And this is a one-time command that you run and then the state is locally saved on your laptop but you never have to log in again. So first Omni will prompt you for your data bricks workspace. So this will be the workspace where your Unity AI gateway lives. Once
[10:58] you authenticate, um, Omni will actually pull in a managed configuration that your admin has set for you and we'll pull it in and use that information to actually set up the authentication and
[11:12] MCPs and everything else um, for your coding tools. And so, as you can see, this setup command just took a few seconds. And now my coding agents are actually all ready to go um, ready to use. And so, this configuration contains
[11:26] a little bit of important information. So, the first thing it contains is all of the coding agents that my admin has actually approved for me to use. In this case, we actually have six different um coding tools that my admin has approved
[11:38] for me to use. Now, this is awesome because now developers get the freedom of choice. Um they're not just locked into one coding harness. They're actually encouraged to use different harnesses for different types of tasks.
[11:51] And then the next thing we have is MCPs. So our admin has chosen these different MCPs for us to use. So this includes Slack, GitHub, Atlassian, and Data Brick SQL. These are actually um out ofthe-box
[12:04] MCPs that um data bricks provides with the Unitya gateway. So the admin didn't actually have to do any um extra setup. Um just select these MCPS and the admin
[12:16] can actually go a step further and even control the types of tools behind these MCPS that they want to allow. So, if I step really quick into the datab bricks workspace that we just logged into, you
[12:28] can actually see this is the MC the GitHub MCP. And let me zoom in here. We have all of these tools that our admin has approved for us. Um, such as get commit and get tag. And I have admin
[12:42] access, so I can actually go in and edit these tools. But this is great because for some MCPs, maybe you want to give your developers read access, but you don't want to give them write access. So the admin can actually configure this
[12:54] all in the gateway and it will get applied automatically to every single coding agent. So going back here, the last thing that we have um configured here is um contextual budget policies. So here our
[13:06] admin has set a a default of $100 per day for me to use across all my coding tools. And then at 100% they are going to block me from using more. So this is again a tunable parameter. instead of
[13:19] blocking, our admin could also choose to switch us to a different model and harness that's cheaper. Um, but in this case, we are going to be blocked. And then we also have some budget policies to c actually like point us in the
[13:32] correct direction of how to, you know, manage our spend. So once we start reaching our um 100% usage. So around 80% we will actually be prompted to um start using omnient with open code and
[13:44] data bricks kimmy which is a much cheaper model. Uh as you'll see that data bricks Kimmy is also extremely fast. So we're not going to be um giving up any efficiency here. Okay. So everything's set up now. Now we can
[13:57] actually just jump in to coding with the simple command omnigent cloud. And what it will do is pull in um the authentication from our gateway and drop us straight into the cloud code UI. So
[14:11] this is also great because um we get dropped into the native harness UI that we're all used to using. you don't have to get um used to another type of UI if you don't want to. And as you can see here, I've been coding a little bit
[14:23] already today. So, I've used up 55% of my budget, but the recommended harness is still claude code with um Opus 4.8. Sorry, lost my cursor. Um and so that's
[14:36] why Claude Code has launched here with Opus 4.8. But if I want to change the model, it's very easy. This is the classic um way to change the models in
[14:51] cloud code. And as you can see here now, we have all of the data bricks um foundation models already locked and loaded ready into cloud code for me to switch between. And so these are actually the um foundation model APIs
[15:03] that data bricks hosted. So you're using the um you know data bricks capacity. You don't need to go and sign any contracts with different vendors here. Okay. And so now um let's get started
[15:15] with working. So let's say that I am owning a you know online retail API and I'm working on that and I'm getting a lot of customer bugs. So I need to you know investigate some things. So I'm going to ask Claude code um to summarize
[15:31] the latest bugs from the customer support channel. So here what will happen is that cloud code is going to actually start using um my Slack MCP server that I have um set up and it's
[15:47] going to start um reading my Slack messages and helping me summarize. So I didn't actually have to do any extra configuration here to go log into the Slack um change some configuration files. Omnigent configure took care of
[16:00] all of that. Now while this is happening, let me launch another parallel work stream with codeex. So same thing happens here. We're going to be launching codeex and we get dropped into the codeex UI. And as you
[16:12] can see the MCP servers, the same ones that we had configured before are going to be configured inside of codeex as well. And here let's say I want to say um pull my latest Jira items and
[16:26] items and start working on the highest priority one. And so here similarly um we're going to start using the Atlassian
[16:38] MCP here to grab all my work items and kick off um some tasks here. So hopping back here, you see that it's found all of my bugs and you know now I need to kind of investigate more into
[16:50] these bugs. So I know that a lot of my customer data already lives inside of the data bricks workspace inside of Unity catalog. So this is actually a great use case for data brick SQL MCP
[17:02] server because I can actually just ask claude code questions about my data and it can help me investigate. So I can ask it um how many customers were affected by the shipping bug.
[17:20] And so what's going to happen here is cloud code is going to start kicking off the data brick SQL MCP server and it's going to go through my um tables and get some information for me.
[17:32] Cool. And this is still running as well. And so, you know, let's say now I'm going to ask Cloud Code to fix the shipping bug, but let's say I want to go for lunch now. And I don't want to take
[17:44] my laptop with me, but I still do want to be managing these agents when I'm away. And so, the great thing about Omni is you can actually run it on any device. So, your device, your co-workers's device, even your phone.
[17:57] So, what I'm actually going to do is I'm going to pull up my phone here, and I'm going to
[18:29] Let's see if this works. Okay, there we go. So, I can open the Genie app and here I'm launched into the Omnigence repo and as you can see um I have my shipping bug um little sessions started here and I can just go and say
[18:42] add some unit tests and Claude will get to work while I'm gone. And if we go back here, we can see that the unit test um has started working. Cool.
[18:56] So now actually when we come back here to codeex, we see something interesting has happened. I've gotten a little warning that's saying I'm nearing my daily budget. And so we actually have these are admin added hooks into all of
[19:10] these coding agents. So this is really useful. It's not going to actually stop me from doing any work, but it's going to be reminding me that hey, you only have 83% left. So, uh, or you've used up 83%, so maybe you should, you know,
[19:22] consider moving to a cheaper model. And, you know, if I actually launch omni aent codeex again, what will actually happen now is that it will even prompt me um to switch to data bricks um, open code with
[19:34] Kimmy. And if I do that and just say continue my Jira work items, you can see that um Kimmy is actually pretty fast. Um so you know and it has
[19:47] access to the same MCPS here as well. So we can just continue with Kimmy and it's going to be much cheaper. Okay. Now a few more things I want to show you. So one is that um our admin can
[20:00] actually also set some security policies for us. So this will be useful if you know they want to make sure that all of their developers are using these coding tools in a very safe and secure manner and not exposing any sensitive
[20:13] information or PII to these different harnesses. And so my admin has actually configured some of those for me and we can test it out. So let's say that I have you know this little snippet. What
[20:26] it says is, you know, I'm trying to test a data bricks authentication token and it pastes the data bricks token in plain text. And if I just paste that here, and what you'll see is that um immediately
[20:38] the prompt was rejected because we have these little hooks um set in place by our admin that say data bricks token was detected in the prompt. Please don't do that. So that is also great because our
[20:50] uh admins can now be at peace that you know we're going to be using these coding tools in a safe manner and not exposing any sensitive information. Okay. And finally what I'm going uh last thing I will show is um you know so we
[21:03] showed that we have these budget policies and that we can have live budget tracking so we know that when we are nearing our spend and how much we are using. Um, and Omnigen also exposes
[21:15] this nice little command called omni usage. So this will actually show us our historical data. Um, so what this will do is prints us a nice little summary of all of our coding agents over the last week. What is our usage? So it
[21:28] summarizes, you know, how many sessions did we run, how many tokens were we spending, and what models were we using. So this is really helpful both for the admin and for myself as a developer because I get to see you know what is
[21:41] like my what type of efficiency do I have with different types of tools you know what are my like top models and I can kind of edit my AI usage um accordingly
[21:53] okay now I'm going to pass it back to uh Rohit to do some admin workflow demos
[22:09] So we saw all the developer workflows. Now I want to show you some admin service areas.
[22:22] Okay. So the first thing I want to show is that this is the Unity AI gateway and uh you can see this is your registry of all the models MCPS providers etc. So you can see these are the models that Arushi
[22:35] was using. In addition to that you can see the MCPS that she was using. She was using the Atlassian MCP and the Slack MCP etc.
[22:48] The other thing that's amazing with Omnient and I think this is like a great data bricks advantage is that we can trace all your usage and data. So we can see all the traces from all the developers like coming in.
[23:00] Let's look at one particular trace here. So you can see in this case I was able to see the token count, latency, session ID, who was the user. I'm able to see
[23:12] which model was called, what was the prompt. I can see which tools were being called. So this was an extremely long session by a user. And this is great by having access to
[23:25] all your tracing data live in Unity catalog. You can do a lot of analysis. For example, in our internal usage, we had done an analysis where we found out that clot code had shipped a feature
[23:38] where in the terminal they print a summary of your work. And we noticed that that particular feature where it enables summary of your work had increased our token usage by $5 million.
[23:51] So these agentic harnesses are constantly releasing new features. And without the ability to trace everything, you have no visibility into how your costs are going up. Are your users using
[24:03] the right model? Are they using expensive model for tasks they should not be using? In addition to full tracing, we also log a lot of the data in delta tables and
[24:16] provide users with like rich out of the box dashboards that you can customize. So you can see requests, tokens, users, daily requests, who are your top endpoints, models, users. You can see performance like your time to first
[24:30] token, fallbacks, etc. You can look into cost analysis and go deeper there. And then finally, you can also set budgets.
[24:42] So this is again a data bricks feature where you can go and set per user budgets. So in this case, I've set a budget where every user gets a $100 to spend per day
[24:54] across all the coding agents. If I go into per user spend, I can see that a few users have already exhausted their limits. I can see how much they're over threshold and I can see also all the users are who are below their spend.
[25:13] So these are just some of the admin workflows in the Unity AI gateway. There are several more for governance.
[25:25] Okay, so going back to our demo, going back to our slide, sorry. Um, let's look at how data bricks is actually leveraging this. So data bicks is a very large engineering organization, over 2,000 engineers, and we use coding agents extremely heavily within data bricks.
[25:39] So as I mentioned, data bricks has over 2,000 engineers, many engineering offices. the S7 languages but it has increased to nine now and a very very high code throughput organization and we run all of our coding agent traffic
[25:52] through the AI gateway. We've noticed three parts for coding agent adoption. The first is we want to measure everything. We believe that you cannot improve anything that you can't
[26:05] measure. And so by going through the gateway the first thing we get is observability. This is a modified version of the dashboard that I was showing you where our internal dev tools team combines the
[26:18] AI gateway usage with data from workday to figure out which teams are using agents heavily are engineering managers leaning in are IC's leaning in, who are the power users, which coding agents do
[26:30] they use, etc. In addition to that, we believe that everybody in the organization needs to start leaning in with coding agents. It makes it super easy for managers to
[26:43] start contributing code. You can see with this Ali is now starting to send PRs within data bricks and I believe your CEO also should be leaning in with coding agents.
[26:58] And then lastly, I don't think we've solved every problem. I just believe that we're increasingly spending more time within data bricks on things like code reviews, scaling CI testing, etc. and increasingly spending a little bit less time writing code. So the
[27:10] bottlenecks are just shifting to a new domain.
[27:26] yeah. Um so I'd encourage you to try Omni Aent. Omnigen is available at omni.ai. It's an open- source product that you can start download and using. Uh we think that for admins the best way to use Omnient is to combine it with a gateway. Uh we recommend the data bricks
[27:38] Unity AI gateway which has a lot of these features, policies, budgets, tracing, etc. All built in. And we think this combination of omni which we demoed along with the gateway provides developers the freedom and admins the
[27:51] governance that we've been talking about. So yeah, that's the end of my talk and happy to answer any questions, anything that you'd like to know.
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.