Welcome to the Practical AI Podcast, where we break down the real-world applications of artificial intelligence and how it's shaping the way we live, work, and create. Our goal is to help make AI technology practical, productive, and accessible to everyone. Whether you're a developer, business leader, or just curious about the tech behind the buzz, you're in the right place. Be sure to connect with us on LinkedIn, X or Blue Sky to stay up to date with episode drops, behind-the-scenes content, and AI insights. You can learn more at practicalai.fm.
Now, onto the show. Welcome to another episode of the Practical AI Podcast. This is Daniel Whiteneck. I'm the Product Director of Exploit Development at VolmCheck, Spencer McIntyre.
Welcome, Spencer. Hi. Yeah, thank you for having me. Yeah, definitely. Well, I know today's events, we may not be able to go into detail because we're still learning all the things, but it is evidence of something that is on the top of everyone's mind, which is how AI intersects with this world of cybersecurity, particularly around discovering exploits, developing exploits, the offensive defensive side.
Excited to dig into some of that with you today. But our audience maybe isn't coming from, not everyone's coming from a cyber security background. Could you help us understand a little bit about your background, how you fit into this world? People might find the Director of Exploit Development title rather interesting. Just help orient us where do you fit within this world?
What are you doing right now with VolmCheck? That sort of thing. Yeah, absolutely. I was really excited when they offered me the title of Director of Exploit Development. That was pretty cool.
Yeah, that was pretty cool. Yeah, I've always been really passionate about exploits. That's kind of actually how I got into the information security industry. My background started out in consulting, but being very interested in Exploit Development at the time, I was under the impression, this was a long time ago, that you really needed to have a strong background in vulnerability research and have a pocket full O days really to do a job as a investor, which I would find out then was not necessarily true and is not true now. But that was what I was told.
So that was how I got started. And then after kind of working in consulting for a while, I slowly transitioned full time into doing research and development, which has really been my focus over the past 10 years. Some of that overlap with research and development in consulting, which was really interesting, because I got to work with a lot of different organizations in the private sector as well as a few different governments, hospitals, education, retail, hospitality, a bunch of of different things. But then yeah, I slowly transitioned over to working in research and development full time. I have an extensive background in the medsway framework doing model development and things like that.
I was kind of a big part of it and kind of on my journey of doing an exploit development that brought me to VLNCHEC, where as you mentioned, the Director of Bexley Development and I work on the initial access team, which provides the data for our initial access intelligence feed. And maybe just to dig into a couple of those terms, just briefly could you explain maybe Metasploit for those that aren't familiar. And then what you mentioned, you know, at the end there around the particular feed that you're plugged into, like what that means in the context of VLNCHEC. Yeah, absolutely. So Metasploit is a framework for exploit development and penetration testing and vulnerability validation.
At one point, it was the second largest Ruby project, I believe, behind Rails. I don't know if that's still true. But it's a pretty large project. It's been going strong for, I think it's celebrated its 21st birthday last year. So a pretty old project at this point.
I started back in like Ruby 1.8. But it was a platform for vulnerability researchers to be able to develop their exploits and kind of share them in a normalized format. And this, of course, started quite a while ago. The industry has kind of evolved since then. And a lot has kind of changed technologies, protocol stacks.
We were doing things, the advent of AI and completely altering our workflows in the past few years. So we'll talk about quite extensively, how things have operated and how vulnerability researchers have approached a lot of these problems. And also we've seen trying to where things have been dispersed quite a bit more. There's not really centralized resources for a lot of this information, which is one of the ways that the initial access intelligence VLNCHEC provides actually offers value to our customers and our users. It is timely data.
One of the things that we really focus on is the speed of how fast we're able to provide this information. It's a holistic view of the vulnerability of which the exploit is one part. But we also provide detections and a high level understanding of how the vulnerability operates. And then we package that up into a data feed and then provide that to our customers. Yeah.
And you even use some words there. You mentioned the exploit isn't the only thing. When events happen, it's happening in today's new cycle. Could you help orient people what defines an exploit? What is that?
And what is the important context around that exploit that may be not the exploit itself, but things that we may use in the rest of the conversation that people just need a grounding in? Yeah. I think you had mentioned earlier that an exploit was discovered. And I want to have my well, actually card. Please do.
That's what we need. Consider me the new and learning along with you. Yeah. There's like, you want to do the term that I'm really passionate about. Even in the context, when you're talking about consulting, people use the phrases differently.
You can understand what people mean. But for vulnerability is basically the potential for something bad to happen. If you really dive into a lot of vulnerability research, vulnerabilities have to be validated. But that line of what constitutes validation and then what would actually be useful by an operator of an exploit that's trying to do something like legitimate testing or a nation state after or something like that, regardless of what their motivations are, is going to be typically almost always higher than what the industry would generally consider to be proper validation. And that's a good thing.
I want to clarify that that's a good thing because people basically saying, well, you know, it's hypothetically possible that this could lead to realistic bad outcomes because we have this hypothetical bad outcome that we've proven. So we're going to take this very seriously and we're going to fix it. We're going to apply the patch and for things like that. So the vulnerability is really the abstract concept of like what the flaw is and what could be done with it. And an exploit is a concrete implementation that leverages that to do something.
I'm curious, kind of tie in, I've used Metasploit in the past, not just as a user trying to make sure that, you know, that my own infrastructure was up to speed. And you know, as we look in the last year in particular and see how clearly things are changing heavily in your industry specifically with things like Methos developing, you know, all sorts of insights into vulnerabilities and identifying those and stuff like that. How like can you as before we dive into a lot of the specifics, can you level set for us kind of where, what the landscape is now and you know, and how it's evolved into that and what is that required you and people in your industry to kind of pivot on to, you know, because the world has changed, you know, with this with these AI capabilities that are doing that.
It's one of those things where those of us that are in AI, but not necessarily in security specifically, you know, we're right on the edge of that and wonder a lot. I was wondering, I'd love to get that kind of general perspective from you. Yeah, absolutely. So disclaimer, I've never actually been accepted for like, Methos access myself. I have experienced a bunch of other models very hands on and everything.
But what I've kind of seen kind of actually goes back to that difference between like vulnerabilities and exploitation, I'd really like to mention because a lot of the AI models, whether it's MSOS or OAPIS-55 or what have you, you know, the O&A models or GLM, they seem to be doing a pretty decent job at identifying vulnerabilities. But then where people oftentimes struggle is with like, okay, this is a vulnerability you can look at in the code and you can understand like, no, this is bad, this bite is overwritten or this token is leaked or something like that. And that kind of seems to be where the analysis stops and people take it seriously and they want to go and patch it, but then a lot of these end up getting hyped a lot. And I think where there might be a disconnect is what the impact is of a lot of these vulnerabilities.
And that's because like we're kind of missing that gap between, you know, the validation and the actual like functional actually that proves attacker utility. And that is how could utility is something even a legitimate pen tester or like a lot by a citizen would really need to understand because there are so many of these vulnerabilities. As you mentioned, there were like big ones that came out today. So people are often struggling with is the prioritization. CDS is not going to get you so far when there's 20 CDSS, you know, nine and aboves.
You really need to understand the attacker utility and then take it into context of like your business to understand, well, if XYZ happens, what does that really mean for me? And that's kind of like where people struggle. So the AI is doing a pretty darn good job of like identifying these vulnerabilities. And I think the projects where like the firms are like sharing is that people can identify the vulnerabilities quicker. But I think there may be a disconnect with what the practical implications of these are in the real world.
And does that maybe just talk a little bit about that validation step from your side? How is it that you get from or maybe just help explain a little bit because people are bombarded by so much noise, right? And you say like things are hyped so much. So just like practically speaking, I'm bombarded by what like, you know, even today, right? There's like this PHP vulnerability.
I'm trying to use the right terms now, right? And it affects all of these. How do I then map that onto my situation from a business leader standpoint or a practitioner standpoint within a company? Like what principle wise should be at the top of my mind as I'm trying to parse through that noise to, well, should I really stop what I'm doing today and sit down and look at this more deeply? Can I put this on our backlog to investigate at some point?
Any practical tips on that side? Yeah, absolutely. I've been through this rodeo a few times where like a really big vulnerability comes out. And I was just knee deep in it like an hour ago trying to figure out like many people are. We're trying to figure out, you know, what are the constraints upon expectation?
Because that's what's really going to tip it into the barrier of people are going to be able to use it in the wild. Generally speaking, from my experience, you know, being around for like React to Shell and like Log4J and things like that, my gut feel is that the longer it's been out and it hasn't been confirmed to be overhyped is generally not a good sign that that tends to be people have. There are enough leads, there are enough variables in this that there could be cases where it could be bad. So it's very early to say, but my advice is on this one in particular, like I would take it seriously. I would definitely use the time period we have right now before that level research is published to go ahead and like patch your systems and things like that because so far it does not appear to be to be overhyped or still kind of in that gray area here.
Yeah. And I'm assuming that some of that like for example, in our own company, like we aren't PHP, like our stack isn't written in PHP. And I imagine some of that is just related to whether we use this system, we use this platform to to run our website and there's a content management, maybe they're using PHP under the hood. And so yeah, is that part of it judging like what you control internally and then what you don't control like from the from the vendor standpoint? Yeah, absolutely.
I think ideally organizations would have an idea for you know, how many different PHP applications like that like they are running, but you bring up a really good point from like the vendors of like PHP is gonna be running on like IoT devices and appliances and things like that. It's such such a popular language that there are going to be all these things. And when I was talking about the variables, the variables in the hardware and the builds and the operating systems that are running PHP are going to be much larger because you have all of these different appliances. PHP runs on multiple architectures like all the IoT space. In particular, you're gonna have all these different potentially older versions of things.
Things that happen regularly receiving patches are manufactured by a company that is no longer in business because this one really apparently affects actually like PHP 5. So it's very possible that there can be some of these and that's what makes it very, very difficult and is contributing to a lot of noise. It's crazy to think that we've been doing this podcast for about 375 plus episodes started back in 2018. I can think back to that time 2018 and it was intimidating to think about entering into this new craft, the podcasting, getting the website set up, getting marketing set up, email, etc. But I'm so happy that we at the time found the right people to make it happen, but it was a lot of work. What I love about what our partner Hostinger is doing with their AI builder is that you can go
from no website, email, marketing, etc. And then actually prompt their AI builder, their agents to help you create that website set up, whatever it is, manage it over time, SEO, website copy, email marketing that can all be included and driven by and through their AI builder. There's no coding or designer or developer needed. It's an all-in-one platform and I wish we would have had it back when we were launching the show. Plans start at just $3 a month and creating a website does not have to cost thousands of dollars. You can begin at your own pace and build from there. Hostinger builds your
vision step by step. Create your website today. Go to hostingor.com slash practical and use practical for 10% off now. That's hostingor.com slash practical and use code practical for 10% off now. So I'm curious as we've been kind of talking about AI starting to really have an impact on identifying vulnerabilities. You still have some of the same problems in terms of kind of categorizing
and determining the risk, near-term, longer-term. As you guys have adjusted this, can you talk a little bit about how your own team is implementing AI? What types of activities that using these different models, you know, you just enumerated some of them right before the break? How are they helping you? And what are the things that are still very much human in terms of what you're managing and stuff like that? How do you integrate in with the AI to be productive today? Which I guess is a
specific question of a more general thing that many of us are trying to find our way through in our jobs. I'd love to hear how it's affecting your team. Absolutely. It's been a, it's helped us a quicken our pace with a lot of things. So, Athloncheck, we actually utilize our open source Go exploit framework, which is really nice for this. So Go exploit is our modern exploitation framework
that handles a lot of the problems that we see our users running into with our vulnerability content kind of normalizes how you go through and handle the variances between checking for vulnerability, standing for it, validating targets, then of course, like running the exploit and setting up your C2. So having a structured framework like Go exploit is very helpful because when we're working with the LLM, it's not starting from scratch and we have a very large corpus of backlog of exploits growing every single day. I think he added, it was like 50 last week and Ron track to add like 60 this week. So there's quite a few. So having that that corpus and then the sort of the normalized structure that the framework of Go exploit provides kind of helps it seems to be providing it with like better results. And then from like a user's perspective, it helps kind of normalize that interface that
way we know how to interact with it without needing to necessarily worry about the details between the different exploits because the LLM and even the human authors as well aren't necessarily having to like build all the scaffolding by itself, which has been really helpful beyond that and beyond kind of Go exploit once you dive into like the real details of the vulnerabilities. The vulnerabilities fall under a certain vulnerability classes. And what we've noticed is that LLM seem to be pretty darn good at exploiting multiple vulnerability classes and not very good at exploiting other vulnerability classes. Everything kind of, well, not everything, but a lot of them fall kind into like one of those two buckets. So for example, we've had a lot of luck using AI and LLM to exploit open source web applications. So these types of flaws that are like logic flaws and how like token
logic is being handled or expression language injections or file leaks and things like that's pretty darn good with those. But when we start getting into anything that's close source where there's a layer of reverse engineering that has to happen ahead of time because it's like firmware or even like close source proprietary x86 software, those types of things would have to do like patch dipping. It tends to struggle a lot more. So those are kind of the two ends of the spectrum that we noticed. And I'm wondering you being on a team that's obviously looking at and developing exploits, and using AI-assisted methods to do that, there's a lot of things that we hear from not being in your position that I'm curious like how much of a problem they are in the sense that like for example with the OpenAI hugging face case, it talked about how the hugging face team, when we looked into that, they couldn't process all of these logs associated with what they were seeing back to OpenAI because they weren't in sovereign control of the OpenAI guardrails. So they were getting
blocked from doing certain things with that third party API. And so they hosted a version of GLM to do this analysis. And that's right. So that's just being one example. But I'm wondering about this concept of, hey, I'm a team, I'm actually developing an exploit or working in research from a positive perspective. I'm not a nation state actor trying to exploit something
maliciously, but I'm doing this for a positive purpose, for a legitimate reason. How are there ways that you're handcuffed now in terms of AI tools that you use? How do you navigate this sort of guardrailing aspect where you can use a tool openly to do things that are legitimate? But obviously, I understand being providing software myself as a company that I lead. I understand why a company wants to put in the appropriate guardrails and put in their own, especially if they're a SaaS provider and they're offering a managed platform. So how do you navigate
this as a team? And what are the real blockers that you see what's in bounds and out of bounds for you? Yeah, that's a really good question. So the guardrails are definitely a thing. So we try to navigate it first and foremost by following the formal processes with the companies to get into the cyber verification programs and things like that. We do do that.
The results aren't great. They don't really seem to change much of what we're able to do. I also have my own personal cloud subscription and I'm learning about exploit primitives and things like that. And then CTFs, so I kind of get a feel for what types of things. It's like, no, no, no, I know what you're doing. That's dangerous. And I compare that to
what it's at work. It doesn't really feel like it's doing much better. And it's talking to a lot of folks that have similar experiences. The trends in the guardrails definitely seem to have gotten more strict. If you talk to anyone in offensive security research, basically the answer is if you're using one of the American proprietary models, it's to downgrade it. That's the thing. So I'm kind of
worried about, I think, August 4.6 or 4.8, which is pretty darn effective. There's something to have been cliff in how helpful it's going to be after those versions are going to be sunset in February or something like that's coming up. So that's going to be interesting. A lot of shots I think are preempting that and they're moving towards local models. And even anthropic, I think a few weeks ago basically came out and said that they benchmarked GLM 5.3, which can be run locally, except that's open weight, was doing I think it was like 90% as good as some of their frontier models. And it was
released three or four months and they're framing it up like how it's so dangerous and everything. Which, yeah, that's great because we need to protect ourselves from people that aren't lobbying and aren't going to do this to help folks and my public research for people to defend themselves. But I think what's really difficult for a lot of these guardrail conversations is proving intent. But that's been a problem that we've had in the security industry for so long in general. You can pretty much talk any person in fact threat intelligence and a large part of what they're trying to do is like, well, they know the attack was run but it becomes much more difficult when after you've attributed it, you're trying to figure out what are they trying to do. Is this just for
political you've motivated, they're looking for money, that type of thing. So I'm curious, as you've kind of dived into some of the different model choices and stuff and I'm certainly coming from a person I work in the national security side of stuff and there seems to be kind of a choice if you're in security in the West in general about kind of dealing with these various guardrails on, you know, because there's a lot of legitimate work that is offensive and defensive both. And so you're dealing with guardrails on one side with American models, most super proprietary, but then on Chinese models, if you have that that's generally not allowed in national security context, but if you're in a larger security world, then is the concern about having things like poisoned weights and you know, the other other concerns, whether they are real or fabricated about Chinese models, how do you as a researcher out there doing this kind of work, how do you balance that of saying, well, there might be more trust as guardrails versus the what am I dealing with in the open source world from the East? So any thoughts about that?
Yeah, so a lot of folks are recommending GLM in particular GLM and Quan, someone was just telling me like, oh, like you should be using GLM yesterday and much kind of like, you know, like, I can't really share the data that I'm working on. I'm not working in the national security space. I can't share my data with anything else. So I see a lot of patients that are trying to pull them internally. I haven't actually heard of anyone expressing concern around like poisoned weights. In fact,
some people have even been talking about was obliterating. So like they're editing the weights themselves to make them even kind of like more dangerous. So I haven't heard anyone talk about this, but I would assume that they're looking at the weights and they're kind of like benchmarking based on that. They would probably find if the weights weren't already kind of bearing the direction they wanted to, because they're already in there looking to edit it. That would kind of be the same with like source code. If someone is going in and like
patching things, then like it's much more like they would identify if there was like an issue already embedded within it. I think a much more immediate concern would be like if you're using the host models yourself, because of course all the data is being shared up. I think there's been instances where one of the close source models was like uploading like all of the repositories and they ended up being found on like S3 bucket type of thing. And that's like what they've accidentally like shared and like published. But like you don't necessarily know what they're doing internally with them. And so from a researcher's perspective, especially when you're working on
these kind of like upcoming vulnerabilities, I think that the real question is like, are you comfortable sharing this information with who you're trying to get help from in terms of like the LLM? And so a lot of people just don't want to deal with it and they'll host themselves. I'm wondering just to kind of tie into some of the use of AI in exploit development. I was really intrigued by some of what Voln Check had published around and fake or AI generated POCs of exploits. And we can link this in our show notes. There's obviously like a lot. This is probably a few
hours or days conversation in and of itself. But I'm wondering if you could help us understand what is the idea of this? What does POC mean in this context? And why may this be like what sort of problem is this or what effect is it having maybe is it way to frame it? Absolutely. Yeah,
that's a great question. So when we're talking about like vulnerabilities kind of being like the theoretical flaw and the exploit being the real concrete implementation of it, POC is kind of like somewhere in between. You know, it gets to be a very area and some people use that term a little bit more interchangeably. Sometimes the POC is just going to cause a crash and that would validate the vulnerability and like a lot of people would take that seriously and they'll apply patches and fix it as they should and want to discount those efforts. But other times, sometimes POCs will be fully weaponized. They call it and actually like deliver payload that does something useful for an
attacker. So I'm not really sure about the motivations of a lot of people that are publishing the POCs. I think there's a huge variety of them. I think there are some that are just doing it for, you know, cloud and fame and glory. And I think other people are genuinely interested in learning and they want to share what they've learned. Other people have actually found the vulnerability. So we want to share a POC to
kind of prove their concept, which is great. That acronym of course comes from. So tying it back into a tevon check, one of the things that we do as part of initial access intelligence is we review all of the POCs that we can identify by CDEs across GitHub, Codeburg, GitLab and I think like a couple of other sources. So we look at all of them. We look at them every single day. So something like the PHP to shell one comes out. Basically, we have a subsection of
the team that's trying to work on the exploit ourselves while other people are going through what is out there in the wild and validating. Is this legitimate or not? Because our customers care about not only do we have it and can we provide it to our customers? We also care about what does the other guy have. So we're keeping a very close touch on the pulse of what is going on in the open source community.
I had alluded to the fragmentation of the distribution of security research over the past 10 years and GitHub has kind of contributed to that where what we're seeing is a lot of POCs are being dumped on GitHub. That's supposed to go into the old school, more centralized forums like X, Y, D, V and packet storm and things like that. I'll give you some of those. Most of them are going to get up because why wouldn't you unless Microsoft and your account because that's something that happens sometimes. So yeah, we are looking through all of those. We at Voncheck actually just hosted a threat
con one. It was our second threat con a couple of weeks ago. And one of my colleagues gave a talk about this analysis we do on all the open source public POCs and he shared something that was really, really interesting. We categorized them internally as whether or not we think they're like AI generated or not and whether or not they work. Removing the dimension of data about whether or not it was AI generated, what he pointed out was that with the increase in POCs that we're actually seeing, we saw a tipping point in 2026 where the average number of POCs that looked illegitimate for one reason or another, most often they're broken. They don't quite work or need our standards for doing
something worthwhile, tip to over 50%. So what we're seeing is that today, your average POC that you find is probably not what you're hoping it would be where it's actually going to truly leverage the vulnerability it says it does and prove some kind of attacker utility. This is so intriguing by you know, some of what you had mentioned around the the tipping point around POCs, how AI is obviously contributing to that or a portion of what's contributing to that. I'm wondering just to switch directions just slightly. There's how exploits are developed. Obviously you're on a team that's
looking at that. There's these POCs that are out there. I'm wondering about the kinds of vulnerabilities that may be net new or maybe they're the same as other vulnerabilities that we're seeing in the actual AI stack. So we have new things like whether that's agent harnesses, right? Whether that's cloud code, open-quaw, Hermes, etc. We've got obviously model serving frameworks have been around
quite a while. We have workflow development tools like DAG pipelines that you can build with AI tools and even some of these integrated into larger platforms like Workday or others like that where you can build these automations. I'm wondering in this kind of new realm of the AI stack, however, you define that, that these kind of net new things we're dealing with. Are there unique types of types of things that you all are considering as a part of these platforms that you didn't have to consider before? Or is it just sort of more of the same in terms of how these things can be exploited or vulnerabilities associated with them? So you're asking about vulnerabilities within like the AI
stacks, not how the AI stacks are being a library server. It's been kind of a lot of the same, I think. A lot of the newer ones that I've seen happen, they're almost always interpreted languages because by the nature of AI, I haven't been released within the past couple of years. You don't really see a lot of people writing AI code in like, for like these types of things that have a remote attack surface, you don't really see a lot of them being written in like C++ or even like a Rust. I'm sure they exist, but they're probably the lower level components that don't necessarily have a attack surface at a remote attacker would be interested in. And a remote attacker is what we're going to be focused on a
lot at VLmCheck and initial access, because that's that initial access component of it. So we look at a lot of like web interfaces on distribution frameworks and things like that. So we're seeing a lot of the same kind of vulnerability classes that we've seen in the past where there are like logic flaws, where files can be read, deserialization flaws, logic flaws, and how accounts are being registered and access controls. So there would be a really good overlap with a lot of the flaws that have been in the OS top 10, historically over the past 10 years, we're just starting to see them more and more in bulk. I'm curious. I'd like to actually flip it over to the other side of that equation and talk
about leveraging the AI stack in that way. And something that I have seen lots of are the notion of agent swarms. And we saw that clearly in the open AI hugging face attack. And I think that in certain areas, the notion of agent swarms are becoming more and more common. What, you know, any thoughts like what does that mean for the leverage of an exploit, aside from finding a vulnerability, let's say that you or potentially in, is it kind of a second half of that, or potentially using agent swarms to find vulnerabilities in real time that are then exploited in real time, which is to some degree, as I understand, it kind of what happened in that open AI situation.
Like how do you think about that as a researcher and how should we, us non-researchers, non-experts think about these possibilities as we are thinking about protecting our own organizations and stuff going forward? Yeah. I think there are a lot of similarities, actually, like in my mental model of how I think about it with like fuzz farms from like a long, a long time ago, in the sense that like, you know, it was a sailing problem where you have 100 nodes fuzzing Chrome or something like that, you're going to find presumably, you know, that many, that many more bugs. The similarities also kind of carry over into what I'm seeing a lot of research shops talk about is they're humbruing their own harness and their own prompts and things like that, because everyone kind of assumes much like they didn't fuzzing to use an off the shelf buzzer against the product that everyone else is fuzzing, like open a stage or something like that, you're probably going to find the same bugs. So people are assuming they use an off the shelf harness with the exact same model. There's more entropy going on there, but I think a lot of people are being
encouraged to kind of develop their own, which has been great. The similarities kind of end there because what we're seeing and how the industry is moving more in a quicker direction is that nowadays with like, you know, the AI's, it provides you with a better understanding because like once the vulnerability has been identified, it's kind of removing that first line of triage. Of course, it's varying degrees of quality depending on your controls and model and whatnot, but it's going to provide you with a good degree of analysis of is this exploitable? What is the bug class? How did we get here? That type of thing. I don't necessarily, like I haven't seen evidence that like full-on
wide-scale exploitation is where we're currently at, but having said that, I would be shocked if the answer isn't different in three to six months because these things are just like constantly going on. That's like what's really interesting about all this is like anything I say now is probably going to be how to hate it and like really needs to be taken into consideration in a couple of months. Thanks for the best. Absolutely astronomical pace. So yeah, I think the agents are really helping with the analysis capabilities and like they can even like build the POCs to be able to go back and like retrigger the flaw, which are all like leaps and bounds, what we used to have to do manually. And so it's really speeding that up. And then in certain cases, kind of going back to the
vulnerability classes that's really good at exploiting, we can get it to the point where it will create a POC or fully weaponized exploit that we consider meets our quality, but it's not quite reliably there for certain classes. Yeah, that was going to be my follow up is just clarifying. So if I'm understanding right, are you saying, because you had talked about these classes of vulnerabilities previously, and AI is doing really good on certain of those categories. And so as the fact that if I'm understanding right, AI found vulnerabilities aren't necessarily exploited at higher rates or with higher impact than human found ones at this point, or is that true or not true? And is that partially related to this fact that AI models are really good at only certain of these classes and haven't quite made the progress with the other ones? Yes, I would say that say that today AI is not as reliable at
exploiting them with the same impact as humans, because humans, first of all, they're going to be motivated for looking at the vulnerabilities. There are people out there that look for vulnerabilities just for funsies, but by and large, a lot of people have some kind of motivation, they need to look at particular application because they want to know like can an attacker get in or something like that, and they have additional context in terms of what the impact would be, and they kind of use that as a point that they want to get to. It's almost always going to be like code execution. And so I tend to see a lot of the more human curated exploits that have been developed are much more mature in their utility for what a real world user could use, whereas in my experience, a lot of the AI exploits will kind of drop it as like this is a crash that's theoretically exploitable, and you kind of try to push it. It might veer off in and go in a different direction that's not quite as beneficial for a human operator. Yeah, so maybe if I'm kind of merging two of the things together,
if I'm understanding your points correctly, you could have let's say a team of agent researchers that are like you're saying, almost acting in that fuzzing sort of capability, maybe even if you have your own harness, that's doing it in a unique way. And so you have this very wide set of things that agents are looking at, and they, you know, maybe to be most effective in your role, you could use that capability to then identify things and filter them down to human experts, to maybe increase the utility of the exploit or the impact, et cetera, and you know, prove out the POC, make sure it's not broken. That sort of thing, would I be understanding that right? If I'm like, let's say for those out there that are maybe in the research space or interested in the research space and want to use AI in a useful way, would that be kind of roughly a reasonable way to think about it? Yeah, absolutely. It's kind of boiling that information down until it's like a
high level of like, you know, what's the point really has been identified and you know how to trigger it. And like, you know, the AI might even know like a little bit about like what you can do with it. It just just certain classes, it kind of struggles with getting to the point of like, what can you do with it? What does attacker want? And then that intersection there. So as we start
kind of winding up here, it's been a fascinating conversation. It's really, really interesting. And there's, I guess, I, one of the things that we tend to do at the end is we kind of ask people to wax poetic a little bit about what you're thinking is, it's kind of like the going to bed at night and you're thinking kind of freely, you know, taking the shower, your brain goes wherever you want that kind of stuff. Can you talk a bit about where you think things are going to go? And you can choose whatever timeframe you want that love. Like, if all of us are getting a glimpse into the mind
of you as a security researcher, when you're kind of free association, you know, thinking, where does that go? What does that look like? What does your future look like that you're anticipating and preparing for? And of the things you may be thinking about, like, what is, what do you think is super cool, you know, and then stuff? I just love to kind of finish off that way.
Yeah, yeah. I mean, I'm pretty optimistic about things that are coming up because things are getting faster and better, of course. But what that has meant for me as a researcher that's, you know, trying to try to help people and try to produce information to allow them to make better in more informed decisions, speed is really important. A long time ago, you know, attackers don't play by the rules, that's the definition of it. So they would have this advantage where they can spend an undetermined amount of time to develop a vulnerability and they can release it by using it and harming people.
And so there'd be this window where it's actively being used and people that are trying to like patch it and defend against it or having a harder time, like understanding it. And so like, one of the things that we're seeing is that we're able to run through that process a lot more quickly. So we are reducing the value kind of that they're getting out of all that effort, which I think is a real good thing. We're able to react much more quickly when there is a variable or a new vulnerability that that comes out. So that's been really great. I'm curious to see on the less technical side,
some of the legal implications of some of these things. One of the things I really want to know about I'm genuinely curious is kind of as you read about these texts that take place in the news, where like someone asked Claude to do X, Y, and Z and in order to do X, Y, and Z it owned this website or something like that. I think I was reading an article where someone wanted to get into a spin class and Claude like actually like a SQL injection vulnerability to like bump him to top of the queue, which is like not great. But like I'm really curious to kind of know where the question is kind of be set in terms of like who's responsible for like the types of breaches, because like I think we all kind of have our opinions, but like I want to see like how it actually shakes out in the courts. Well, hopefully some vulnerabilities can give me back in my exercise routine.
I need a little bit of help there. But yeah, that's awesome Spencer. Thank you. Thank you for taking time to chat with us on a very eventful day in the world that we live in and the cyber world. So yeah, appreciate it. And we encourage everyone to check out what Volm Check is doing. We'll put
some links in the show notes. Just amazing work. Thank you so much, Spencer. Absolutely. Thank you for having me. All right. That's our show for this week. If you haven't checked out our website,
head to practicalai.fm and be sure to connect with us on LinkedIn, X or Blue Sky. You'll see us posting insights related to the latest AI developments. And we would love for you to join the conversation. Thanks to our partner, Prediction Guard, for providing operational support for the show. Check them out at predictionguard.com. Also, thanks to Breakmaster Cylinder for the beats
and to you for listening. That's all for now. But you'll hear from us again next week.