Name: Nerdy 30 live: How should we think about AI risk?
Uploaded: 2026-08-27T19:16:10.429Z
Duration: 46 min 16 s
Description: Nerdy 30 live: How should we think about AI risk?

Transcript for "Nerdy 30 live: How should we think about AI risk?": Give me the beat. Nerdy thirty. Laid back beat, knowledge flows. Step into the session with the info type, dropping facts, connections, sparking in the night. LinkedIn Live, we bring the insight flow. From tech to biz, watch your network grow. Mine on innovation, vision in your sight. This is where the nerds unite and ignite. Nerdty thirty, we keep it live. Knowledge popping, ideas thrive. Nerdty thirty, feel the vibe. Join the stream, it's our time. Nerdy thirty. Nerdy thirty. Nerdy thirty. Alright. Believe we're live. Hello, everyone, and welcome back to another episode of the nerdy 30. I am, particularly excited about this one. We are introducing a new framework which you can use to think and communicate about the risks that AI introduces to your org. I'm your host, Ben Baker, director of content at XPEL. This is our ninth episode in the nerdy 30 series. We actually have other episodes of cool topics like how dangerous Claude mythos and emerging LLM models actually are with our friends and researcher, Marcus Hutchins, and James Schenck, who is our guest today. We have a cool episode on AI malware, how to measure your sock, and and much, much more. You can check out all of those videos at our YouTube channel. It's youtube.com/@expelsecurity. If you look at the docs tab on the right hand side of your screen and click that, there is a, there's actually a tab there to go to our YouTube page. Go, go subscribe. Just go check it out. This nerdy 30, as always, sponsored by XPEL Security. XPEL is a human led AI accelerated managed detection and response service. If you want more information about how and why we do what we do, I would recommend you join a group demo. We call these demo casts. You can check that out at expel.com/democast or again, click on the docs tab over on your right. And, and within the docs tab, you will see a, a CTA, but you can click to lead to that page. We actually have one tomorrow, so you should go join that one. Alright. Before I tee up the topic and intro our guests, let me first, address the format, if you've never seen one of these before. Like I said, this is called the nerdy thirty, thirty minutes talking about nerdy topics. After I intro our guests, I'm gonna time myself counting down from thirty minutes. At the end of thirty minutes, an alarm will go off. And at that point, we'll transition into q and a. Please, please, please drop in questions and comments during the session. If for any reason we don't get to your questions, we can do a follow-up blog where we'll address any outstanding items. You can check out our blog at expel.com/blog. If you don't have any questions, frankly, I'm probably gonna break my own rule and just keep talking, and keep asking questions of my own because there's some really rich content in here, that I feel like it's gonna be tough to pack into thirty minutes. But, hey, we'll see. We'll see. Alright. To the topic. Today, we're talking all about AI risk because I mentioned. Alright. Imagine with me this scenario. Alright? Someone in authority comes to you and says, hey. We're protected against AI. Right? And suddenly, thousands of questions explode into your mind. Do you mean AI being used by attackers? AI being used by employees? AI tools we've created, prompt injection, rapid vulnerability discovery, deep fakes, regulatory concerns? And you realize suddenly in a split second that the implications for AI are massive. Right? And it's really damn hard to communicate about it. And so I'm unsure if any of you have found yourselves in that situation, but I hope you have because that's what we're talking about today. James Shake, who I'm gonna introduce here in a second, pull in here. Our director of threat operations has put together a thoughtful framework for you to use to help you kind of clearly, see think clearly about the lanes of AI risk, and to hopefully grant you a little bit of sanity and help you communicate about those issues, to those around you. In the coming months or so, just heads up, we'll be releasing a white paper version of this framework so you can dig in deeper. Go keep an eye on our LinkedIn page, for promotion around that asset. Our session today just treated as a sneak peek of sorts. James gave, information, gave this talk track at Black Hat, and this is, just kinda rehashing, a lot of what we talked about there. So I'm gonna pull in James. Let's see. Pulling you in here, James. Let's see. Push here we go. James. Hello. Good. to yep. Welcome. Glad to have you. Yes. Glad to be here. Thanks for that introduction, Ben. I think you framed it, quite well. This is what what we're gonna talk about, and the the why behind it is man, there's been a lot of uncertainty about the questions that that have flown by my screen from customers, from people in the industry about risks associated with AI and and how we're addressing them. So doubt. No doubt. A little bit about you, James. You joined XPEL as the director of threat operations in 2025. Prior to XPEL, you held various roles at threat intelligence company Spy Cloud, and I mispronounced this every time, but I'm determined to pronounce it correctly. Team Cymru. Yay. You. got it. Alright. Excellent. I'm glad to hear that. James keeps the needs of the, Internet information security community at the center of his efforts, which frankly is at the center of what we're talking about here today. He's involved in and coordinates several community oriented efforts to combat online threats and, somewhat recently was a part of a collaborative effort to take down Emotet, which is awesome. Works with community members to find innovative solutions to thorny issues that are hard to solve by individual operators. James. Yes. Again, glad to have you. This is gonna be great. Alright. Awesome. Alright. I'm going to start my clock. I have my timer here on my phone. Alright. The thirty minutes has started. Let's dig in. Just a reminder, everyone, add in your comments or questions as we as we go through this. Alright. Oop. Didn't mean to do that. Alright. Before we jump into the framework, I wanna build some suspense and kinda tee up the conversation really digging into the why behind this. Again, you kinda talk to this, you know, you created the framework. I've I've read early drafts. Super helpful. I think it's gonna be great. I can't speak for everyone who will eventually read this, but I found myself honestly feeling very overwhelmed as I was reading this. I think I actually mentioned this to you, in some of our earlier talks. You know, when you think through the lens that you offered, you realize that there are so many domains where AI has introduced risk. But this report is not funny. It's not about fear, uncertainty, and doubt. It's very pragmatic, very practical. For you, why did you feel driven to create something like this? I I love that question. So I think there's a a few different, there's a few different answers to that. The first and the most obvious is because of an emergent need. When when we started getting questions, when I've started talking to people and people were talking about the subject of securing AI, It runs the gamut of what that might mean to a specific person. A lot of times it means how do you take an AI model and secure it? How do you build in safeguards so that it doesn't help produce nuclear weapons or biological weapons? That's one category of of security risk related to AI models. But a lot of people, they don't have to deal with securing the models. They're more interested in how do I secure my enterprise given that AI is a reality of the operational environment that we find ourselves in today. And that's where it became it became very ambiguous what what people meant by securing my environment from or with or in regards to AI. So the second answer to the why is because we need a way to systematically change how we do security in our environments to address the risk that's introduced by AI because it doesn't model what we've what we normally find ourselves having to deal with. If you think back on some of the other introduced technologies that and I guess, let me let me take one step back here. Oftentimes, security has to just adapt to what what's thrown into our environments. Right? We we don't get to control the flow or the innovation of technology. We just need to come out the other end of it and with a reasonable risk mitigation and, approach to handling risk on the other side of it. So if you think through some of the evolutions recently of the move to the cloud, then the that eventually became hybrid environments. BYOD, so bringing your own device to work that became pretty prominent with the advent of COVID as well, Mhmm. where everything became, kind of remote first or remote as a central component to, our operational environments. All of these changed some aspects about how we approach security. They changed maybe one, two, or three things that we have to do. I would argue that AI is changing many more aspects of how we have to think about security than, than these examples that were still fundamental shifts in in, how we how we secure our environments. The ad the introduction of AI into the operational workflow of companies and the doors that it opens to how threat actors can work, how our employees work, and how our environments are structured, it's a lot. It is a lot. And it it demands it demands a systematic approach, tools and a framework in order to really address the gamut of what that means. Yeah. I know in the white paper in the framework white paper, you mentioned some of that about how this isn't like this isn't like, like the cloud or, or like BYOD or, you know, any other sort of security, in a or any technology innovations that we've encountered in the past. It's it's something brand new. And one of the things that you mentioned is, I'm actually gonna try to share my screen here. One of the things that you mentioned in regards to let's see if I can get this. Yes. There we go. One of the things that you mentioned regarding, there we go. That's better. Regarding the shift, our key assumptions that we've kind of held historically within security that are being challenged by AI adoption. And so you list nine of them. They're all here because you can see humans make decisions, identity maps to a human actor, data movement provenance are clear, execution is deterministic, intent and action are directly linked, observability sufficient for reconstruction, Time exists between attack phases. That's a crazy assumption that's being impacted. Vendors are infrastructure providers rather than decision makers, and there are clear accountable priorities. You know, we we have these. In your opinion, if you can if you can choose this may be an impossible question, but I'm gonna throw it out there. If you can pick one of these, what scares you the most about AI challenging these assumptions? So I would say the thing that causes me the most concern is observability and reconstruction problems because I think this is the this is where the shift this is where observability is always a challenge. Right? Security has to adapt to, like, what we can see all the time. But this introduces AI introduces, some distinct problems with the ability to understand what happened next and what happened as a consequence and who what was the intention behind the the prompt that some somebody sent? What was the intention behind the, you know, third or tertiary level, prompt that an AI agent might have sent? And the other thing about the the the observability is even with the observability of the prompts and understanding, like, what people are asking the AI models, you don't necessarily have an understanding through that of what their understanding of the model and how it responds to, different prompts is. And as a consequence of that, because they're probabilistically driven systems and not deterministic systems, you run into the what does this mean. Totally. And when you get into a what does this mean question with logs and observability, sources, now you have legal nonrepudiation problems as well. Right? This introduces that, well, I didn't mean for it to do that. I meant it to it meant for it to do this. And so there's just this whole, like, domain that, like, ties into that reconstruction problem that becomes it becomes really big in scope. And so I would say that one is is the one that causes me the most concern. But but all of these are are significant, Of would say. And and and the where the significance raises to the bar. of, like, of this being different than everything else is that they're all present, Mhmm. Yep. not not two or three of them. Two or three of them, you can kind of get your hands around and figure out how to, like, how to respond to that. Them all being present makes the the the approach to how to solve for them a fully cross functional and strategic effort rather than a, more operational or tactical and and more confined to a single department or single organizational unit sort of effort. Yeah. Which is which is, part of the reason why you put this together. Right? To, to teach how people where the different domains where teams can intervene because it's not owned by one team. Right? It's it's kind of spread across the org. Let's, let's, let's hop into the actual, 10 domains that you introduce, that that are introduced by AI adoption. We can read them here. You know, there's 10 different domains. Most of these are are relatively self explanatory, I think. And as you mentioned, observability is actually a domain that you mentioned in here that sort of stretches across all of them by way of control planes, which we'll talk about control planes here in a second, kinda pick your brain on that. But, you know, most of these, I think, are self explanatory when you read the names of the domains, the titles of the domains. But do you feel like there are any here that warrant further definition? You know, we may not be able to define all of these in-depth, but based on your conversations with others about the framework or maybe conversations you had at Black Hat, like, are they do you get requests about clarifications on certain ones more than others? I think there are a couple of them do merit a little bit more discussion. I would say that the the defender operating model disruption is one that that needs a little bit more discussion. I I think it's one that a lot of people are already recognizing as as happening. This has to do with in short, the only way that we can defend against, AI creating like, doing, application security sort of audits and finding exploits at scale and quickly enough means that from a defense, a defender, position, the AppSec, review processes should be integrated and automated, so that we can get ahead of and use the same technology that is being used to find those, by actors. Get ahead of that. We have the advantage here, which is a it's it's kind of a unique sort of situation. Most of the time, people think of AI as creating the advantage giving the advantage to, attackers. The reality though is that we have the source code, and we have our network diagrams, and we have our security, playbooks. We have our security. We know where our gaps are already many times. Like, if you talk to enough people within within the org, you'll get a you'll be able to surface a lot of gaps. Are we taking that information, feeding that into models and saying, like, where do we need to look? What do we need to focus on? How do we need to secure our environment? Where do we ramp we need to ramp up controls? Where do we need to adjust controls? Is our config solid? Is our code solid? If we're not doing those sorts of things and if we're not thinking about this as, enabling the defender with AI tooling so that we can get, we can match the the pace of change within attacker, tool sets. We're giving we're giving up the game to. the attackers. Right? That's a that's a winning decision, and and there needs to be a collective understanding. It needs to be in conjunction with GRC. We need and you need to properly assess the risk of exposure of data, to different, hosted models if that's the approach you take or what your risk appetite for for surfacing those sensitive data points to models might be. That might be a case for setting up local environments and running local models. But. point is if we're not thinking through how do we enable that, then we're deliberately falling behind, and we really need to rethink, how to stop doing that because it's that's a that's a bill that we don't wanna pay later. Yeah. No time no time to fall behind at this point. So, defender operating model disruption. Any others that you feel like you received questions about? I mean, you know, a lot of the vulnerability discovery and exploit acceleration, we've heard about that in the news with Claude Mythos and different things like that. You know, attack chain compression orchestration attackers moving faster than they typically do historically. Again, a lot of these are, like, self explanatory. Is there anything else besides observability, which we already talked about, and, Defender operating model disruption that, that, you know, merits further discussion here? Yeah. I would pull in the thread of domain two as well, the the identity authorization and boundary degradation. I the the unintuitive thing that's embedded within this is what who or what is taking the action. Right? With with traditional identity, we've already made the evolution from identity being only a person to nonhuman identities. This is a entirely different form of nonhuman identities. This is not a device that's running some automation. This is a system that's making some decisions that are nondeterministic actions. The that we need to think through what that that space needs in order to address that. I'm starting to come to the conclusion that we might need something different than what we have. Yes. This this is a case where the way that I think about this is, to pull on a few, older terms, like, it's almost a difference between discretionary access control and mandatory access control. Discretionary access control is, not giving you explicit grants based on the context in which you're operating. And that's that's still very common in the way that we approach, approach user and identity security. We need to move to a model where we have the context of what is executing. And that influences the the downstream authorization and the downstream access from the, from the, whatever is taking that action, whether it be a human, whether it be a nonhuman automation system, or whether it be an AI agent taking an action. Mhmm. I remember, I worked at a cloud security company a few years ago. And even before the AI explosion, which I feel like we've experienced over the past few years of mass adoption of these platforms, I remember we were already talking about nonhuman entities in in the cloud and despairing at the state of entitlements management, identity, entitlement management already, and then reflecting on what the impact of having an influx of nonhuman identities is gonna have on your cloud environment. It's just it's a different world a different world. So, totally understand that one. I, wanna ask you some pointed questions about a couple of these. Let's, let's go back to observability. So, get a kind of get meta on the framework here and talk about the structure of the framework. Observability is really unique against all of these domains because, you list observability also as a control plane, within your framework. So, explain the concept of control planes, within the con context of your framework, and then and then maybe talk about how observability is both a domain and a control plane. And I actually have a I have a slide listing out all of your control planes here. So, yeah, give us give us some insight on that. Yeah. Yeah. So the the control planes answer the question of where we have the ability to implement controls. Right? They're broad and they're a little bit abstract from a specific surface. It's not it's not but you're not going to see, like, Okta, for example, surfaced as a a place where we have control. But the I but Okta would be a a subcomponent of identity. Right? And these these control plans help us to understand I I guess, downstream from from just defining them, they help us to understand what teams might be involved with answering the the question of how do we go about, answering our risk concerns related to the domains that that these control plans are, exist under. And to go back to the structure just slightly of the the framework, to answer the question, more completely. The each of the domains have associated control planes that are influenced in in in scope for each of these domains as well as information like the actor context. But to go back into and answer your question directly, observability is a core component of security that's oftentimes overlooked until it until it's until you need it and you see the gap. And I. I to some degree, that's a a natural occurrence as you as you're building out systems and whatnot. But the ability to reconstruct what happened is essential to the ability to understand how do we defend against it happening again. And in many cases, the what happened also has implications for legal concerns that might have cons, implications for whether or not insurance pays. There's implications for the for every part of security in terms of what observability allows you to tell about what what happened. And, frankly, honestly, what happened is one of the first questions that leaders will ask when when you tell them we have an incident. It's very natural. Okay. What happened? You. know? And and our ability to answer that is core to our ability to perform our jobs in security operations. So observability as a control plane talks about how it how observability enables us to affect controls and answer questions about compliance and answer questions about, high level risks. But as a domain, AI does change certain elements about traditional observability that make it that call into question certain elements of how we go about mitigating the risk and how we go about answering the question. Gotcha. And so to answer your question about why does it exist in both both places, it's a critical control element that is necessary for us to to be able to go about the next activities within security operations. It's a domain because AI changes what it means. So if you have, if if domain 10 is being, sort of disrupted by AI, which is what we have sort of established here. But domain 10 is embedded as a control plane in all of the other domains. I would assume that that's priority one. Get your, get your, observability in order. And what does good observability even look like these days? Is it achievable? You know, what what is that what what's possible there? So those are great questions. In terms of the prioritization, the the domains have a number associated with them as a as an ordinal, but not as a, but it's not intended to a. priority a priority order. Yep. Depending on each organization's risk profile and how they operate, these are going to these are going to be surfaced as different priorities within within an organization. So I I I would only slightly augment what you said in terms of it being priority one. I it's not always going to be priority one because some organizations might have this well handled already or or mostly well handled already, Sure. where where their their predominant gap is somewhere else. But, what does good observability look like today? Let me answer that in the in question form because I think the questions will will help to paint a picture. The the role that observability plays in security is kind of twofold. One is it it's helpful for detecting things, and secondly, it's helpful for investigating things. So the the natural answer to what what does good observability look like today is does your ability to see what happened help you with your hunts? Does it help you with your investigations? And does it answer the questions that you that you are left with? And the the way that AI influences that and change that is it, a a a few different ways observability has changed. First of all, like, there's a question of who intended the action that was performed or possibly what intended the action that was performed. The second thing is, do you have visibility into the action that was performed as well as what caused the action that was performed? So are you logging the prompts? Are you seeing changes to that might be, implemented downstream into in terms of your compliance for prompts? Are you seeing changes to any of the context that's being injected? Also, are you aware of the training data that goes into the model? Because one of the other problems you run into with observability is even if you have prompt awareness and you don't understand the model training, you don't really have a a way to map the in a reliable way, map the prompt input into an expected action on the other side, Mhmm. which this this plays into the whole determent, execution is nondeterministic, problem. So did I answer your question thoroughly there, or. Alright. A you up with a question on. the. other. No. side of. that? No. No. No. No. Yeah. No. I think it's no. I think we've I think we we got, we got the gist of it for sure. I wanna jump to so add in your questions. If anybody has questions about this, continue to put them into the chat here. Time check, twenty two minutes. If you don't add questions, I'm just gonna keep asking some of these once we run out of time because I've got them. I got some questions. So let's do, let's jump to domain three, instruction manipulation. A lot of vendors, you know, wave off, prompt injection as an engineering problem, maybe could be solved with guardrails. You say that that's not the case. Why are you skeptical? Right. So I I'm skeptical skeptical for two primary reasons. The the first is that guardrails are doing in in their best case, they're doing intent or, semantic sort of classification on what's what's happening, or they're possibly killing different pathways that as the as the model is progressing through its answer. These are all able to be manipulated by a, sufficiently skilled actor. And we've seen, several examples of of evasion of various controls in terms of, prompt evaluation. The but but to talk about this a little bit more along the lines of the the domain, the right now, like, right now, what observability do we have into, whether or not any prompts are being, manipulated between our systems and elsewhere? What is the context in which the question is being asked and answered? And how are is the model incorporating the the context into what you're asking later? Now some of these are well defined, but how much of that are we are we considering when we're as assessing the security implication of what the that the meaning of that prompt is. Sure. Right? In addition to that, context and prompt injection, depending on depending on how well you're monitoring and looking at changes that are injected into your environment, this becomes a it kind of degrades into this, semantic game of who has the best, way of quickly assessing what a prompt or a change means. And even when you do that with only the prompt or only the the context context that's injected as part of the the question, you don't necessarily know how that performs within the model itself. That is there's is, the layer of complication that is a little mind boggling. So Well and and it's fundamentally nondeterministic that's right. well. So. it It, you there's this, in inside of every, section within the framework, you add these strategic realities. And your strategic reality for instruction manipulation is, quote, execution integrity depends on the integrity of everything the system reads, which is horrific to me. So yeah. Right. Yeah. And we've we've already seen examples of this where, where there's, you know, white on white text that's embedded within documents. Some people are using this to try to bypass automatic AI filters for job applications, for example. Students are starting to use techniques like that to evade, AI detection systems that their teachers might be using. And more maliciously than that, it's starting to be, injected in places where security controls that are implemented using AI, AI prompts and parsing the data through AI prompts. So there's attempts to inject that into spam, for example, or email messages or other documents that are known to known to be entering, AI workflows for assessment. How about that? We have three and a half minutes left. We're just gonna keep going. We have, I see a question came in from Jeffrey. We'll hop to that, here in a minute. I wanted to hit let's actually let's go ahead and hit this question, actually. Let's go and do it. Jeffrey asked, who's truly accountable for AI agents that are intertwined in daily organizations, in their operations? Who's accountable? That is a great question, and it's hard to answer. The in many cases, the user doesn't really have full control of agentic systems. The the, like, the the core attribute to agentic systems operating is that agents are able to commission work through other agents. That means you've got AI talking to AI to do things that AI is asking other AI agents to do. Okay. Recently recently, there was an example of this that I I think I that highlights this problem. There was a a person that was scheduling a a a gym slot, I believe it was, or a therapy slot. I can't remember exactly what, but, the agent ran into a problem. There were no calendar items. The calendar slots that was the gym in Australia. were open. Right? Yeah. Yes. And what did the agent do? Oh, well, I the agent found that the to cancel an appointment was an an authenticated action. So I'll just cancel somebody else's appointment. Sure. Now you've got got the slot the AI agent did and the AI did what the what the person asked the AI to do is go schedule me a slot. And he was very proud. The a AI agent was very proud of itself. for doing. this. Yeah. Like, look, I solved your problem for me for you, you know. The I I guess, as you start progressing that through an, an agentive system where there where the code the execution of the the user intent becomes, like, third, fourth, or fifth order sort of actions. I I know in my own AgenTek systems that I'm that I that I've built, I I'm not telling the AI to do what it ends up doing. I'm telling it to build something big. Right? I'm telling it like, in one case, it was a here's a presentation about an open source, way to solve this problem. There's basically the content from four slides, cut and paste, and then the result is, you know, a lot of code being written, a lot of design being done by the AI agents. Did I intend everything that it that it created? Well, no. I didn't intend that. Like, I didn't I didn't even fully control that. And in fact, in some of my agentic systems, my agents are commissioning other like, building out other agents that they find as a gap. Like, so I don't I don't I'm not even, like, explicitly intending for that agent to even exist. So who is ultimately responsible? Well, frankly, there a quote that I'd like to go back to is in, in the corporate world, like, AI does not change RACI. Right? Ultimately, the accountable party is the person that's con that's employed for that particular role. They're accountable for all of the work that results in all of the output and all of the action that results as a, out of what they they start and what they initiate. But on the flip side of that, there is the question of, well, at some point, as it becomes a a, you know, third, fourth, fifth, sixth, seventh order sort of action that's commissioned by AI systems, is it the same? And, also, if they're using agentic systems or they're using, prompt context or skills that are built by colleagues, then how much is the person that's using it and telling it to do something responsible for the output versus the person that built the skill? It so much. gray area. So much gray area. Yeah. Exactly. Exactly. And so it becomes a it becomes a very legitimate observation problem and attribution problem very quick. Yeah. I see more questions coming in. Let's do this. I have one more question about a domain, and then I wanna tie a bow on this. We're officially over thirty minutes, but that's okay. We're gonna we're gonna tie a bow on this, and then I'm gonna loop back around to q and a at the end. So if you have questions, send in your questions. I wanna touch on one more domain, and then, ask a question about, about, you know, practical practicalities moving forward, from your perspective. But let's hit domain four because domain four honestly ties into the discussion that you, myself, Marcus, and Greg had, whenever Claude Mythos was in the news, and had all of these reports about vulnerability exploitation and finding these vulnerabilities, you know, all over the place. You, you say control now depends on limiting exploit impact, not necessarily preventing discovery. To me, that sounds like almost conceding the front door. Yeah. Is that is that what you are, is that what you're sort of implying here, and is that a mindset that security security leaders are, are ready to make? I think it's a mindset that we've all adapted to already, after you get get past your, you know, the your first few years in the security field. The the reality is that compromise is not always avoidable. Sure. We have incidents. That's why we why we have playbooks to run down incidents, and that's why we have IR as a function. That's why we have, like, forensics as a function. The the point here is that to in many ways, the way that that security incidents start with exploits surface, though it's not always easy to see that. Now there's a part of it that is easy to see that because some of them are quite noisy. A lot of them are quite noisy, in fact, but some of them are not noisy. And for the ones that are not noisy, the the there might not be a log message emitted. There might not be a system performance change. There might not be anything except now you've got a device that's under the control of somebody else or maybe something else if if if it's AI enabled sort of attack. And in those sorts of incidents, the places that you catch the activity is in the attack chain development. And that that's that's been true for a long time, but. I do wanna pull one other thread on the same domain. Yep. So I was one of the reviewers of the CSA paper that talked about Mythos, and and I'm glad that we sent off that signal flare. Like, that signal flare was a is a necessary thing for us to to fire. But we haven't seen the vulnpocalypse that people have predicted really surfacing in the data that we've that that I have seen, and it's not having the impact that everybody assumed that it would have. Why not? One of the fundamental controls that is not controls. I'll change that word. One of the fundamental realities that we operate within is we have attackers and we have defenders, and everybody is motivated by certain things. Now there are some chaotic sort of actors in in some cases, but a lot of actors have some intention that they're trying to accomplish. They're making money or they're stealing data or they're, causing havoc in some other way. And these these things that the actors are after, they fundamentally run as an as an underground economy. They fundamentally are are, you know, selling services. They're selling capabilities. They're using capabilities that they commission from the the underground. So long as that pipeline is doing well, they're not necessarily going to change to something. It's when they encounter a problem where they need to, evolve because some something changed environmentally and they're not as successful as they were before. Mhmm. That's when they change their their business operations just like every other company. When you course. when you've got a product selling gangbusters, you. don't go and say, let's change the product a whole lot. You say, like, well, how can we add to that? How can we expand? How can how can we do the next thing? That that changes changes our overall success pattern, but while maintaining, like, the continuity of that that product success. Threat actors, a lot of them are operating with similar sort of fundamentals. And as a as a consequence of that, even if some capability becomes emergent, it doesn't necessarily mean that threat actors are going to jump on it right away. Mhmm. Yeah. You said, companies don't change what they're doing, if their product's selling like gangbusters, except for Coca Cola with Coke too, which, didn't turn out too well for them, sadly. So, send in more of your questions. I got one more question for you, James, and then we'll grab these questions, and we'll, we'll we'll get out of here. You, what's the action item for Monday? You know, in light of this framework and, again, I know we're packaging this up. I know we're gonna send out white paper form. But for people on Monday who are attending this today, who don't have the white paper yet, but they've seen the risk domains. They've seen the control planes. You know, they've seen, they've seen the the, assumptions that are changing with the introduction of AI. What is the takeaway on Monday? That's a great question. That's a great question. I I would say start understanding all the elements of the the risk appetite for your organization and start understanding how the domains, how the control plans, and how AIs changes to the fundamental, your fundamental environment interact with that that organizational organizational risk appetite. I I know that's a high order question to start to answer, but the thing that you can do now is start having a very clear picture of what is acceptable, what's unacceptable in terms of your organizational risk appetite. That's foundational, and that that's going to drive the priorities as soon as you start piecing this apart and understanding how do we commission the downstream work and how do we report upstream to executives and to the board, how we're controlling for the organizational risk appetite. Yeah. Some of that found foundational work that needs to be done. James, this is great. Let's hit a there's a question here from Jeffrey. Another one here. Let's hit this. He says, would intentional AI leakage be more a data security issue or a SOC issue? Again, I think this goes to, you know, responsibility and swim lanes and things like that. It's hard to say. It might be a GRC issue. It might be a legal issue. Oh, yeah. Issue. That's true. it it depends on what's being leaked. Honestly, it could be, it could hit other teams as well. So the, I would say the the answer to that is conditioned upon what the what. what ends up being leaked. That makes sense. Alright. We are at the forty five minute mark. So I say we round it out, and, tie a bow on this. I'll say this to everyone who attended. Thank you. Thank you for attending. I hope you enjoy the session with James. We're currently working on the white paper version of the framework. And as soon as it's done, keep an eye on our socials. We'll be promoting that, and, and you'll be able to take that and share it with, with your with your coworkers and colleagues and start to get a handle on how we should be thinking about AI risk within our organizations. So, James, appreciate your time today. This was really helpful, really great framework you have here for us. So Thanks, any. Appreciate it. Appreciate. the opportunity. Yeah. For sure. Hope everybody has a good rest of your week. And if you have any questions, reach out. We'd love to, would love to hear, hear more from you about this framework and and your thoughts on that. So, until next time on the nerdy 30, hope you have a hope you have a good one. Thanks, everyone. Cheers you. all. See you. Bye.