Redefining Detection Engineering With Interactive AI Agents in the SOC

Summary

A major hedge fund deployed a human-in-the-loop detection engineering agent—built with the Mosaic AI Agent Framework integrated into Databricks Notebooks and Apps—to accelerate detection baselining, anomaly detection, and false-positive filtering while keeping engineers in control of final logic.
Databricks Lakewatch was announced as a new SOC integration with three pillars—open architecture, human-in-the-loop design, and built-to-scale detection engineering—with early results showing 60–70% cost savings at Rivian and Standard Chartered.
The modular architecture supports adding capabilities like MITRE ATT&CK mapping and threat intelligence enrichment without rewriting core logic, using Genie and SQL as the foundation for detection baselining.

Redefining Detection Engineering With Interactive AI Agents in the SOC

AI is transforming how Security Operations Centers (SOCs) operate, with tools that augment detection engineers and analysts to combat threats. We show how one SOC at a major hedge fund adopted AI to enhance detection engineering, accelerating creation, and minimizing response time. By integrating the Mosaic AI Agent Framework with Databricks Notebooks & Apps, this SOC provided detection engineers an AI assistant within their existing workflow. This agent accelerates detection baselining, anomaly detection, and filtering false positives while giving engineers control over final logic, ensuring human expertise remains central. The modular architecture enables adding capabilities like MITRE ATT&CK mapping, threat intelligence enrichment, and custom patterns without rewriting core logic. We demonstrate this assistant and how Databricks AI tools, including Genie and MLflow Evaluation, contribute to faster development, increased efficiency, and shortened response times to emerging threats.
Talk By: Chandhana Padmanabhan, Sr Specialist Solutions Architect, Databricks ; Riley Nastase, Senior AI / ML Engineer, Rearc ;

Chapters

FAQs

What is the human-in-the-loop detection engineering agent?

This video describes an AI assistant built with the Mosaic AI Agent Framework and integrated into Databricks Notebooks and Apps to help detection engineers write and baseline security detections. The agent accelerates creation but keeps human engineers in control of the final detection logic.

What is Databricks Lakewatch?

Lakewatch is a Databricks SOC integration announced in this video, built on three pillars: open architecture, human-in-the-loop agent design, and a platform built to scale detection engineering. Early customers Rivian and Standard Chartered reported 60–70% cost savings using Lakewatch.

How does Genie support detection engineering on Databricks?

Genie and SQL form the foundation for detection baselining in the agent architecture, allowing detection engineers to query security telemetry in natural language. This helps engineers identify normal versus anomalous behavior patterns without writing complex queries from scratch.

Why do AI agents need human expertise for security detection?

Generic AI outputs without domain context tend to produce detections that are too broad or miss attacker behavior patterns, increasing false positives. The human-in-the-loop architecture ensures that engineer expertise shapes the final detection logic, while the agent handles tedious baseline research and filtering.

Full transcript

[00:07] Uh thanks for coming to our talk. This is redefining detection engineering with interactive AI agents in the sock. So last year we worked with so rearch and data bricks worked with a major hedge fund to build out a a baselining agent
[00:20] to assist detection engineers in writing their detections. So, what we'd like to do today is walk through some of the things that were important to us as we were building these out to talk about some of the things we learned to do a quick little demo to kind of show this
[00:33] agent in action and then we're going to talk about what this looks like going forward because as we know the tech changes so fast the way you build agents last year is not the way you build agents this year especially with products like watch. So before we get started let's introduce ourselves. So
[00:46] before we do and I promise this is relevant. Uh, this is going to come out a little bit in the things that I say, but am I the only one or is there anyone else that like in the last two years or so has discovered that they like reading again? Like reading like actual stuff
[00:58] that people wrote. Yeah, I see. Yes. Like AI has made me love reading again. Not because AI can write, because AI can't really write, but because then I see people write stuff with actual opinions and I'm like, yes. So that's
[01:11] just remember that. That's an important part even as an AI engineer of where I'm coming from as I'm building out these tools. But I'm Riley Nasi. I'm an AI and ML engineer. I have a background for the last eight years or so building ML applications. And now since everybody
[01:25] wants AI, I kind of got forced into I'm building AI applications now. So I've been doing this for a few years across cyber security, healthcare, financial services these cases. I'm coming from North Carolina. So hockey fans, go Canes. Stanley Cup champs. Love that.
[01:38] And if I'm not in work, you I'm usually with my wife and my three kids just having a ball. So I'll pass it over to my co-presenter. >> Thanks Riley. Um hi everyone. I hope everyone's having a really good summit. I know this is like day two, day three
[01:51] for some of you. Uh this is probably my 10th summit. Although most of most of the summit like uh when I've been on the top, it doesn't have any Wi-Fi. So uh basically I love spending time outdoors
[02:04] and outside of work. Uh when I'm not helping customers build a IML solutions at data bricks, I love actually being outside uh away from my screen. Uh so spending time during summer hiking uh
[02:17] and then during winter skiing. I live across the bay in Oakland um uh with my husband and my uh dog. And actually my husband is here uh in the in the audience. So I'm a little bit nervous,
[02:30] but it's okay. We'll we'll we'll get through this. But yeah, I've been working at Data Bricks um uh for like four and a half years. And yeah, we're excited to do this. >> All right, let's do it. How many of you are from like you work in the cyber industry or you work
[02:43] specifically on you know cyber security use case at your companies? Okay, a good a good amount. So you don't need the slide, right?
[02:56] mythos. Rest in peace mythos, right? We have well at the keynote yesterday, what did we hear? In the next six months, more software is going to be written than has been written in the entire history of humanity. As Mario Zechner, the creator of the PI agent says, more
[03:09] software equals more boooos, right? More vulnerabilities, more exposure, more things to be alerting. So, we're working with our customers, this customer in particular, to figure out how do you scale to this, right? How how do you
[03:21] build out your methods of writing detections in a way that you can keep up with these workloads? And the truth is it is often still quite manual. So to talk about a detection for a moment, a detection in its simplest form is a
[03:35] query. A query with wear conditions, with filtering conditions. Something passes through those filters and bam, that's that's the kind of thing that you're trying to detect that you want to alert on. But writing the detection itself, writing the SQL is fairly
[03:48] straightforward. Most of us have written SQL. We're at a data bricks conference. If you haven't, you have tools like Cloud Code, which is pretty darn good at SQL. The hard part is understanding what query do I even really want to be
[04:00] writing here. Do am I writing out this these filters in a way that represents the normal patterns of my data? What users are allowed to do? What? What does this data look like? Am I accounting for the right trends and activity as I'm
[04:12] forming baselines so that I'm detecting on the right stuff accounting for normal patterns of everyday use. So that's the hard part. It's very iterative. It's a ton of queries. I have an idea. I'm going to inspect some data. I'm going to
[04:24] try to distill that. I'm going to join in another table and round and round and round we go. This is the way many organizations still work. I'm going to go in, I'm going to acclimate to the data and it takes a while to really figure out what's the right detection
[04:37] that I'm trying to build here. And that's what we're doing from a baselining perspective. So, what do we do? Just automate it, baby. Right. Just automate it. No, no, no, no, no, no, no, no. So, how many of us use coding agents?
[04:50] Yes. Um, cloud code users. Cloud code. Codeex. Anything exotic like Pi or Open Code? I got a couple in the back. All right, cool. Um, what happens when you're using one of these agents
[05:03] and the goal isn't very clear and you haven't made the goal very clear or what your agent needs to know to succeed is all over the place or there is certain information that you are relied upon for
[05:15] that agent doesn't intuitively know or intrinsically know and you're not there to tell it what to do. How well does that usually go? Not very
[05:27] garbage. Too many assumptions. The model just kind of is like, "All right, they want a detection. I'm going to go write a detection, right?" And on and on and on we go. And you end up having to rewrite the thing. So this is these were
[05:39] the things we were trying to balance with our customer. The the urgency on time is a real factor. We need to be able to write detections faster and we want to leverage the tools we have at our disposal. But at the same time, we
[05:51] have to slow ourselves down enough to know that we trust the things that we build, that we know what's actually being detected, that it's accounting for all the right patterns in our data, and also that they're built in a way that we
[06:03] can build on more in the future. So that's what we're trying to do. Now, when we built this out, this isn't really an architecture talk, but here's an architecture slide. It's a data conference. So at its root, this is a this is a lang graph agent that oversees
[06:15] these steps in the baselining process. We saw the hypothesizing, the segmenting the data, calling different tools to bring ambiguity to the forefront, all of these types of things. We use lakebased for managing memory, not a lakebased talk. If you're curious about why I
[06:27] think lakebase is a great fit for agent memory, talk to me after the talk. Um, got lots of opinions. We used MLflow for evaluations. And in terms of that final artifact, we either want a a a path to a
[06:40] detection. So a query that someone can go and turn into a detection or even just a conversation that helps a user understand, okay, I know my data better. I know how to think about my data better or an investigation notebook, an artifact, something that can live in
[06:53] data bricks, perhaps be version controlled that other people can review and use to better understand their data. So again, this isn't an architecture talk. I'd like to talk more about the disposition we're bringing with us as we're trying to make agents work in the
[07:06] cyber domain. And this is this is the thesis of the talk, right? I I I don't want to get into this like, oh well, agents just do everything. I've been working with these tools. I have strong opinions. That's probably obvious by now. I'm sorry. You can't outsource
[07:20] expertise, right? The the people who have experience in certain domains have to be able to leverage those domains and use the tools at their disposal to take care of some of the busy work so that experts
[07:33] can leverage expertise where it actually matters. Because you can you can put stuff into semantic layers. You can upload data. You can give context. But still, for those of you who realized you like reading books so much, it's not the same. You could have all the data there.
[07:46] You can be trained on the same data. You can use all the same data as context. But there's still something different about what a human is bringing to the table as opposed to how an agent is solving a problem. So everything we're doing as we're constructing this agent, the tools that feed the agent, the way
[07:59] we manage context is about leverage. I'm not trying to replace a human workflow. trying to use agents to augment the human workflow and to expedite those very repeatable
[08:11] deterministic parts of the workflow. And we're going to talk about a few of those things. So, first, as you're building out this agent, I think it's really helpful to talk to people. Um, a few engineers probably got a little nervous.
[08:24] you if you don't talk to people, you're forgetting the reality that oftentimes we're using agents to do jobs or to do certain tasks that people are already doing today. And in many cases, they're
[08:36] doing them quite well. And we would be fools to simply just say, "All right, throw an agent at it." Without taking those learnings away from people who have really understood how to go about this process, right? Another thing is, and we did this by having the detection
[08:49] engineers come and co-pilot our agents as we were building it. I don't know what they're looking for. I don't know the processes in their company. I don't know the way they typically baseline. I don't know um how they intend to use these at the end of the day or integrate
[09:01] them into their system. So, I want one of their engineers sitting with me and playing with this agent that I'm building so I know how exactly they want to interact with it. And lastly, I'm getting into the documentation that's been that's been created already. Again,
[09:13] they've poured a lot of thought into what baselines ought to look like. So, we're building out agents who really have to have a lot of respect for those things so we're building out the right thing. And if we don't, we will build the wrong thing. Another thing we're doing is we're extracting steps as
[09:26] tools. So this was a really fascinating thing for me as we had we were really fortunate to have a ton of access to people who had done rigorous investigations, rigorous baselining, and gave us reference material. And what you'll often find is um that there are
[09:38] these queries that fit into, you know, families, right? You're you're doing some um high level analysis of the data. You're grabbing a schema. You're getting a sample of the data. you want to understand what the data looks like or
[09:50] you're doing percentile baselining or you're computing a zcores or you're doing some more complex aggregations or you're evaluating how well the detection is working. We found that we could abstract about 90% of what detection
[10:02] engineers are doing in a baseline use case into six or so Python tools that an agent could call without having to give the model direct access to writing SQL. It was parameterized. they can pop in
[10:14] some inputs and then do a lot of what was necessary to create a baseline. Now, it's easier these days to let an agent run SQL. That's kind of the entire foundation of Genie 1. We're going to get to that in the Lakewatch portion, but for now, this is where we were in
[10:26] 20125. Another benefit of this though was standardization. We heard a lot from the detection engineers we worked with at this company. Everybody does detections a little differently. The queries all look different. Um, there's it's very disperate in terms of how they're
[10:39] communicating, way the baselines are created, and it was a headache for many people in the organization. So when you are able to extract meaning into tools like this, then you do standardize the process. You make it more repeatable. It's easier to keep everybody on the same page. And lastly, I think this is
[10:53] the most important part. So, what I'm getting at here is if you want to if our goal is leverage and we're coming from this place of an agent is going to want to run and go do
[11:05] something, but somehow we have to get the agent to stop and ask, you're the one who knows what's going on here. What do you want to do? You have to attack that at the prompt level. Well, why is
[11:18] that? The way these models work, they are trained via reinforcement learning and they're graded, you know, positively on good outcomes and negatively on bad outcomes. But one of the side effects is they're they have a strong bias towards
[11:32] a resolution. I want to create a baseline. Agent goes, great, I'll make a baseline for you. And they're not designed in a way that's very conducive to them stopping to ask questions to make sure the right thing is built. So,
[11:44] we really have to go after this um at at a prompting level. We have to give the agent a different goal. So somewhere in the system prompt in the tool prompts we have to articulate not just don't come back to me until don't
[11:58] just go make a detection. You have to give it something else to pursue. You have to say go explore and find ambiguities that might look like this. Go explore and find things that you are not able to answer with your
[12:11] understanding and bring those things to me and let me handle that. And that's kind of that's kind of how you go about that. And another reason why this is really important. How many of us trust like LLMs to make important decisions?
[12:25] Wow. Okay. I expected at least one hand like All right, we got one hand. Thank you, sir. Um so, um All right. So, um I like to tinker. A confession. Uh a couple weeks ago, I switched from
[12:37] Windows to Linux. And I promise it's not because I wanted to look good doing a cyber security talk. I promise. Um I just needed a project to work on. So, you ask Chad GP a question like, "Hey, what Linux distribution can it use?" And it finds pros for everything, right?
[12:50] Like, I dropped a piece of celery on the ground. Should I eat it? Well, if you're interested in that nostalgic dirt flavor, it it's it's ludicrous. They're just not sound at having opinions and expressing those opinions and making trade-offs. So, again, experts have to
[13:03] be making these decisions and we have to instruct the model in creative ways to ensure that they're bringing the human back into the loop here. And lastly, before I get into the demo, what about speed? I thought the whole point of
[13:16] agents was agents can go do all the work and I can sip on my coffee and then the stuff gets done and it's all really good. One I would say again if you've worked with coding agents, I don't know how many of you have done this thing where you just like one more prompt, one more prompt, almost there. One more
[13:29] prompt, keep going. And then you're two or three hours or four hours or two days in and you go this is garbage. somewhere along the way I stopped paying attention or I lost the discipline that
[13:41] I needed really to enforce here. That's a lot of wasted time, right? That that's a lot of wasted time. So I want us to in invest a little bit more time earlier on or in the process so that we're confident in what's being built. And in
[13:54] the meantime, if we look at this iterative baselining process, the inspection of the data, some of the baselining calculations, the stuff that's going on, the LM is still saving you a lot of time. So again, the the big point I'm saying is I think there's a
[14:06] lot of value in slowing down and it caused the model to slow down so that you can speed up in the long run. So with that, I'm going to move over to a demo because it's more fun to see some stuff. >> So um this demo we built with it's
[14:19] echoey over here. We built with a a synthetic data set from Carnegie Melon University and it just represents organizational data. Synthetic organizational data. You've got a bunch of people in this company.
[14:32] They send emails, they, you know, plug in USBs, they go to websites, all that kind of stuff. Okay, so here's here's our our little boring app. And we want to say, I want to create a
[14:46] detection to identify internal Riley can't type data movement. There we go. And hopefully the internet is good enough for this to work. This is the
[14:58] scary part. I was like, "Okay,
[15:11] So, we can see the functions that are passed in and then some of the data that comes back, all those goodies. And it'll tell us I found a productivity table. Um, there's some several measurable things yada yada yada." But one of the things we get across is, well, internal
[15:24] data movement, it's not like that's a field. So, let's let's get a little more granular here, shall we? like what what are you looking for? And in this case for this particular detection I want to focus on workstation policy
[15:36] users have assigned PCs and ignore shared PCs. This organization in the data set has like a computer lab. I don't really want to get too much the nitty-gritty with this kind of stuff
[15:48] right now. So it's going to spin and it's going to do a little bit more analysis and it's going to split the data up in various ways and explore a little bit more. Okay, so this changes the interpretation
[16:00] a lot. Goody goody. Oh, there's a caveat here. Okay, so IT admin, they account for 237,000 of the 245,000 events. So somebody's doing something on their non-assigned PC. This is almost all IT
[16:13] admin. That makes sense. Do you want me to separate them out or exclude them? Exclude them. Focus on nonIT admin and non assigned PCs. Okay.
[16:28] And it's going to spin a little bit more and it's going to do some more digging and it's probably going to look into different types of things you want to measure. Now, in another more complex workflow, this would be a really good chance to go look at what other
[16:41] detections have already been written and say, okay, well, you already have detections that cover this scenario. You already have detections that cover in this scenario and so on and so on. But it's doing this and we've targeted a few different paths.
[16:53] Um, so we've w we have winnowed it down to 7,900 total events, mostly the log on log off. There is some like file access and some outbound email. There's some
[17:05] removable media activity, some local file stuff. Let's let's actually baseline the file access plus outbound attachment email.
[17:20] Now, when I say baseline and I ask him to baseline again, it's going to start understanding some of the behaviors around this data set and it's going to start making some recommendations. Another thing it'll likely do here is run a tool called evaluate candidate rule. This was something that the people
[17:33] we were working with held dear before, oh, here we go. Evaluate detection rule. Before they put one before they actually, you know, send one of these things off in a schedule, they don't want to be like, well, great. I launched a detection because it looked good and now it's triggering 80,000 times a day
[17:45] and somebody has to go review those things. So what evaluate detection rule is actually bringing it's back testing that over the last x number of days whatever the model decides saying if this had been implemented a month ago and we implemented on the schedule this
[17:58] is what that would have looked like in terms of the alerting that you would see and we get that and we get again various thresholds if you were to choose these different thresholds greater than one file open greater than three greater
[18:10] than five here are the different alerts that you would see and I'm just going to wrap this up by saying package the most sensitive option. I still can't type in
[18:22] that list. So, this would be the first one. And then you'll
[18:34] detection query, too. And and there we have that. So, one of the things I want to get across here. And there's there's a there's a nice fun query. Okay. So it's a demo, right? Like
[18:48] I I know I know this is a contrived use case, right? I I I know that's quite obvious, but what I'm trying to get out here is writing a detection does understand does require
[19:00] utilization of this kind of nuance. So we ran another thing where instead of walking through this process, I basically said I took the the
[19:12] best model I could. But I told it to think for a while, but I told it not to ask me. Go write a detection to capture internal movement. And you'll notice what it spits out is incredibly generic, right? Like go find stuff where somebody I think there's a filter
[19:25] in here, but the zoom isn't good enough. Go find stuff where somebody puts greater than or equal to 10 files on a removable drive in a day. Okay, like it's reasonable. There's something going on there. But in this data set, there is
[19:39] an in so it's a synthetic data set used for such use cases. There are 30 malicious events in here where somebody was excfiltrating data. This detection would have caught one of those at the cost of generating 16,000 alerts, which
[19:54] is not super nice and super useful. So again, I know the point I'm really trying to make is um models when left to themselves will generate median quality or very generic kinds of outputs. And we don't think I don't think we get much
[20:06] value out of that which is why it's important to insert the human in the loop to understand what they have, how the pieces tie together and such so they can make something more useful that that works for their use case. So that's what's going on here. Um I will pass it
[20:18] over to Chonga and let her talk about what this looks like today. >> Awesome. Thanks Charlie that was an awesome uh demo. Okay so I want to take us back to
[20:31] the existing problem in the industry um right and the existing problem is that and again this is all from like IBM reports and crowd strike uh threat intel report uh data sources. So on an average
[20:44] to go through a breach uh detection life cycle it can take over like 200 days right but attackers are moving in minutes again recently when um in one of the crowd strike threat intel report it
[20:57] said that attackers can move from one system to another in under an hour or as fast as 2 minutes right and then even 79% of those attacks are malware free which means that they can have valid
[21:09] credentials for traditional EDR systems it can be really really hard to detect uh and then also of the about like 62% of them uh bypass like MFA uh and things like that right so what that really
[21:22] means is attackers can move really quickly but we don't have systems and tools in place that's able to detect um as fast as the attackers are moving right so that's the existing problem we have so over the years we've been able
[21:35] to like make progress in how we've been able to solve it I see a lot of my customers here Justin I know you just like walked in uh but I remember two years ago, I'm gonna I'm gonna just talk because Justin, I saw Justin. I'm going to talk about uh one of the problems we
[21:49] were trying to solve. He's one of my customer. I'm not going to take the customer's name, but we were really working on this problem two years ago at this point on an agent sock. And at that time, data bricks just had vector search
[22:01] and it was really really hard for us to solve that problem. And we like went and explored so many different solutions and we were able to solve it like you know decently well. But it just makes me happy that we've come a long way, right?
[22:14] And going back to last year, like everything that Riley just uh walked through in that custom lang graph framework uh to now we have a new product that we just released, right? And so that's what I'm going to talk
[22:26] about. >> Oh, right there. >> I'm going to use this one. Yeah, I forgot about that. Okay, so just going back to it, you know, uh Riley walked us through how we went about building it with uh another customer, right? So it's
[22:40] a combination of building the tools that our engineers use in the formats uh that's expected orchestrating into like a langraph framework deploying that agent in data bricks. Um so all of this
[22:55] putting together it does require some level of like a IML expertise and >> some amount of work to put it all together like it works really really well. We have several customers that have put together the solution and gone to production. But now um we're able to
[23:10] do that a lot faster, right? Like the build process has gotten a lot faster. How many of y'all um attended the keynote and saw the lakewatch announcement? Okay, awesome. Yeah. So I don't have to introduce Lakewatch here.
[23:23] So yeah, so that's the other part of the solution, right? So, we've come a long way and now with the Lakewatch product, even though the product is super super early, but it's going to make the building process faster, it's going to make the detection um that whole life
[23:37] cycle of detection a lot faster, right? Um and so the biggest piece is again we have Geniode assistant natively available. So, whatever work you've put into building these systems in place, now you can just like migrate that over
[23:50] to Genieode and build those workflows in an accelerated way. Um so yeah so like Riley Riley showed again you know building those tools like
[24:02] thousands of lines of code right now you have to sort of think about how you can translate that into skills and a few markdown files right and all of that again Genie code can help you plug in and again in the demo I'm going to go
[24:14] through that and show you how we've taken the work that has already been done and how that can be done in lakewatch going forward. So yeah with that I just want to like level set everyone what is lakewatch right it's our it's datari bricks open agentex sim
[24:26] uh solution and mainly just wanted to talk about in three pillars the first one is open right so it's built on your data on open standard so you can bring in any type of data sources the first
[24:38] thing uh and you can bring it in lakehouse and um for example if you bring in like data sources like crowdstrike and things like that we already have data presets available to be able to uh go through the process of
[24:51] building going from like bronze, silver, gold uh ready to be consumed downstream applications, right? So again everything that exists in data bricks in terms of all the data engineering best practices lakeflow connect autoloader all the same
[25:05] principles you will be using within lakewatch to be able to like build that data engineering uh workflow. The second piece is that human in the loop, right? And again, I just want to ask like how many of youall think agentic sock needs
[25:17] to be fully autonomous. Okay, that's great. That's what I wanted to hear. So, yeah, human in the loop is obviously a very essential element and we've been talking about it from the beginning, right? So, lakewatch is again
[25:30] built in a way that every step of the way you're getting that human in the loop element, right? So as as soon as you bring in data, not only can you do on demand analysis, but every every step that it's taking you through, uh you're
[25:43] going to have, you know, you can go back and forth with the agent to correct the workflow to to tell it what it needs to do and build your workflow accordingly. So that's where the second pillar is, which is in every step of the way that agentic element is built in. Um so
[25:56] that's in your data engineering workflows, in your downstream applications, if you want to do investigation. Now a lot of it you can like automate it right but then you want to be able to catch the false positive
[26:08] and the the most important pieces. So you need to build the workflows in a way that when the agents are not sure it needs to give the control back to the human to be able to take that decision right so how do you do that again with
[26:20] all the guardrails like within the platform we've thoughtfully done that and yeah the third piece is built to scale this is again lakewatch is just built on top of uh data bricks so a lot of our customers have been able to like
[26:33] u bring pabyte scales of data and have seen like huge um TCO cost savings Okay, just just going to touch a little bit more on some of our customers, early adopters who've who've used Lakewatch,
[26:47] uh what they've been able to um um see in terms of gains, right? So, our customers have reported that they've seen 60 to 80% uh TCO cost savings. Adobe is running about 21 pabytes of data. And again, all these are publicly
[27:00] referenceable. So, uh that's why I've put it out here. And then Rivian and Standard Charted have again like reported somewhere between like 60 to 70% of uh cost savings.
[27:12] And one thing to keep in mind here is again that once you bring in your data, you're only paying for things that you're running. Um right now we don't charge if you're just like storing your data or any of that, right? So that's
[27:24] the huge benefit when you compare it with traditional SIMs. Okay, this is the last slide and then I'll jump on uh to my part of the demo. So
[27:36] again I don't want to go into too much of the detail but just wanted to emphasize on the fact that lakewatch is just built on top of data data bricks platform data intelligence platform right which means that uh you bring in any of like your cyber security related
[27:50] data sources under the hood it is going to use the same autoloader lakeflow connect all of the data engineering best practices to go from bronze silver gold and then lakewatch again every step of
[28:02] the way you have that agents built in to be able to do your investigation and detection downstream application. So yeah um so it's essentially built with our agent bricks um genie all the all the products that we have like it's just
[28:15] a product that sits on top of our platform. Okay, with that I'll go to my part of the demo. >> While they're doing that, um, >> and then >> one of the things she was touching on was the original application had
[28:27] thousands of lines of langraph code for the orchestration for the tool definitions on a lot of those. I don't know if you ever seen talks from like AI engineering conferences like I had 10,000 lines of code and I turned it into a skill or two skills. Markdown
[28:39] files are a lot easier to write than custom langraph tools. So one of the things lang lakewatch does is allows us to since we can trust the running of the SQL little on a little bit more ad hoc basis in lakewatch instead of having to
[28:52] parse out specific you know more structured tools that run SQL we can bring a skill to give instructions to kind of enforce some of these same ways of working in the lakewatch. So um after the demo there will be another slide with the QR code. We've actually open
[29:05] sourced the skill. So if you want to take it and take it for a spin on Lakewatch you can be able to do that. >> Yeah. So, um, so basically everything that we saw, uh, what Riley showed us,
[29:17] right? And Riley just gave me the repo and you know, someone helped you out in building that repo. I know you. >> Yeah. Yeah. Harrison on our team, Harrison Schuman wrote the skill for us. >> So I what I did is again when I started out my part of the presentation, I
[29:30] mentioned about how you can whatever you've built, you can take the things that you've built and migrate it over to Lakewatch, right? And so I just wanted to, you know, showcase that. So this is the repo and if you see there is uh you
[29:42] know we have some skills and we have some markdown files that exactly has the definitions of how we want to be able to do certain certain things right like our engineers are used to doing. So the first thing you know when we see the
[29:55] platform this is how lakewatch looks and again a lot of you might have already seen um in the keynote yesterday. So this is lakewatch here. Uh this is the overview page and then when you see Genie code here um you can see you can
[30:09] just like interact with it in natural language and be able to like start um uh working through it right and so the repo that I showed you you can just come to settings here and then you can plug in the skills. And so now I have the same
[30:23] repo that I've plugged into lakewatch into Genieode. So now it has that context right that we've already worked on building. So the first thing I'm going to do is I'm going to reference that.
[30:44] direction. Oh, I have a little bit of a height difference going on here. Then my cursor. Where is that?
[31:02] Okay, I'm just going to say what skills do I have access to? So yeah, this is the agentic piece of it, right? So I'm just right now asking
[31:14] so it's able to like uh look at the skills and it's able to give me just the definition of what skills I have access to and all the different um markdown files and the definitions of that. Right. Okay. From here, I want to start
[31:28] doing some prompts. So, where did my cursor go? Okay, I have a prompt. I'm just going to run that.
[31:41] Okay. So, I'm going to again reference detection engineering and then I'm going to run this see prompt. Okay. So, I'm just saying use the temporal baseline skills.
[31:53] So, one of the skills that Riley passed me and I'm asking you to do a few different steps, right? I'm asking you to you uh do detect successful signins from a country an account has never used before and then I'm exactly pointing it
[32:07] to like what table it should be using in lakehouse and then do some transformations, use an a certain window uh and yeah, a lot more specifications I'm giving. Right. So now you can see
[32:20] um it has okay it's still working on it. So let me go here. Always allow. Okay.
[32:48] okay. So if I increase um if I just read through this. So basically it's doing that chain of thought uh uh prompt reasoning right. So you can see all the exact steps here. And if I uh show the steps over here uh it had already created that query. So it was able to
[33:02] point to the exact query and then it says okay I'm navigating to the query page. No hopefully this runs. Okay. All the demo issues. Um but yeah it's
[33:14] able to like exactly go to the uh query and it's explaining what the query does and um so I already had run the query so it was able to just like pick from the memory and point it to the exact table and it also populates it right so this
[33:28] is where all the agentic pieces are happening not only it's using the scale it's able to read that table it's able to create the query and it's also able to populate the query in the query editor okay I'm just going to keep
[33:40] canceling this for now Hopefully it doesn't get mad. And then I'm going to accept it. And um this is the query page. And it it's going to go and start it's it's going to go and now run the
[33:53] query. So while it's running I can actually show you the one that I had previously ran. Right? So basically this is the
[34:05] query and once it runs this is where it's using uh the serverless compute over here and it gives all the um um results right I know what's going on.
[34:18] Okay from here I am going to go ahead and run uh the other query too. So okay I I like the results and now I want to go create a detection rule and I also want to create a security case. So
[34:30] that's what uh the lakewatch is built interactively, right? So I So you can see you have over here. I'm going to go back to the lake watch.
[34:47] Okay. So you have the detection rules, security cases, system cases, all of those pieces existing here.
[35:17] So what's this going to do is again I had pre-errun this uh query. So what's this going to do is the results that got populated. It's also going to help me create a detection rule and a security case on top of that. So that's what it's doing over here, right? So it says the
[35:30] user wants to create a detection rule and for the detection rule, the skill says to navigate to this. So it's using the skills, the context that I gave it to be able to create that detection rule. Uh I'm going to just show you the
[35:42] one that it had already created. So if you see this is the one I just basically created uh using Genie code. And so if you look at this, the genie code autopop populated um this detection
[35:56] rule with the name, the comment um all of the query and from here like you have it in the UI form, you have it in the YAML form, you can use it in your CI/CD workflows and you can even automate it and have it run in a scheduled manner
[36:09] right so um so yeah all of this again natively available through the platform outside of that it also is able to create a security case right so this is again something that I had already run uh through Genieode and in the security
[36:23] case again Genieode was able to autopop populate this right and as a human you can go review it like and see all the information looks good right and then from here you can even go change if you
[36:36] want to change the severity or want it you know like change the status to in progress and assign it to someone else uh to pass it on. So all of those are the added functionalities uh that we're
[36:48] bringing in lakewatch outside of the tools that are existing right okay so that's okay those are the pieces that I wanted to showcase and outside of that another part that I wanted to mention is
[37:01] the um the other pieces that are cool so within lakewatch out of the box if you aren't able to build all your workflows now you have access to even all of the data bricks related tools Right. So you
[37:15] if you go back to just um so I for example I can go to lakehouse and I have some agents that I had created even over here right which has access to few
[37:28] different things. So this is like a custom agent bricks that I had built with um some gold tables and a genie space and a knowledge assistant. You can even tie the pieces that you're working through in lakewatch with some of the
[37:41] agents maybe that you have already built in in lake lakehouse 2. So yeah, so with that I wanted to just like you know conclude by saying that I know there was a little bit of a glitchy demo but um
[37:53] but yeah like the essential pieces are that like within the platform you are able to like you know using Genie code able to like run your data engineering workflows do the agentic pieces and create a detection rule create security
[38:06] cases and then also can plug in with um some of the pieces that you've already built in lakehouse and tie it together. >> Awesome. Awesome. Thanks. Let me just go back to that other slide. I promised to >> Oh, yeah. >> Yeah.
[38:18] The fun stuff. If you want to go ahead and take this skill for a spin. >> Oh, we're mirrored. This is good. >> Yeah. Yeah. Make it big. There we go. So, we took that skill. We popped it in there.
[38:30] You can pop that into your dot assistant folder in Genie and and let it rip. So, one just as a builder of AI agents, one of the things I loved was Markdown's heck of a lot easier than um lang graph code. That's super cool. Two, even in the chat workflows, right? It'll take
[38:43] you if you work through like the original demo that I did through my agent. And if you do that, it'll take you to like, do you want to turn this into a detection? You hit accept and it brings you to that page, which is awesome. So >> yeah. >> Anyway, that was our talk. Hopefully it was helpful. Thanks all for coming.
[38:56] Yeah.

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.