EP252 The Agentic SOC Reality: Governing AI Agents, Data Fidelity, and Measuring Success

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the Senior PM for, well, all kinds of stuff in Google SecOps, and of course, Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. You know, listeners, I've said that URL 250 times, still sounds like a mouthful to me. I don't know how any of you remember it to type it in. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, this episode started from a conversation a karaoke booth in Singapore. What?

I did not know that backstory. Well, of course, I wasn't at the event in Singapore. Unfortunately, I missed it. But I did not know that because the guest is from Europe.

No, he is. Both of our guests today, listeners, are from quite an old, well-established company in Europe talking about how they're using GenAI in Google SecOps to accomplish some really hard problems. But this was born at an OCISO event in Singapore over the summer.

I mean, you made it sound like it's a customer case study, but ultimately, you would notice that even though it occasionally has a customer case study vibe, it is also really fun. And it brings up some incredibly useful bits you can use while adopting AI for security operations tasks and also other security tasks, actually. And by the way, one thing that impressed me the most, I'm just going to go with this amazing highlight from—

Oh, go on.

Yeah, for me, it was the— you occasionally hear some sort of a Bay Area startup, large-ish Bay Area company adopting AI, and everybody's impressed. But this is a very old-world company that is really, really impressive with using AI for security, despite regulation, despite maybe culture in the region, despite other things, but they're just really good.

Yeah.

In that context, which to me is, is quite amazing. That to me was a shocker. That to me was the mind-blown moment.

Well, it's good that Alex and Lars are so good in this context, because I have to say, listeners, Alex is not so good in the context of singing karaoke. So maybe with that jab at my good friend Alex, let's turn things over to today's guests. Today we are joined by Lars and Alex. Lars is our global head of detection and response at Allianz, and Alex is a deputy group CISO at Allianz. I think a deputy group CISO might be a new title for us. We've had CISOs and BISOs, but a deputy group CISO might be new for us. So Alex, you're one of our closest partners. We love working with you on the, on the SecOps team. And this is one of those funny episodes, listeners, where I will wear both my SecOps PM hat and my podcast host hat. You've been with us on this journey from traditional SIEM to agentic outcome-oriented SOC. How did that go? for you? And especially, how did that go at something as heavily regulated as a German insurance company no doubt is?

Well, let's first of all say I think it hasn't gone, it's still going, right? So it's a continuous journey. Okay, we're on that journey towards agentic SOC. One of the key questions that I keep asking myself and asking the team is, what does done look like in agentic SOC, right? So if you, you know, ask the Gartner analyst of these days, Maybe Anton can shed some light on that, but the definition on that is still a bit fluid or flexible. If you go to RSA, I think you've got 200 vendors selling you 300 different versions. So for us, we adopted the CrowdStrike view of this, and George Kurtz came up with this analogy of using kind of the autonomous vehicle comparison, where a VW Bug is your level 0 and your Knight Rider kit is your level 5 or level 10. Level 5 it is. So an agentic SOC, I guess, you know, level 0 is everyone doing everything manually, and level 5 is you sitting down with your newspaper and just reading your newspaper while this autonomous SOC handles everything. At least in our view, I think we're somewhere near level 2 or potentially moving into level 3. So we're on that journey. We're not done with it yet.

And so how has that been working with the Google team and going on that journey?

It's been amazing, right? So as you said before, we look at Google as one of our strategic security partners. So we work very closely with the teams. And that has 2 sides to that, right? So one is, we want to build trust in our teams on what Google builds, right? So we're involved in a lot of the, or some of the product development, especially on the Agentic Triage agents, some of the Agentic Malware agents, and all those things that are coming for SecOps soon. But on the other hand, it's also, at least I hope it is, a benefit for Google to work with us because we have a global visibility of, A, what threats look like, B, what a corporate SOC that's a reasonable size can do. And thirdly, also, you mentioned regulators before, we're quite heavily regulated, right? So around the world, I think I tried to count, we have over 100 regulators that all have different fund requirements. We then on top of that—

Only?

It's probably around 100. Yeah. So it's 72 countries, and then we've got 52 in the US on top of that. So that probably makes it closer to 120. But I mean, some of them are aligned, some of them are not. And then we have our own internal legal and governance requirements in the company that come on top of that. But I mean, if you buy into the agentic SOC vision, going through all those hoops is actually worth it. Because in the Your agentic SOC is going to be the only way you can defend against agentic attackers.

I think on the second point that Alex said, one of the really cool things is Allianz obviously has a really big environment that's super diverse. And a lot of the Google ways of how building it, working together with them really helps on trying out these agentic capabilities on a diverse data set that we have. Because I think that's kind of important for it to work, and especially for the trust aspect that Alex already mentioned, to really make sure we try it out. And being closer with the Google team really helps here. Because we get early access and we can give feedback super quickly.

With those different environments, are you having to explain this to different regulators? Are you getting multiple bites at trying to explain this to people? How's that going?

So different regulators have different views on things, obviously.

Obviously.

So yes, we do have to explain this time and time again. Luckily, or maybe not luckily, I don't know, I probably shouldn't put this on a podcast, but the regulators haven't dug that deep into Agentic SOC yet. They're currently still, at least for what we see, most worried about actually being able to detect and respond in time. And if you look at some of the European regulation especially, there's a lot of regulation on how quickly you have to respond, detect, and all those things. And Agentic helps with that journey, right? There are, however, also other things like the EU AI Act that still requires you to put certain safeguards around all your AI journeys, right? So for us, I think our motto at the moment is AI is our copilot, not on autopilot. So there's still a human in the loop for anything that's destructive or that has a chance to affect or have a severe effect on the organization.

But it basically takes a lot of the tedious work and tasks that analysts used to do before, and it does it more flexible than a deterministic workflow. Because deterministic workflows are, the second one thing changes, we have an issue with it or it doesn't work, it fails, human needs to look at it. And the agentic part is just far more flexible. So as Alex said, Copilot, take care of, you know, prepare everything, give the briefing to the pilot, and then take it from there.

But a lot of this is like really common sense. I mean, yeah, I know if you go to the crazy land of RSA and there would be a vendor who says that we can remediate, you know, 77% of alerts automatically without humans just putting the cup of coffee down. I mean, we all know it's a lie. Like, and probably they even know it's a lie. So, everybody kind of knows it's a lie, but everybody, many people keep repeating that message that, oh, yeah, yeah, yeah, we're going to be on a journey to full auto in a year. But what you're describing is, of course, is absolutely logical and coherent, and it makes sense. So, I'm not— I mean, it's probably a very pointless point I'm making, but it is logical whether you regulate it.

Listeners, Anton called our guests logical and said they make sense. This is a high compliment, Lars and Alex. I don't know if you know that, but this is—

No, no. We are honored, Anton. We're honored.

I mean, I really—

Well, not to say I didn't mean it. I did mean it. But it's the actual interesting point is coming. Sorry. That use of AI for SOC, AI agents for SOC applies to a startup in the area and the regulated company in Germany. Like, it's common sense. It's actually the commonness of it is the point. That it is what you're describing is how it's done today, how it should be done in a year, probably 2 years. Don't know beyond that. But This is the— if the audience is hearing this and say, no, no, no, they're too safe. No, they're not too safe. That's actually where you should be. It's not being too safe. It's being good.

It really depends on the risk appetite of your organization in the end, right? So as a heavily regulated global financial player, obviously, and a company that as an insurance company is good at risk management, I would hope we do have certain— we do know the amount of risk we want to take on board. And that's why we chose that approach, right? So it might be different if you're a 2-person company that just as an agentic SOC because that's all you have.

I want to ask specifically about governance, even though you kind of explained de facto governance. And while the question will apply, of course, to agents used for security, but maybe you can spill over a little bit and talk about the governance for agents, AI agents in general, because this is— and how it applies to SOC, of course. So this is kind of the, how do you govern triage agents? How do you govern agents?

Yeah, and that's a very good point, right? So as I mentioned before, because we are under quite a bit of regulation, we have strong governance around that. So we review the model— well, we don't review the models themselves, but we review the use cases. There is what we have internally is an AI board that actually looks at whether that's legal and safe in a way to do. So there's multiple functions involved: data privacy, AI team, data team, security team. So we have all those safeguards. And then once it's gone through that, we put them into production with the appropriate safeguards around them. The other thing for agents is that a lot of people think— I think the joke in the industry is, like, the S in MCP stands for security, right?

Yes.

So everyone assumes you just put it out there, and it works. Managing access and security of these agent-to-agent communications is a challenge. So we've talked to some other companies that have actually started giving agents employee IDs. Which, at first, it sounds like a very strange idea. But the more you think about it is, well, it's an employee that does things, right? It has certain access rights. It shouldn't have certain access rights. It needs to be monitored. It needs to be managed. And that's how we think about it, right? So what's the identity and access management stuff that we need to put around these cool, modern AI agents to actually be able to operate them safely?

Hmm.

So the employee ID may send me down in a very interesting path because I've had a few conversations with clients about governing agents. in applying IAM. And I've noticed there are actually kind of 2 camps. There's one camp that thinks agents is an employee, and they should be treated as you described in some regards and governed as you would an employee. So, like inside of threat risks and all that. And there's also a camp that thinks agents are workloads. And there's absolutely almost nothing new. They're just less deterministic workloads. But then these camps believe that they are the only source of truth. And the other one cannot possibly believe that, which is what struck me as interesting. It's not that there are 2 positions, but that each believes that they have the common sense and the other cannot possibly think that.

I mean, as an ex-consultant, I have to say the answer is yes.

Yes, yes, well, both. There's a little tiny camp that says both but can't explain what it means.

Well, it means both things, right? So, A, the agent, when it does stuff, it behaves like an agent, right? It does things semi-autonomously. At the same time, it's also a workload, right? So, I think what a lot of people forget to look at for AI You still need to secure the infrastructure. You need to secure the code on top. You need to do all the things you do for a workload. And then, at least in my view, something on top.

Yeah, and I fully agree. I think a workload is a little bit more, at least for me, a deterministic part of it. So I see the agent more like a capability, like an agent that works on the workload and then basically goes from there. So I would actually be the little camp in between that says, well, I think it is both. So in general, I would go more for the— it's a user, like it's an employee, because that already has a lot of existing guardrails around it that we could just recycle for this.

Yes, that actually— I like that.

I'm getting very, like, superposition vibes from this discussion, and I thought we were done with quantum episodes for the year. So I want to move us along and ask a slightly different question around how did you, day to day, when you're actually building this stuff out, draw the line between what the agent could do versus what the human had to be in the loop for? Because The agent's useless if it can't do anything, and it's also terrifying if it can do everything. So how did you help your team draw that line?

Yeah, super good question. So I touched on it before a bit, right? So right now, the agent is useful even if it cannot execute things, right? So looking at the agent, we look at it as pretty much the same as a lower-tier analyst, right? So it has the same, well, similar skills, but it also has the same restrictions. So an L1 analyst wouldn't be able to isolate half the company, hopefully, if you set it up right. And for the agent, we take a very similar approach, right? So let it figure out what it can do. If it's a single machine, we can discuss whether it can isolate that. It shouldn't be able to do more than X. At the same time, just like a lower-level analyst, if it doesn't know what to do, it should actually put a human in the loop, right? Or the next-level analyst in the loop.

Right.

That being said, and Lars touched on this before a bit, to us, actually using AI is the second step, right?

Sure.

So we start with deterministic automation where we can, right? So if there's a phishing mail reported, that's a very deterministic flow, right? It's phishing, it'll get blocked, we pull it from everyone else's mailbox, et cetera, et cetera. AI, or the AI triage agent especially, or even the AI malware analysis agent, right, that comes in when the deterministic automation Doesn't have an answer, right?

And that's pretty much exactly how our playbooks are built. We try to get to a pretty high percentage of everything being done fully deterministic because that's great to auditors, that's great to all of that fun part. And then the second, the determination is not too sure. So the different phases of an incident in our playbooks, we always ask a question at the end. Do we know if this is true positive or false positive? Do we know which systems are involved, which users are involved? And if we are really sure, because the deterministic playbook did everything fine, it just continues as it is. If it's not too sure, we can then continue to the other tiers. And that's where I see this all going, is it then goes to the AI tier basically. And then eventually, if that isn't sure, it goes to the human tier. And I think that way we can scale greatly because obviously these models need crazy amount of compute anyway. And we can do a lot of deterministic parts that we also wanna do. The other really big part, and I think this is where the legal part always comes in, the second we involve investigations against another employee. So another human in that sense, we always have to take another human in the loop anyway. That's just from legal regulations as well as like internal regulations, which I think is also a good idea in this sense.

I like that. And I think that the deterministic priority of deterministic is an interesting and a very good point. Like if the use case calls for deterministic automation, you should use deterministic automation. Again, it is not something I've seen people do because people say, And again, sorry to detour to SIEM and YUBA wars back in 2010 when people said, oh, we're going to use ML. And I said, but you're matching to threat intel lists. Why do you want to use ML? Oh, we extrapolate ML and build these things. No, you should just match against the list. And the list is the genuine bad list you want to match. Why are you doing this strange thing on the side? So, to me, the same ghost came here to haunt us is that people over AI in some areas where the deterministic answer is the right answer.

Agree.

Yeah.

So, lately, I had an obsession, and my obsession was kind of like, is SOC ready for AI? And the point about data quality comes up quite a bit. Data availability, data quality. People have been making agents to scrape logs through terminal windows from mainframes. That's a real example. I mentioned it in my blog, and I thought it's idiotic, but it actually happened. So, that's why it's bizarre, but it happened. So the data quality and availability and fidelity is kind of a challenge for this. So from your perspective, how was it solved? How are you solving it? Like, I don't know, like, I don't wanna presume you solved it, but how are you solving it?

Exactly, fully agree. So I think that's one of the big parts that we looked into really early on that we know it's GIGO, it's garbage in, garbage out. So you really need to make sure that everything you get in works. And for us, a big part comes down to understanding the data flows. So where does data come from? How do we parse it? How do we change it? And where do we store it? And how long do we store it in our central SIEM to really make sure we know what the fields mean? Surprisingly enough, if you actually get something in your SIEM, that log already usually gets parsed multiple times before it ends there. So are you sure this source IP is actually the source IP and it's not called something else in there? So that's super, super, super important. And then the other part is we really need to understand We have to give the models capabilities to understand what data we have and what we don't have, because that's one of the things where the human analyst back in the day is really good. Like, they've done a lot of these investigations and they saw, well, you know, if I search for this, I don't get a result, then I know this log doesn't exist. Well, how does the AI agent know that? And especially if we look at the, you know, and I like the reference that you made in one of your earlier podcasts that an AI agent is like a human with a really small window. So it only sees the world from a really, really small part of it. And I think that's exactly how we see it as well. And it only knows this case at the moment. It doesn't know how the cases before looked. Maybe we can give him that information. But eventually, context windows get too small for this. So for us, it's super important to give the models all the knowledge that our humans have, like the business knowledge, the context knowledge, and so on. I think that's where we are working a lot, also with the Google team, to be able to give them that information. I think one really interesting part of this is, for example, if you use a top-level domain internally that is also used externally, then the agent will think somebody— you access something on the internet, or you don't. And the equivalent with IP addresses, ranges, hostnames, all that.

Sorry, I had to shudder briefly because I had it happen many years ago when I was a very bad PM at a SIEM vendor.

Oh, no.

And it was the IP addresses, internal use of external IPs.

Yep.

Instead of RFC 1918s and also domains. That was just like a horrifying nightmare for the product developer, right? That you have the same number, same string may appear, and they mean absolutely 2 different things.

Exactly. And you know what the interesting thing is? If you have an analyst in your SOC, the analyst knows that because the analyst shadowed the other analyst before and eventually from experience got that. Well, we aren't there yet. We can't let our LLMs at the moment actively shadow and learn stuff. That's at least not where it is yet at the moment. It might get there eventually to learn all of that business context. And then on the data thing, there's one more thing that we're looking into that we think are super interesting. With the ability that we have these agents, we basically built a time machine. Like, we can do so much more analysis in such smaller timeframe before, which basically will end up— and we can do the analysis much, much more detailed than before. And if we think of our analysts doing normal analysis, they use— or like in-depth analysis, they need a lot of data. They eventually pull data from other systems and so on. So I'm pretty convinced. we will not have enough data available in our SIEMs to have all of our agentic power actually run and do all that it needs to do. And from our view, the next generation of this is that the agents have the ability to actually pull data from systems.

Mm-hmm.

So you don't only let them query stuff, but you then eventually actively let them pull stuff from the system the same way a real analyst would do. And I can see the industry already going there. We have multiple things where we're trying out. And that's super, super neat. Because that will then eventually move us from what we see at the moment, from more triage stage to actual investigation stage, where the analyst actually moves and pulls stuff further. And I'm super excited about this because that's where we get closer to what I think the agentic SOC actually is.

That strikes me as, like, the audience better take notes because this is, like, super useful. And you've went through that journey, and I feel like people who are now plopped some kind of agentic AI product on their SIEM and pushed the button, cranked the handle, and then suddenly, it kind of blew up because of data quality and that was— they were kind of upset. I'm sorry, Tim, your question.

No, no, no, no, it's a good discussion. I've got all day to ask questions, Anton. I wanted to touch on how do you know if this is working and what are you tracking and what's getting better so far and what do you expect to get better in the future? Because, you know, Anton— well, we'll get to Anton's question after this, but let's start with that. How do you know if this is working and what are you tracking?

I think one step before that is what you actually want to achieve with SOC automation and using AI in the SOC, right? So if we take one step back—

Oh, is that not obvious?

Well, it depends, right? So it could be saving cost. It could be better outcomes, right? But then better depends on what you want to do, right? And I think that's super important to understand that the metrics you measure are the ones you're going to optimize for. I mean, that's true in any case, but especially in this case, it's an important one, right?

Yes.

And for us, it was really— I always call it turbocharging the SOC. Sorry, lots of car references. You're talking to the Germans, right? But that's what we're going to do. So I want the SOC to be better and faster. The other thing, and we were discussing this before, we both sail a lot. And in sailing, if you go across the ocean, you end up having radios. And one thing you have on the radio is what's called a squelch button. It's the thing that does kind of the noise suppression. The beautiful thing, once you have AI agents in your SOC and they work, you can actually play with that squelch or volume button to make it easier. So we can turn up the noise in the system and just let AI filter out what's actually needed.

Right.

Anything that we would now automatically consider a false positive because there's low fidelity, if we give that to an AI agent, that can actually do some more triage on it and verify whether it's actually a false positive or not. And that's something that I'm excited about. But back to measuring, and that's Lars's domain because he's been doing that for a while.

Absolutely. So we basically recycled stuff that we had before from the normal automation part. And I think one of my favorite ones is the amount of time we save by automation, and eventually also the AI agent with it, is in a quarter, we save about 68 years of time of our analysts every single quarter just by using this.

That's amazing.

And that's super cool because the SOC itself can actually do cool things, like other things than clicking things or querying databases, doing stuff, because we save that time, continue to do other items. The other thing is to convince our team and also our management of how much do we trust this agent? And I think that's like the one big, big question is, and talking to the team itself, the whole triage agent was built by running the same the same request, the same incidents beside the agent and a Mandiant analyst. And like, yes, my team might not be a Mandiant analyst, but we basically did the same thing. We just let the agents run parallel to our normal analysts, our normal cases, and then at the end did some statistics on how often do they disagree.

Hmm.

How often do they agree? How often do they disagree? And then on the ones that we disagree, we let a more senior person look over it and make sure that that happens. And like, from the statistics that we look at, We are at the moment at the level of what our analysts are, if not in some cases beyond, especially on the false negative rate, where the Agentic AI spotted something that the analyst said, ah, this is likely false positive, and did more analysis in it. So ran more queries, got more data, because that's usually the time effort of the normal analyst. They don't do it because they're like, ah, it's going to be false positive, right? And it actually turned out not being false positive. So that shows us the confidence that is actually really neat. And it still runs in parallel to all of our cases at the moment.

I'm very curious, if you're measuring the agreement rate between the agent and the analysts, are you also from time to time measuring the agreement rate between Tier 1 analysts looking at the same data?

We're not yet. I like the idea. What we do is spot checks on quality. So we have to obviously guarantee that the quality works. And we have people that are Level 2, Level 3, like higher-tier analysts that randomly take cases and go through them and make sure, like, is the case actually handled the same quality as we want to handle it? And that's one of the things we want to use also with the Agentic agents. That the agentic agents run it and basically don't treat the agentic case different to a case that a human handled. And let randomly pick the cases, let a senior tier analyst look through them and say, this worked, this didn't work, or this was right, this was wrong, and then fix it from there. And that way we can measure agentic versus human quite nicely.

And so is it better? Is the machine— I mean, it's all probably like a question that's been bubbling up in my head is that, are things getting better?

I think it's getting better. I actually think things are getting better on our side. One of the great examples for this is actually the malware analysis agent that you guys have. Like, having people that can reverse engineer malware, that takes time, and you need the people.

Yeah.

And we get a lot of phishing, a lot of malware delivered. Now, using that agent, every analyst can basically just dump everything into the agent, and the agent does the analysis from it. And like, one of my favorite examples with this is a lot of the malwares have multiple C2 channels. They try to reach out, and if you detonate it in the sandbox, you usually only get the first because the sandbox basically checks what network connectivity the thing actually does in dynamic analysis. Well, turns out the analysis agent dumps the file and figures out all five six C2s, and it's really surprising if you compare that with the TI knowledge we we see. Usually the first is already blocked early on, but even like proper TI feeds out there take longer to get the second, third, and fourth because they don't all do that, and that gives us an advantage because we can start blocking. that C2 channel going out and preventing people from infecting or downloading the second stage just by using that. And that would not be possible human-wise. Like, I could have a whole fleet of people doing malware analysis, while now I just plugged it into the analysis agent, and the result comes out of it.

Yeah.

Back to the volume of squelch button, right? So we can now do stuff at scale that before wasn't feasible just from a cost or even finding people that can do it perspective.

Right.

I think malware analysis is a great example because it's a low cost of an error. high cost of human labor. My ex-analyst brain is thinking of some framework we should build for use case judgment. And I think the malware analysis is a very obvious fit for that because even if the agent is just completely wrong, probably humans will just redo the labor and there's nothing horrible would happen. But if the same agent gives you IAM recommendations and automatically implements them, you are shooting a pretty massive torpedo in your business, right? Or something like it can be Clearly harmful. But the malware agent analysis mistakes, kind of like, okay, whatever.

Well, and the cool thing is, especially with, like, if you look at IoCs, before blocking an IoC, we have guardrails in place. So we check, you know, is this a business? You know, are we going to block google.com or not? And that is really, really neat. So, you know, even if the analysis makes a mistake, it really doesn't— like, it will get caught in a different layer before it makes business impact. So exactly, Anton, as you said, it's a huge advantage for something that doesn't really cost us much. So I'm really, really happy about that.

I just want to go back like 5 minutes to a particular word you used. You used the word squelch, and I have a squelch knob in my airplane for exactly the same thing as you have on your sailboat. I used that word not too long ago in a PRD internally, and somebody said I would get bonus points if I got that word into the product. But today I've gotten it into the podcast. So Spencer, we are squelching a lot of noise in our product.

And I actually think it's a really good example of showing that you can really noise stuff up. I think one, one really cool example with this this, looking for having user accounts or service accounts, NPIs, whatever you want to call them, and checking with them if they log into a new system. That itself is probably not malicious, but how cool would it be that every single login you have an agentic agent actually look at it and says, do we expect this? Do we have anything else malicious around it? Do I run some queries? And then eventually even theoretically interact with the owner of the NPI, so owner of the service account, like, do you expect this? Yes, no, maybe, and write some explanation back and forth. That's stuff that takes a lot of time for an analyst to do. But basically, like, the value is also huge for us if we start detecting, for example, red teams that abuse these APIs with this. So turning up the squelch.

I mean, this— I still want to briefly have a more formal answer about, like, are things getting better? Because if you have the adoption journey to some of this tech, malware agents is a great example. And I think that beautiful examples like mail-order agent where the value is obvious, the risk is low, the advantages are dramatic. And it's just like, to me, they overshadow the rigorous measuring process. And I know it's kind of a good thing happened to you, value is obvious, great. But for triage agents, are you doing the measurement of human labor savings? How do you measure quality? Like the easy examples, like an elephant in the room and it's like, yeah, it's beautiful, it's magical, rainbow colored, it's great. But what about the other stuff, like triage agent? How do you measure the value that it's working?

So for the triage agent, we also— so we measure the amount of time that is saved from it. That goes into the, whatever, 68 years every quarter. It's not only that. It's also automation part of that. But that's a combination of it, which is really neat because we turn up the squelch button, and we get far more alerts. And now suddenly, we don't have to look at every single one of them because we just check, you know, how confident is the agent that this is actually malicious or not, and then continue from there.

There obviously is also another advantage to this, right? So if we look at, I think the term used to be bore out, right? So a lot of L1 analysts looking at, I don't know, the 10th failed login by Alex because he can't type the password, that just pushes them over the edge and they leave and they do something else. So we haven't been using the TriEdge agent long enough yet to be able to have a definite answer on this, but my hope would also be that it will ease up some of the burn or bore out that we see in analysts, right? And actually let them do more interesting things. Yeah.

Fully agree.

I think that's actually like— I like that because to me, this is the— well, it's an obvious, again, common sense answer. But I just want to caution you against measuring the time because, again, it came up in a few discussions before that people say, well, obviously, things would go faster. And I said, you're right. Obviously, things would go faster. But guess what else is faster? Just deleting all the alerts. It can be even faster. So, if you measure the speed only, like MTTD, You will immediately end in a ditch. And also, Tim made a wise point in one of the other podcasts. He said, well, of course, automations make things faster. What do you expect? But if you— sure, but if they become 3 times faster and 10 times worse, that doesn't work. You probably lost. Yeah, it doesn't work. Or even if they get 10% faster and 3 times worse, you still lose. So, to me, that's—

I'm happy to do another episode with you on SOC metrics. I still haven't found the perfect one yet.

Oh, we are so having you down for it.

That would be really fun. So I really hate to do this, especially as we were just getting into what I think is really a slightly different interesting territory of like, what are the human beings going to do in the future? This is something we talked about on the Mnesia episode that I thought was so fascinating of like, well, now we're unlocking humans to do things that they're actually good at rather than these painful things that have burned them out or bored them out for decades now. I actually have to close us because we're way over time, listeners, and I hope you've hung on for a longer than normal episode. For both of you, you both get our traditional closing questions of, one, do you have a tip to help people adopt agentic capabilities in their socks? And 2, do you have recommended reading? And that recommended reading could be anything from a beginner's introduction to sailing theory to a history of German cars, whatever you want to share with people that you think they might like to read.

I have one item, and I think that's definitely fix the data first.

Mm-hmm.

I think one of the things that we started looking into is our data quality before starting working with the Google team, and also while working with the Google team. Turns out the agent can be as good as it can be. If the data quality isn't there, you are going to get into trouble. And I think one of the really important parts of this is actually to continuously monitor your data quality. Like, it's nothing that you could do only once or twice or something, but actually build automation around monitoring it. Because as I said before, the human analyst will notice that this looks different to what it was yesterday. The digital analyst or whatever, the agentic agent doesn't yet. I think it might get there. But at the moment, it doesn't detect it yet. And you might get into exactly this, you know, 3 times worse because the automation doesn't find it or the agentic agent doesn't find it yet.

So as for recommended reading, I actually have 3. One of them is a bit cheeky, right? So I'd start with your company's annual report, because that tells you where the risks are and what the priorities are for the company. Sounds stupid, but that really helps you set everything up beyond that. And also gives you the risk appetite normally to a certain extent. And then 2 more books, right? One is How to Win Friends and Influence People.

A classic.

The classic. Now, don't do everything that's in that book because it'll make you look like a robot, but it helps you. You can't go this journey alone, right? So, the SOC alone can't do this. You need data from other people. You need to interact with other people. You need to build allies in the organization. And that's important. And the 3rd one, just because I can, it's Will It Make the Boat Go Faster? So, that's another shared love that we used to do rowing. It's a book by the British Olympic team that started challenging every decision with, will this make the boat go faster? Otherwise, we don't do it.

I didn't know that you two also rowed. I rowed throughout high school. There we go. It is a terrible, miserable sport.

Or you can consider it fun. I don't know.

It's an elite sport, though, right? It's not like a— I'm trying to make a gesture down.

You're talking to Tim that has an airplane.

Yeah.

Well, fine.

No, I mean, some of the greatest highs of my life have been at the end of a sprint. So I— yeah, what a great sport.

I agree. I agree.

All right, listeners, on that note of reminiscing about victories and losses in rowing boats, Lars and Alex, thank you so much for joining us today.

Thank you for having us.

And now we are out of time. Thank you very much for listening and of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast. By Google.