エクスプロイト開発、エージェントによる脆弱性発見、そして偽PoCの実態

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, on to the show. Welcome to another episode of the Practical AI Podcast. This is Daniel Whitenack. I am CEO at Prediction Guard, and I'm joined as always by my co-host, Chris Benson, who is a principal AI and autonomy research engineer. How are you doing, Chris? Hey, doing great. Going, going, going. How's it going? Going, going, going. I mean, Chris, it seems like every day we're hearing about something like this, but today also was a doozy, I guess.

You know, I saw Wall Street Journal articles saying, you know, AI discovered exploit that affects 70% of the web, right? This is happening, I guess, as we're recording this, October 21st. So we're hearing about this all the time. And it conveniently happened that we had scheduled to talk with us today on the podcast, the Director of Exploit Development at Volncheck, Spencer McIntyre. Welcome, Spencer. Hi, yeah. Thank you for having me. Yeah, definitely. Well, I know, you 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. I'm 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, you know, a little bit about your background, how you fit into this world? People might find the director of exploit development title rather interesting. So just to help orient us kind of where do you fit within this world? What are you doing right now with Volncheck, that sort of thing? Yeah, absolutely. I was really excited when they offered me the title of director of exploit development. Pretty awesome. I thought that was pretty cool. Yeah, I've always been really, really passionate about exploits. And so that's kind of actually how I got into the information security industry. So my background kind of 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 of O days really to get a job as a pen tester, 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 is really has been my focus over the past 10 years. Some of that overlapped with research and development in consulting, which was really interesting. So 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, bunch of different things. But then, yeah, I slowly kind of transitioned over to working in research and development full time. I have an extensive background in the Metasploit framework doing module development and things like that. Metasploit was kind of a big part of it. I'm kind on my journey of doing exploit development that brought me to Volncheck, where, as you mentioned, I'm the director of exploit 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 Full Check. 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. It started back in 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, the way we're doing things, the advent of AI, and completely altering our workflows in the past few years, which I'm sure we'll talk about quite extensively, has kind of shifted how

things have operated and how vulnerability researchers have approached a lot of these problems. And also, we've seen the trend 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 speed that VulnCheck 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. And 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 kind of like 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 used some words there. you mentioned, you know, the exploit isn't the only thing. Like when events happen like is happening in today's, you know, news cycle, could you help orient people, you know, what

defines an exploit? Like 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. So I think you had actually mentioned earlier that like an exploit was discovered and I want to have my like, well, actually card. Yeah, yeah. Please do. That's what we need. Consider me the noob and learning along with you. Yeah, there's nuance in the term that I'm really passionate about because even in like Metasploit, there are different contexts or when you're talking from a consulting perspective or something like that, people use the phrases differently. So being around for a while, You kind of understand like what people people mean. But for a vulnerability is basically the potential for something bad to happen. And if you really dive into a lot of vulnerability research, vulnerabilities have to be 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 actor 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 that's 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 to kind of tie in. I've used Metasploit in the past 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 Mythos, developing, you know, all sorts of insights into vulnerabilities and identifying those and stuff like that. How, like, can you, 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 has 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. And 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 Mythos Access myself, have experience with 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 that I'd really like to mention because a lot of the AI models, whether it's MISOs or Opus 5.5 or what have you, or, you know, the open AI 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, you know, this is bad, this byte 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 we're kind of missing that gap between the validation and the actual functional exploit that proves attacker utility. and that attacker utility is what something even a legitimate pen tester or like a law-buying citizen would really need to understand because there are so many of these vulnerabilities. As you were mentioning, there are like big ones that came out today. So people are often struggling with is the prioritization. CVSS is only going to get you so far when there's 20 CVSS, you know, nine and above. 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 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 from your side How how how is it that you get from or maybe maybe just help explain a little bit because people are bombarded by so much noise. Right. And you say like things and things are hyped so much. So just like practically speaking, I'm bombarded by 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 it out like many people are. We're trying to figure out, you know, what are the constraints upon exploitation 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 to like Reactive Shell and like Log4J and things like that, But 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 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 of research is published to go ahead and, like, patch your systems and things like that.

Because so far, it does not appear to be overhyped. But we're 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 run our website and there's a content management platform. 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 vendor standpoint? Yeah, absolutely. I think ideally organizations would have an idea for, you know, how many different PHP applications that, like, they are running. But you bring up a really good point from, like, the vendors that, like, PHP is going to be running on, like, IoT devices and appliances and things like that. It's 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 going to have all these different potentially older versions of things, things that haven't been regularly receiving patches or were manufactured by a company that is no longer in business because this vulnerability apparently affects that to like PHP 5. So it's very possible that there's going to 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, et cetera, 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 hostinger.com slash practical and use practical for 10% off now.

That's hostinger.com slash practical and use code practical for 10% off now. So I'm curious as we've been kind of talking about, you know, 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, you know, near term, longer term. As you guys have adjusted to this, could 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, a more general thing that many of us are trying to find our way through in our jobs. So I'd love to hear how it's affecting your team.

Absolutely. It has helped us quicken our pace with a lot of things. So at Vulturec, we actually utilize our open source GoExploit framework, which is really nice for this. So GoExploit is our modern exploitation framework that handles a lot of the problems that we see our users running into with our vulnerability content. It kind of normalizes how you go through and handle the variances between checking for a vulnerability, scanning for it, validating targets. Then, of course, like running the exploit, setting up your C2. So having a structured framework like GoExploit 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 a backlog of exploits. It's growing every single day. I think we added, I think it was like 50 last week, and we're on track to add like 60 this week. So there's quite a few. So having that corpus and then the sort of the normalized structure that the framework of GoExploit 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 LOM and even, you know, 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, vulnerabilities fall under certain vulnerability classes. And what we've noticed is that LLMs 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 of into like one of those two buckets. So, for example, we've had a lot of luck using AI and LLMs 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 closed source, where there's a layer of reverse engineering that has to happen ahead of time because it's like firmware or, you know, even like closed source proprietary x86 software, those types of things where it has to do like patch diffing, it tends to struggle a lot more. So those are kind of the two ends of the spectrum that we've noticed. And I'm wondering, you being on a team that's obviously looking at and developing exploits, you know, and using AI-assisted methods to do that, there's a lot of things that we hear, you know, 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, you know, when we looked into that, they couldn't, you know, process all of these logs associated with what they were seeing back to open AI because they weren't in sovereign control of the open AI guardrails, right?

So they were getting blocked from doing certain things with that, you know, third-party API. And so they hosted a version of GLM to do this analysis and that sort of – so that 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. Right. 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 the tools that you use? How do you navigate this sort of guard railing aspect where you can use a tool openly to do things that are legitimate? But, you know, obviously, I understand being, you know, providing software or, you know, myself as the 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.

Right. So how do you navigate this as a team and what are the real blockers that you see? What's inbound 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, like 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, like, I have my own personal, like, cloud subscription, and I'm, like, learning about, like, particular exploit primitives and things like that and then, like, CTFs. So I kind of get a feel for like what types of things is going to be like no no no I know what you doing That dangerous And I compare that to like what is at work I like there not really it doesn really feel like it doing much better And in talking to a lot of folks they had 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, Opus 4.6 or 4.8, which is pretty darn effective. There seems to have been a cliff in how helpful it's going to be after those versions are going to be sunset in like February or something like that's coming up. So that's going to be interesting. A lot of shops, 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 benchmark GLM 5.3, which can be run locally, except that's open weight. was doing, I think it was like 90% as good as like some of their frontier models. And it was released like three or four months. And they were framing it of like how it's so dangerous and everything, which like, yeah, that's great because, you know, we need to protect ourselves from like people that like aren't, you know, law-abiding and aren't going to do this to like help folks and like publish research for people to defend themselves. But I think what's really difficult for a lot of these guardrail conversations

is proving intent. But, I mean, like, that's been a problem that we've had in the security industry for so long in general. Like, you can pretty much talk to any, like, person in threat intelligence, and, like, a large part of, like, 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, like, what are they trying to do? Is this just for, like, you know, politically 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, you know, 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, you know, 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, mostly 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 by 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 QAN. Someone was just telling me, like, oh, like, you should be using GLM yesterday. And much kind of like you, I'm like, no, like I can't really I can't really share the data that I'm working on. I'm not working in the national security space, but I can't I can't share my data with with anything else. So I see a lot of patients that are trying to to pull them internally. I haven't actually heard of anyone expressing concern around like poison weights. In fact, some people have even been talking about 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 veering the drugs that they wanted to, because they're already in there looking to edit it. That would kind of be the same with like source code. Like if someone is going in and like patching things, then like it's much more likely 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 and models yourself, because of course all the data is being shared up. I think there's been instances where one of the closed source models was like uploading like all of the repositories and they ended up being found on like an S3 bucket type of a thing. And that's like what they 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 up and coming vulnerabilities, I think that the real question is like, are you comfortable sharing this information with, you know, 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 it themselves. I'm wondering just to kind of tie in to some of the use of of AI in exploit development. I was really intrigued by some of what Volncheck had published around 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 few hours or days conversation in and of itself. But I'm wondering if you could help us understand what 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 a way to frame it. Absolutely. That's a great question. So when we're talking about like vulnerabilities kind of, you know, being like the theoretical flaw and the exploit being the real concrete, implementation of it. A POC is kind of like somewhere in between. You know, it gets to be a

gray area. Some people use that term a little bit more interchangeably. Sometimes a POC is just going to cause a crash and that would validate the vulnerability. And like I said, a lot of people will take that seriously and they'll apply patches and fix it as they should. I don't want to discount those efforts. But other times, sometimes POCs will be fully weaponized, they call it, and actually deliver a 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 clout 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 vulnerabilities, so they want to share a POC to kind of prove their concept, which is where that acronym, of course, comes from. So tying it back into VulmCheck, 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? They also care about what does the other guy have? And 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 like 10 years. And GitHub has kind of like contributed to that where what we're seeing is a lot of POCs are being dumped onto GitHub as opposed to going to the old school, more centralized forums like ExploitDB and PacketStorm and things like that. Like you can still find those. Most of us are just putting them up on GitHub because why wouldn't you unless Microsoft bans your account? Because that's a thing that happens sometimes. But so, yeah, we are looking through all of those. We at VolmCheck actually just hosted ThreatCon 1.

It was our second ThreatCon a couple of weeks ago. And one of my colleagues gave a talk about this analysis we do on all of the open source public POCs. And he shared something I thought was really, really interesting. We categorized them internally as like 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 she 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 look illegitimate for one reason or another, most often they're broken. They don't quite work or like meet our standards for, you know, like doing something worthwhile, tipped to over 50%. So what we're seeing is that today, your average POC that you find, it's 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 this 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, you know, 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 just 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 Claude Code, OpenClaw, Hermes, et cetera. 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, 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 how these things can be 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 leveraged for vulnerability. Okay. Okay. It's been kind of a lot of the same, I think. A lot of the newer ones that I've seen have been, they're almost always interpreted languages because by the nature of AI having been released within the past couple of years, you don't really see a lot of people writing AI code for these types of things that have a remote attack surface. You don't really see a lot of them being written in like C, C++, or even like Rust. I'm sure they exist, but they're probably the lower level components that don't necessarily have an attack surface that a remote attacker would be interested in. And a remote attacker is what we're going to be focused on a lot at phone checking initial access because that's that initial access component of it.

So we look at a lot of like web interfaces, distribution frameworks, and things like that. So we seeing a lot of the same kind of vulnerability classes that we 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 OWASP top 10 Historically over the past 10 years we just starting to see them 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, you know, 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 is 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 time ago, in the sense that like, you know, it was a scaling problem where you have 100 nodes fuzzing Chrome or something like that. You're going to find presumably, you know, 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 homebrewing their own harness and their own prompts and things like that because everyone kind of assumes, much like they did in fuzzing, if you use an off-the-shelf fuzzer against the product that everyone else is fuzzing, like OpenSH 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 the AIs, it provides you with a better understanding because 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 of this is like anything I say now is probably going to be outdated and like really needs to be taken into consideration in a couple of months. Things are moving fast. Absolutely. Astronomical pace. So, yeah, I think the agents are really helping with the analysis capabilities. and they can even build the POCs to be able to go back and re-trigger the flaw, which are all 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 a fully weaponized exploit that we would consider meets our bar for 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, right? And AI is doing really good on certain of those categories.

And so is the fact that if I'm understanding right, you know, 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 it's safe to 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 a motivation. They need to look at a 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 like what the impact would be. And they kind of use that as a point that they want to get to.

Almost always can be like code execution. And so I tend to see like 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 craft, just theoretically exploitable. And then you kind of try to push it. You know, it might veer off and go in a different direction that's not quite as beneficial for what a human operator would need. 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 agentic researchers that are, like you were 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 the 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 to maybe increase the utility of the exploit or the impact, etc. And, you know, or prove out the POC and make sure it's not broken, that 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 gets to like the high levels. Like, you know, once the vulnerability has been identified and you know how to trigger it. and the AI might even know a little bit about what you can do with it. Just certain classes, it kind of struggles with getting to the point of 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 I guess 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 your 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 time frame you want, but I'd 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, what is, what do you think is super cool, you know, and stuff? I just love to, to kind of finish off that

way. Yeah. Yeah. I mean, I'm pretty optimistic, 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 trying to help people and trying to produce information to allow them to make better and more informed decisions, speed is really important. A long time ago, 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 would be this window where it's actively being used, and people that are trying to like patch it and defend against it are 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 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 attacks 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 exploited a SQL injection vulnerability to bump him to the top of the queue. Not great, but I'm really curious to know where the precedence is set in terms of who's responsible for the types of breaches. Because I think we all have our opinions, but I want to see how it actually shakes out in the courts. Well, hopefully some vulnerabilities can get me back in my exercise routine. I need a little bit of help there. But yeah, that's awesome, Spencer. 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 Bulncheck 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. Thank you.