Harry Wetherald: [00:00:00] We look at the cost, and when we extrapolated up to their whole environment, it was gonna be $4 million a week.

Ashish Rajan: I still remember the two people team that I had in one of the organizations, entire job that they had was the entire time going through every alert that has come in from a SaaS tool, SCA tool.

Harry Wetherald: The old school of SCA and SaaS would give you nine false positives out of the ten, at least. They give very confident, but sometimes wrong results, 'cause they'll go very deep in an investigation and take one wrong turn along the way, and then give you the wrong answers.

Ashish Rajan: They found a vulnerability which was 27 year old or something.

Ashish Rajan: I think the cost of finding that was $10,000. Yeah.

Harry Wetherald: If you're talking to an, like, AI-based product and it looks like a black box and it's not telling you in really clear detail what it's doing, I would run a mile. We no longer need to have these wall gardens where you have these very, very separate tools and very separate teams.

Harry Wetherald: The way I see it is we need a sort of security brain that sits behind the coding agent.

Ashish Rajan: Security teams have started using AI for security, which is for cloud, which is for code, which is for AI SOC. A lot of times we don't know the questions we should be asking to identify red flags, especially if it's an AI native company versus an AI bolted company, especially when it comes to AppSec, [00:01:00] which has been known to have a lot of false positives.

Ashish Rajan: For this particular conversation, I had Harry Wetherald, who is the CEO and co-founder of a company called Maze, and we spoke about the evolution of how AI is being used by companies to solve cloud security problems, AppSec problems. What's the reality of having a native AI AppSec program? What you could be doing, uh, differently if you are already running an AppSec program, and how can you bridge the gap between code and cloud?

Ashish Rajan: A lot more in this conversation with Harry. As always, if you are here for a second or third time and have been enjoying the episodes, I would really appreciate if you take a quick second to drop the follow or subscribe button, whichever podcast platform you're listening or watching this on. We are on Apple, Spotify, YouTube, and LinkedIn, and anywhere else you consume your podcasts from.

Ashish Rajan: Shout out to Maze who sponsors this episode of Cloud Security Podcast. Um, I hope you enjoy this episode. I'll talk to you soon. Peace. Hello, welcome to another episode. I've got Harry with me. Hey, man, thanks for coming on the show.

Harry Wetherald: Thanks for having me back.

Ashish Rajan: It's always a pleasure, especially when we're talking about reachability and exploitability.

Ashish Rajan: Uh, but maybe to start off, if you could just share a bit about yourself and [00:02:00] where you are today.

Harry Wetherald: Yeah. So I'm Harry. I'm the co-founder and CEO of, uh, of Maze. We're a Series A security startup founded two years ago. We've been... We've spent the last two years basically building out the infrastructure to build AI agents for security.

Ashish Rajan: I think, uh, something that keeps coming up in all the conversations that I have is about reachability and exploitability.

Harry Wetherald: Mm-hmm.

Ashish Rajan: And it's, it's, I don't know if it's confusing is the right word for it, but it definitely is misunderstood.

Harry Wetherald: Yeah.

Ashish Rajan: And maybe that's a good place to start, because a lot of people who may be from a cloud background, from an app sec background, how do you differentiate the two? Because, uh, people just think isn't that just vulnerability? Why is that different?

Harry Wetherald: Yeah. Yeah, so they can be used in different ways, right?

Ashish Rajan: Yeah.

Harry Wetherald: And you actually see them used in different spa- uh, different ways in cloud and application security, but if you strip them back to their core meaning, you kind of have a easier way to understand things. So, reachable basically means can the attacker at least get to the vulnerability, right? And that means different things in, in cloud and code.

Harry Wetherald: In cloud, people often use it to mean is it possible for them to reach it from the network, right? Mm-hmm. And that means different things. It's not as simple as just saying the asset is exposed to the network. [00:03:00]It's more subtle than that. It's a little bit more to do with the actual vulnerability itself.

Harry Wetherald: And in code, they typically mean is the function, uh, reachable. So is that code actually active pretty much is what that means, or is the code just dead code that happens to be in the application. If it's dead code that isn't used anywhere in the application, then of course the attacker can't use it to exploit anything.

Harry Wetherald: If it's active, all it means is it might be possible to be used to exploit something, and that's really like the key word around reachable, which is reachable just gives you a sense that this might be exploitable. There is then a series of steps that if I was a human looking at a vulnerability, I'm gonna do next to understand if the vulnerability actually is exploitable.

Harry Wetherald: Mm-hmm. So in the code example, is the code actively used, yes or no? Gives you, like we'll filter out a good chunk of, of vulnerabilities. But next is, okay, logically can the attacker actually exploit this? It's one thing for the code to be active, but can I actually pass the kind of request into the application that's gonna trigger the vulnerability, yes or no?

Harry Wetherald: In a lot of cases, for example, the kind of request I need to be able to trigger just isn't possible for some kind of reason, some kind of input sanitization or other control around the application that blocks [00:04:00] me from being able to do it.

Ashish Rajan: Yeah.

Harry Wetherald: So that difference really is a difference between reachable, but is the code alive i, in the simplest terms?

Harry Wetherald: And exploitable is, is all the context kind of there for the attacker to actually be able to trigger the specific vulnerability? And that's the big change that we're able to do now with AI, is go from really more like blunt force measures, is the code there, can I, can I reach the asset, these kind of things, to looking at all the context around it, can it be exploited, yes or no?

Harry Wetherald: Which is, which is what we've been doing for the last couple years.

Ashish Rajan: So now that people are... Obviously I was gonna talk about the like the frontier models have started releasing security products as well now, and I think- Maybe in the last cl- last time we had the conversation, we were c- still talking about whether people would choose to build.

Ashish Rajan: I feel like now the, the needle is more towards, "Oh, we wanna buy this." How far is it possible for teams to use AI to go between your cloud and code? Uh, how much is, uh, is reality and how much of it is hype today? Yeah. Especially now that there've been so many more models that have come in.

Harry Wetherald: Yeah.

Ashish Rajan: I feel like, I'm sure there's a model being released right now as you're talking as well.

Harry Wetherald: Yeah, yeah. So it's, it's possible [00:05:00] obviously. I'd say a lot of our customers have actually been building first before they came to us.

Ashish Rajan: Yeah.

Harry Wetherald: So they've kind of been building, understanding the problem better, understanding what's possible, and then hitting some kind of wall, and then coming to us to work with us, which, which we always like.

Harry Wetherald: The challenge with building with these LLMs is at first you think it's gonna be easier because you get so much power out the box.

Ashish Rajan: Mm-hmm.

Harry Wetherald: Right? You plug into this API and it gives you so much power, right? Like, you know, it's magic genie in a box to do all these things with. The problem is that it gives you so much power.

Harry Wetherald: And so the degrees of freedom really around what you can do with that power are so great that it means that the difference between someone that spends years perfe- perfecting a system and someone that spends, you know, one or two internal people one to two months perfecting a system, you're gonna get drastically different results.

Harry Wetherald: Actually, bigger difference between that and a more traditional software product where there is less that you can change and tweak. And what that looks like specifically is when you start building it yourself with, with AI, and what a lot of people come to us and, and mention that they've seen is it's really hard to know if it's right or not.

Harry Wetherald: Because if I'm doing this really [00:06:00] deep, like, 20, 30, 40 step investigation into a vulnerability, let's say in a, in a code base or in a, in a cloud environment, there's so much complexity there. It's gonna take me an hour or two to validate whether it's got the answer right or not. Now, if I'm building something kinda turn int- internal tooling, I need to be constantly knowing if it's got the answer right or not.

Harry Wetherald: So next thing, next thing I need to go and build some kinda like monitoring and validation that sits on top of my internal tool. And then once I've done that, great, well, I might as well start using that data somehow to start reinforcing and training the agents to get more and more accurate. And then once I've done that, well, the LLMs cost a lot, right?

Harry Wetherald: Yeah. And so there's a lot of optimization that you can put in to actually improve their cost efficiency, so get the same accuracy at lower cost.

Ashish Rajan: Yeah.

Harry Wetherald: And then once you've done that, you think, "Well, now that I've got this kinda much more complex system, maybe I could experiment with using different models for different things."

Harry Wetherald: And you keep working through all these steps, and suddenly you've got a very long backlog of things that could drastically improve the performance of your system. And what a lot of people come to us and say is, "Look, I, I built something in-house. I could see the potential of it. But running it across every PR in my environment or every cloud asset in my environment [00:07:00] would cost me tens of millions of dollars a year to do it at the level that I want to do, do it at.

Harry Wetherald: And I don't even know if it's accurate every time." And so companies like us kinda specialize in nailing that question. Can you make it- ... much, much, much more reliable than the out-of-the-box models? And can you make it not just, you know, half as cheap, but 100 times more cost efficient? And then you can play with those two variables until you get a much better product at the end of the day.

Ashish Rajan: Is it different between using AI to solve security problems between AppSec and co- cloud?

Harry Wetherald: Yeah, different in places. Obviously, the, the models are... The thing that they're increasingly being trained on more than anything is code, right? Yeah. And understanding code. So they're almost a little bit more natural there, you know?

Harry Wetherald: Yeah, yeah. Um, naturally skilled there. But the challenges remain similar in that in, in both cases if I just say, "Hey, Mythos or Fable, uh, or, or Opus, something, here is my PR." Please check it for vulnerabilities. Uh, the things the optimal thing that happens next is not just that you look at that single snapshot of code.

Harry Wetherald: The optimal thing is that you go and trace a bunch of [00:08:00] different kind of piece of data across. You understand this piece of code, the rest of the application, all the different business logic flows through an application, where the application might be hosted in the cloud, what that cloud is configured like, what controls might be around it- Yeah

Harry Wetherald: what the context of the company might be like, et cetera, et cetera, et cetera. So whilst the core code understanding is better in the models, the optimum way of you doing code security is not just understanding snippets of code, right? It's understanding applications and reasoning across an application, and the cloud that it, it exists in, or the other infrastructure that it exists in.

Harry Wetherald: And so, uh, what we've found as we've transitioned from cloud to code is some things have got easier, right? Like, the core domain knowledge is a little bit better.

Ashish Rajan: Right.

Harry Wetherald: But the kinda mapping of all the different things you want to know is actually in some places even more complex, so it kinda balances itself out.

Ashish Rajan: 'Cause I guess to what you're hinting towards and what the message that I'm taking away also is the fact that 'cause traditionally, AppSec team is separate, cloud security- Yeah ... team is separate. They don't really... I mean, they don't, they kinda talk to each other, but not always.

Harry Wetherald: Yeah.

Ashish Rajan: How does AI kind of break that barrier- Yeah

Ashish Rajan: and why is that even [00:09:00] required?

Harry Wetherald: Yeah. Why, why did we do it that way? Yeah. Is, is one good question, right?

Ashish Rajan: Yeah.

Harry Wetherald: So yeah, what we see is, like, oftentimes you have one leader, and then you have two kinda managers, and then the two teams work very closely together is the most common setup in, like, the size of company- Yeah we tend to work with. Um, and I do think it makes some sense that it works that way. But when you think about it, a lot the issues are often the exact same thing. And it's not just like there's relationships between them. Like, they are literally the same vulnerability in a lot of cases, and two different teams are dealing with it separately.

Harry Wetherald: And in other cases they are different but related issues, right, that each team, uh, cares about. So- I think the reason why we've done it that way historically have been partly to do with the tools, and partly the reason for that is if I'm building an AppSec tool in 2020 or 2015 or before, I need to build regex basically to understand every s- potential risk in a coding language, right?

Harry Wetherald: I need to build a bunch of logical rules that, that look for bad syntax and find me a risk, or look for a CVE and find me a risk. I need to do that for Java, and I need to do it for Python, and I need to do it for, you know, C++, and I need to keep going and going and going, going. And by the time [00:10:00] I've built all those things out, I'm pretty worn out, right?

Harry Wetherald: Yeah. I'm not going and building a whole cloud security product as well and understanding how all the-- and building all the logic to fit it together. Mm-hmm. Same on the cloud side. By the time I've built my logic libraries and rule libraries and understood all the cloud context, it's gonna be slow for me to go into code, although some have, like, ways, et cetera.

Harry Wetherald: But what changes now with LLMs is LLMs almost acts as like your translator, right? So you, you have a, you know, someone speaking English on one side and someone speaking Spanish on, on the other side, and you have this system that can perfectly translate between the two.

Ashish Rajan: Yeah.

Harry Wetherald: So we no longer need to have these wall gardens where you have these very, very separate tools and very separate teams.

Harry Wetherald: We can kind of perfectly kind of understand how a risk in one place corresponds to a risk in the other, how context from one place impacts context in another, and overall, we should start bringing those worlds much, much closer together. We shouldn't be sat here in five years' time and going, our AppSec and our cloud security program runs completely separately."

Harry Wetherald: They should be kind of pretty unified.

Ashish Rajan: And do you feel... Well, I would-- Well, I, I guess I was gonna say, because found the frontier models have started coming up with security products as well. I [00:11:00] think Claude has, uh, I think they have, like, the-- they have Glasswing, and OpenAI has the Day, the Daybreak, I think they call it.

Ashish Rajan: They have security programs coming up. They're obviously releasing... There's almost... is it a good thing or a bad thing in terms of both sides now have access to a powerful model? Well, whenever Fable 5 comes online, uh, I mean, I guess 5.5, 5.6 is there as well. But is there, in terms of... Because AppSec was always that, "Hey, we care about pen testing."

Ashish Rajan: Cloud was almost like the bottom tier. And like, well, if you get to it- Yeah ... we'll have some kind of solution to look at the configuration. I feel like is there a difference in messaging in terms of now that if people are using, say, their own, uh, what's the word for it? If I use a cloud security product Should I already-- Should I replace that my SCA and SAST with?

Harry Wetherald: Yeah.

Ashish Rajan: Or should I still have... Because I already have SCA, SAST. It's not that I did not have that before. Yeah. How are you approaching that with, I guess, is it better for people [00:12:00] to, how should they think about an AppSec program in an AI native world? That's kind of where I'm going with this- Yeah, yeah

Ashish Rajan: basically. That's kind of where... Because now I have a choice, so I already have an SCA and SAST. I also have providers at the frontier model giving me a security solution.

Harry Wetherald: Yeah.

Ashish Rajan: How do I signal-- I mean, I give the signal from the noise. How do I differentiate that- Yeah ... as a leader?

Harry Wetherald: I think there's a few ways to look at that.

Harry Wetherald: The first one would be: How did you decide about these tools like this in the past?

Harry Wetherald: Because it's not new that our kind of engineering tools or IT tools or general productivity tools off- also offer security, right? Think about Google, Microsoft, Amazon, Datadog, et cetera. They've always kind of seen these opportunities to offer somewhat good security products on top of their existing solutions.

Ashish Rajan: Yeah.

Harry Wetherald: Uh, for me, it doesn't-- nothing changes that drastically here. Like, what we've seen from Claude Code Security and from other, the Google and, and OpenAI equivalents is when you test them, they're far inferior to the more domain-specific tools that people have spent a year, two years honing, refining, training, et cetera.

Ashish Rajan: Yeah. '

Harry Wetherald: Cause they're side projects really for these big [00:13:00]labs. And so for me, it's like similar analogy to would you have chosen a Google or Microsoft product in the past? For a lot of people, the answer might be yes, right? Mm. Like, that was good enough for this use case. And the s- the same answer might be true in this case.

Harry Wetherald: If instead you say, "No, this is a really strategic part of our program. We don't want to lock into one lab," for example. "We want to be a, we wanna have a product that orchestrates across lots of different models for us. We wanna get much higher accuracy." And what's interesting in this case is the Googles and the Microsoft always used to be cheaper, right?

Harry Wetherald: Mm-hmm. It was, like, typically cheaper for you just to go and buy, you know, Microsoft Defender or- Yeah ... or something like that. In this case, because of the way the lab's incentive structure is set up to sell more tokens, Claude Code Security is not just tested to be inferior to kinda custom-made products.

Harry Wetherald: It's also a lot more expensive typically.

Ashish Rajan: Oh.

Harry Wetherald: Because they're not spending the time to optimize the cost down heavily. They're kinda just, like, selling you the tokens on, on top. So yeah, that would be how I think about it. I think it, they're gonna be good options for a lot of people is the reality, right?

Harry Wetherald: That Claude Code and, and similar are gonna be good options for people that just need a little bit [00:14:00] extra on top of what they're doing. I think much like in the past how not everyone used Google and Microsoft, if someone really wants to make that a, an important part of their security program, they're probably gonna go out to, to specialist vendors and, um, and work with them instead.

Ashish Rajan: I think I, I, I... When you said accuracy, one thing that came to mind was AppSec as a field has been known for heaps of false positives. It's like I had, I still remember the, the two people team that I had in one of the organizations, entire job that they had was the entire time going through every alert that has come in from a SaaS tool, SCA tool, which is, because we spoke about reachability and exploitability earlier as well.

Ashish Rajan: So has AI kinda challenged that space a bit more, or is it the same even in this space?

Harry Wetherald: So it's changed it a little bit. I'd say back to your question about Claude Code Security and and Codex and stuff like that. Nowadays, if you, in those previous days, imagine we got 10 findings.

Harry Wetherald: You know, the old school of SCA and SAST would give you nine false positives out of the 10 at least, right?

Harry Wetherald: You know? Yeah. You know what it's like? Maybe 99 out of 100 rather than 9 out of 10.

Ashish Rajan: Yeah.

Harry Wetherald: What an unoptimized [00:15:00] AI product will do, like just using Claude or just using Codex or something like that, weirdly enough, it will give you I don't know two false positives out of 10 on the first run, and then on the second run it might give you three, and on the fourth it might give you one, and on the fifth it might give you five, right?

Harry Wetherald: So you have this slightly different, uh, different kinda thing going on where when you use them out the box, they can be more accurate than using rules and old, old tools and stuff like that. But without really optimizing them and training them and managing all the edge cases and stuff like that, they're, they're much more unreliable, right?

Harry Wetherald: So they give different results on different days, in different cases, and stuff like that, and they give very confident but sometimes wrong results 'cause they'll go very deep in an investigation, take one wrong turn along the way, and then give you the wrong answer. So you might get, rather than kind of an old tool like, um, you know, Sneak or Checkmarx giving you just blatantly a false positive with very little context, a unoptimized AI product might give you a very long, detailed answer, which is also still a false positive, but they've gone into a lot of context.

Harry Wetherald: So the key for, you know, what, what, uh, the way we've approached this and the way I think others will approach it is you've [00:16:00]got to kind of train the agents to understand how to navigate these investigations really, really reliably, and that's how we get out of this mess of either having just loads of false positives like we used to-

Ashish Rajan: Yeah

Harry Wetherald: or having results we can't rely on, like you kinda do if you just use AI out the box oftentimes-

Ashish Rajan: Yeah ...

Harry Wetherald: towards having these results that are really, really reliable, right? And they know when they... They know how to catch mistakes, they know how to correct those errors. They've been trained to actually navigate the investigations over long periods of time.

Harry Wetherald: Um, and I think that will be the key to kind of changing how AppSec works. Not just better results, but better results you can really, really trust as well.

Ashish Rajan: I... 'Cause trust is an interesting one, right? 'Cause I think w- a lot of leaders, they look at anything AI-generated. I mean, it was same case with automation as well.

Ashish Rajan: But let's just say in this particular case with the AI world where I get a result today Somehow people have developed a trust more for, I have run the automation script, I got a high for s- for particular vulnerability. I think it's pretty much... I'm pretty sure it's high. But because of the whole hallucination conversation with the AI, there's been a lot more conversation about, hey, if, if an AI agent gives [00:17:00] a particular vulnerability as a high and six months later...

Ashish Rajan: Or sorry, come, gives it as a low and six months later it comes up as a high or is, it's exploited. How do leaders build that confidence in the answers that they get for this? Because ultimately to your point, yes, there's automation, yes, there is the capability, but how do I develop a confidence or even in my team as well, not just myself, to be...

Ashish Rajan: 'Cause the ultimate goal is to be more productive and be able to go forward. How do you see people can build that confidence for the results from AI?

Harry Wetherald: Yeah. It depends what you're using. So if you're using a third-party vendor like us-

Ashish Rajan: Yeah ...

Harry Wetherald: right? You need to obviously choose the right vendor, uh, and assess them very, very thoroughly, right?

Harry Wetherald: Yeah. And not just trust whatever hand-wavy claims are gonna, gonna get going on up front. Um, and then you do need to be running, you know, try and run reasonably regular checks on making sure the data is making sense and things like that. But most of the onus when you're using a third-party vendor should be on us to build a lot of the monitoring and validation that sits on top of the product.

Harry Wetherald: Like, a huge chunk of what we've built is just validating and training the agents, right? Mm-hmm. Um, if you have to do that [00:18:00] in-house, that's where you have a much bigger hurdle to climb. So in my opinion, because agents are so hard to quickly assess, right? Because they're doing a lot of complex work. You need to build really, really strong kind of monitoring and validation layers that sit on top of it, so you get- Yeah

Harry Wetherald: good ongoing visibility on how they're doing. You know, simple things like if you're changing a model, how has that impacted results? How accurate are they at doing the same investigation again, and again, and again, right? You can run, sometimes you run an a- if you, if your system isn't very well put together, you run the same agent on the same data 10 times, it'll give you a different answer five times- Mm

Harry Wetherald: out of 10, which is not how you you know- ... not, not something you can rely on, right? So depends on what you're using. Uh, if you're building in-house, yeah, all about building not just the average, the odd spot check, 'cause a human might not pick up on this kind of stuff. You need to really invest in like big kind of automated ways of validating the results, and once you've got that you can build a lot more confidence.

Harry Wetherald: Is

Ashish Rajan: it... And to your point about looking at third party as well, a- and not everyone may be a Maze customer as well. Yeah. Just to kind of separate signaling from the noise, it, what kind of things can I look out for that [00:19:00] helps me with the auditability of, "Hey, how did you come to that decision?" Yeah. And obviously I'm, I feel...

Ashish Rajan: I'm curious to know in terms of does that help, and what are some of the things people should look out for in that- Yeah ... to build the confidence?

Harry Wetherald: Good question. So number one red flag to look out for is- products that feel like a black box. This is my, like, biggest bugbear over the last couple of years, is we get the odd customer coming to us and they're like, "I tried," "product X."

Ashish Rajan: Yeah. "

Harry Wetherald: I, I couldn't really tell if it was any good. It was a real black box." And I'm thinking, "How, nowadays, can you have a black box product?" LLMs, which should be the underpinnings of anything relatively modern now the thing that they do is they just chat, right? Yeah, yeah. A, a good, a good agent should be producing sometimes 20, 30, 40 pages of discussion, and as a product you need to try and distill that down and, and communicate it to a customer clearly.

Harry Wetherald: So one major red flag, if you're talking to an, like, AI-based product and it's saying ... And it looks like a black box and it's not telling you in really clear detail what it's doing, I'd run a mile usually. So that would, uh, that would definitely be one thing. The other thing I'd, I'd try and get vendors to do, or whoever you're talking to do, is to [00:20:00] try and explain what they're doing on top of the out-of-the-box models.

Ashish Rajan: Okay.

Harry Wetherald: Right? Because very easy, you and I could start a company today.

Ashish Rajan: Yeah.

Harry Wetherald: Right? And we could hook up, you know, we could, we could, uh, hook up Opus. Yeah. Um, we could give it a few prompts, and we could point it at some code bases and it'd find some stuff, do some useful things, but that's totally useless.

Harry Wetherald: Like, you can do that in-house. You're not, you're not adding any difference as a vendor on top there. So the thing I would really probe people is, "What have you done?" Like, what value are you adding, and what are you able to generate with that value? Because the list of things you can do is enormous, and you can change the outcomes drastically from just building with out of the box.

Harry Wetherald: But if they don't have a good story about that, and what they've done and how they've done it, probably the answer is they've not done very much, right? Mm-hmm. And they've just kinda like rushed a product out to market and just kinda chased the hype.

Ashish Rajan: What would be... A- and I'm curious to, the, just to double-click on that, 'cause I think it'd be interesting for people to hear the, the difference between a black box versus a, "Hey, here's what we do."

Ashish Rajan: And wi- without sharing- Yeah ... a secret sauce, how do you normally answer that question so people have a, have a version of it?

Ashish Rajan: And feel free to just say, "Hey, secret sauce. Can't share over here." No, no,

Harry Wetherald: no. No, I think if, if our secret sauce c- if someone could replicate what we've [00:21:00] done on a, af- after listening to a three-minute segment- ... of a podcast, then we'd, we'd be- I mean ... we'd be in pretty big trouble, right? Yeah, yeah. So no, I think answer more generally to where I see products going in the future, and basically what we've built, is historically if I was building a software product, I built some kind of database.

Ashish Rajan: Right?

Harry Wetherald: And I built some kind of rule-based logic sitting on top of that software product, and then I built some kind of UI integrations, workflows are sitting on top. And that describes most of the security products we know today.

Ashish Rajan: Yeah.

Harry Wetherald: Some of them do so- quite complex things in the middle of all that, but that really describes what they do.

Harry Wetherald: For me the w- the world around how we should build software products has changed so drastically, in the sense that we are no longer having humans define upfront, "Here is a decision for the product to make," or, "Here is a way the, the user can configure that decision." We're instead saying, "Great, we're gonna have these long-running agents."

Ashish Rajan: Mm-hmm. "

Harry Wetherald: They're gonna run for two, three, four, five, six longer minutes at a time. They're gonna explore three, four, five, six, seven, eight, nine, 10 different data sources, and they're gonna do that millions of times every day, and they're gonna drive all sorts of different [00:22:00] decisions in the middle, like, layer of the product."

Harry Wetherald: That's such a drastic departure from how we built software in the past.

Harry Wetherald: That we're not just, like, building roughly the same software platform and then just plugging agents in the middle of it or on top of it. Uh, and that's why you see so many of the incumbents struggling today, because they're trying to do that.

Harry Wetherald: They're trying to take their, like, 2010s era software platform.

Ashish Rajan: Oh.

Harry Wetherald: What you need to build today is, is drastically different. So you need to build a data layer that is suitable for agents to use, right, and gets the most out of agents. So what that looks like, instead of just storing data in a traditional way, you're gonna gather up more of, like, a context graph in a sense.

Ashish Rajan: Mm-hmm.

Harry Wetherald: Right? So every time the agent wants to do some kind of investigation, look into something, they don't wanna go and gather all the data themselves. It's extremely expensive and unreliable. Like imagine, you know, if you've used Claude or Gemini or something like that, when you say, "Hey, go and look up this from, you know, source here."

Ashish Rajan: Yeah.

Harry Wetherald: They'll often give you a pretty patchy response, and it will cost them a lot of tokens to go find that response. Mm-hmm. We don't want, every time we run a security investigation, we don't want them going and gathering source data every single time, right? We want them to have some kind of like preloaded- Contextual kind of- enriched cached [00:23:00] kind of like, data that they can go, "Oh, great, I need this question. Here I go."

Ashish Rajan: Yeah.

Harry Wetherald: And so that's a lot of work to build out that, like, layer of context, basically.

Ashish Rajan: Mm-hmm.

Harry Wetherald: And then sitting on top of that, okay, we're no longer just building logic. We're not just having a team of developers or security people writing logic around the kind of things we wanna catch.

Harry Wetherald: We're having these agents run for long periods of time and understand what they wanna catch. That, again, requires drastically different technology, so you're gonna probably want to build not just take-out-the-box agent framework, like LangChain or something. You're probably gonna wanna build completely your own version of that that's suited to your task- Mm

Harry Wetherald: and maximizing the, the value of your task. And then once you let these agents run for long periods of time, you're gonna need to not just give them one model, but the ability to access lots of different models. Yeah. You're gonna need to be able to orchestrate that intelligently. You're gonna need to be able to measure the success of different models intelligently.

Harry Wetherald: Okay, so once you've done that and you've got agents actually running, now you've got lots of real data starting to come through. So now you need to be able to validate the success of your models, right? Yeah. You need lots of different ways to do that. Yeah. Uh, and are they being smart? And then once you get lots of kind of successful runs happening, you now need a way to reinforce that back through the system.

Harry Wetherald: So you need feedback loops to help you [00:24:00]reinforce, "Okay, this was a good in- this was a good kinda run. We were correct about this. Let's reinforce the lower layers of the system, and let's go again." And then at the very top layer, the product layer, you're also probably gonna wanna think about a f- few things differently, because there's much richer contextual data sitting in the product now than there used to be.

Harry Wetherald: There used to be, tables and rows and not that much to it, whereas now we've got this really, really rich context. You need to think about the usability of that in a different way as well. So- All those layers are just drastically different to just calling Claude out the box. And they're so different to the way that the last generation of kinda software products were built.

Harry Wetherald: So you would hope that you hear some kinda story somewhere along those lines. If you don't hear at least some of those things, I would argue that, yeah, the, the, the company you're talking to probably is just more like putting a wrapper on top of some models and, and leaving it at that.

Ashish Rajan: And I, I think to, to what you said as well, 'cause you have to consider cost and other things to what you said earlier, expensive activity, so you probably spent some time optimizing that cost as well- Exactly.

Ashish Rajan: Yeah ... for the right kind of API.

Harry Wetherald: Exactly, yeah. They should have a good story about that as well because what we [00:25:00] found, like the first time... I may have told you about this before, but the first time we ran our cloud product-

Ashish Rajan: Yeah ...

Harry Wetherald: it was at like a Fortune 100 customer. Really, really big environment. We plug in, we're really excited about the first, like, big run we're doing, and we run it and the results are okay, right, need, needs some work.

Harry Wetherald: Um, and then we look at the cost, and when we extrapolated up to their whole environment, it was gonna be $4 million a week I think. So we sat there thinking, "I think we'd only ra- I think this is like way, way we go." So it was about the amount we'd raised at the time.

Ashish Rajan: Yeah. Yeah.

Harry Wetherald: So thinking, "Okay, that's probably not gonna work," right?

Harry Wetherald: Yeah. Um, and so from there we set ourselves up to say like, right, cost is gonna be a key, key part of like the product we build. Yeah. And actually, because cost is so high around this stuff, when you let the agents run, think for a long time, it becomes cost becomes accuracy i- in a weird way. Yeah. Because if you...

Harry Wetherald: As soon as... 'Cause you're always cost constrained-

Ashish Rajan: Yeah ...

Harry Wetherald: there's only so much customer will pay for a product, right? Yeah. And so the, there's always a maximum level that you can, that you can spend in terms of tokens on your side. So if that's true, and you're cost constrained, then the better you can optimize your cost, [00:26:00] the better your product can be.

Ashish Rajan: Oh.

Harry Wetherald: Because if I'm kind of managing some budget of tokens that I'm, or cost that I can spend, the more places we can find where we don't impact the accuracy at all, but we reduce the cost, which there are loads of cases like that-

Ashish Rajan: Yeah ...

Harry Wetherald: then the more we can drive up the accuracy because we can spend our budget more effectively.

Ashish Rajan: Yeah.

Harry Wetherald: That's what a lot of people miss about this stuff, is that they think that managing cost around this stuff is just like a nice to have for the vendor, right? Mm-hmm. That make a bit more profit, so we get that. Yeah, yeah. It's not the case at all. Like, if you... I think I did some analysis the other day, if you run Mythos- uh, on every PR for a 10,000-person software company, it comes out as $52 million a year.

Harry Wetherald: Right? So all these people that are like, "Well, Mythos is great. Why don't we run that as our SAST scanner?" Yeah. Not only will it not be as good a SAST scanner as something if you spent some time tweaking it, it's just completely impossible to do. Like, no one can afford that. Yeah. No, no company in the world can afford that, no matter what they want.

Harry Wetherald: So yeah, the, the best products here should have a really good story about not just how they're reducing cost by 20%, 30%. It should be they have [00:27:00] techniques that help them reduce cost by, like, 100X.

Ashish Rajan: Mm. '

Harry Wetherald: Cause you can do things in that kinda ballpark. Once you've seen enough real-life kind of data-

Ashish Rajan: Yeah ...

Harry Wetherald: you can start to understand why you don't need to use a frontier model anymore, and you can get the exact same results.

Harry Wetherald: So that means, like, orchestrating between, you know, one minute I'm using Opus, the next minute I'm using something much cheaper.

Ashish Rajan: Yeah.

Harry Wetherald: Maybe next minute I'm not even using a model at all. Yeah. And by, like, dynamically routing across-

Ashish Rajan: Yeah ...

Harry Wetherald: you know, those different parts, I'm able to then generate much, much, much better cost profile.

Ashish Rajan: I think that's a good, good point. Al- also just on the Mythos thing, I think the highlight announcement they had was around 20... They found a vulnerability which was 27 year old or something, and I think the... I was reading somewhere the cost of finding that was $10,000.

Ashish Rajan: Yeah. And I'm like, "wait, so that was one vulnerability for $10,000." Like, no person on the internet is ever going to give- Yeah ... that much money. But so I 100% agree on the cost factor, as well. People should ask that question. You mentioned something about the line of making a decision for what's the best for an expensive LLM, cheaper LLM, or other things.

Ashish Rajan: One of the things that people talk about in AppSec is [00:28:00]also, hey, I obviously there are parts which can be, uh, human in the loop, and which can be some- something kind of fully delegated. Is there some understanding on the AI ecosystem between cloud and AppSec as well, where you find that, hey, these parts could be easily fully delegated to AI 'cause there's a lot more accuracy, whether it's through using a third party or using it yourself, versus certain parts should always be there's a human in the loop.

Ashish Rajan: Like, are there, is there, like, a separation that you have in mind for that?

Harry Wetherald: Yeah. I think where it's kinda logically verifiable, so exploitability, which we started talking about earlier- Yeah ... in both camps, cloud and AppSec- At that point, I don't think we should be having humans in the loop of that decision.

Harry Wetherald: Right. Because th- the decision that you need... You wanna be able to run that at huge scale across maybe, like, millions of findings if you're a big enough company, and the analysis is quite deep. So if you're expecting a human in the loop of that you're not getting anywhere. You're just back to your old life of, you know, having a team of people triaging everything.

Ashish Rajan: Yeah.

Harry Wetherald: Where... downstream of that, where it starts to get a little bit more subjective, you might in some places want more of a human in the loop, and the main area is remediation at the moment- Right ... [00:29:00] where there's a lot of things we can do around AI and remediation and, uh, and we do, uh, most of them at the moment.

Harry Wetherald: But what we reliably see is most teams are saying wait a minute. I don't want you to take that final step yet." Yeah.

Ashish Rajan: Okay.

Harry Wetherald: And I think what we're probably gonna see is over time, as companies use AI to help them with remediation more and more, right? What you see is, let's say I do 100 remediation actions today, and 20 of them I've maybe already done five times before.

Ashish Rajan: Yeah.

Harry Wetherald: And the last five times they all worked fine. On the seventh go, could we think about making it more automated? Mm. I still don't think we're quite there yet, honestly, as a a comm- community as far as I can see. But that seems to be the best direction of travel, which is not we just flick a switch and everything's automated immediately.

Ashish Rajan: Yeah.

Harry Wetherald: But instead we use data to inform us on what remediation actions are really reliable. And I think, yes, simple code fixes is one of the areas that are most appealing there because the coding agents are getting so good that simpler coding fixes with enough context around what's been acceptable in this company before- Yeah

Harry Wetherald: and what it might do to the application and stuff [00:30:00]like that, you can see that world becoming a reality sooner. In the cloud, yeah, you've got similar kinds of, um, equivalents, whether it's a relatively simple fix, you've done it a lot of times before, you've got a lot of context around it. Maybe they're the best, like, early things for us to fully automate, and then we kinda just keep going and going and going until hopefully in a few years' time we, we've automated almost all of it.

Ashish Rajan: One of the things that come ups, comes up in AppSec is quite a bit about the developer friction. Like, the whole SCA, SAST, the entire ecosystem was, at least the previous generation, was built on that, "Hey, we wanna make it easy for developers to not make the mistake." How is that different in an AI native context?

Harry Wetherald: Yeah, and that framing was always interesting, right? It was like, "Yeah, you know what? We're shifting the problem left- Shift left. ... to help you. To help you guys." Yeah, yeah, yeah, yeah. Yeah, yeah. Yeah, it's to help you guys. Don't worry. Yeah, yeah. Yeah. We're not just shifting the problem to you and- Yeah.

Harry Wetherald: and leaving you in misery. There was a lot of that, and so how does it change in an AI world? I think, um, the accuracy is just so much drastically better that everyone can engage with the problem a lot more, right? I think is a big [00:31:00] difference. The re- ... Well, one of the key reasons we built Maze in the first place is me and my co-founders were all kinda leaders of engineering product orgs.

Ashish Rajan: Yeah.

Harry Wetherald: And we were all just constantly bombarded by this problem of, you know, each quarter, what are we gonna do? Well, we've got all these vulnerabilities to fix, and we've got this big backlog from security and things like that. And it was never security's fault. They were- Yeah ... they were trying to, they were trying to build, bring the best possible things.

Harry Wetherald: But now the difference is back then we knew that a lot of that stuff was bogus and not necessarily that important. If we can get to the point where we know things are critically important, then we should be able to- everyone should be able to engage with the problem a lot better. So it goes from, like, shifting left to help you, but actually hinder you massively.

Ashish Rajan: Yeah.

Harry Wetherald: If we get to the point where there's kind of like... The way I see it is we need a sort of security brain, in a sense, that sits behind the coding agent. So you've got Devin or Cursor or Claude or whatever it might be. Yeah,

Ashish Rajan: yeah.

Harry Wetherald: And that has a really reliable kind of brain that's done a lot of the thinking around the security problems for it already.

Harry Wetherald: It goes and calls that brain and says, "Hey, I'm about to build this application, this piece of code, this, this, uh, code change," whatever. "What do you think of what I'm about to do [00:32:00] here?" And then it can inform it with a lot of context and a lot of kind of opinion, and that's the m- I guess, the future equivalent of shift left, but a much more useful equivalent, I think.

Ashish Rajan: Also, so, so the IDE, as they call it, the Cursors of the world, or anything that I'm using to- Yeah ... to write my code.

Harry Wetherald: Yeah.

Ashish Rajan: It's already ha- Like, outside of the SCA and SAS, it's already happening. These providers are already providing the opportunity for them to build the code the right way.

Harry Wetherald: Yeah, yeah.

Ashish Rajan: So to your point, it's no longer, "Hey, I'm integrating into a CICD pipeline so I can stop Ashish from-" Yeah ..."pushing that code in."

Harry Wetherald: Yeah.

Ashish Rajan: It's even happening way before that. I think,

Harry Wetherald: I think you'll see both. Okay. I think you'll, you'll want multiple places where you can check because you build the, the further the code goes, the more context you get as well. Yeah, okay. Right? So if it's just on the IDE, you would just- you're just seeing literally the code or maybe you're inferring where it's gonna, where it's gonna go.

Harry Wetherald: Once it starts to progress through CICD and beyond, you start to gain more context of where it's gonna run and what control's gonna be around it, stuff like that.

Ashish Rajan: Right.

Harry Wetherald: So there's various reasons why you don't just wanna check everything as far left as possible.

Ashish Rajan: Yeah.

Harry Wetherald: But what I think is gonna be the case is, as Cursor and Claude Code and Devin, all these kind of coding [00:33:00] agents get more and more popular, those tools are not gonna wanna do all the things I mentioned earlier of going in, like, gathering all the security relevant context and putting it all in one big graph and caching it all and understanding it all and stuff like that.

Harry Wetherald: They're gonna wanna do that for the kind of developer's typical workflow.

Ashish Rajan: Yeah.

Harry Wetherald: And they're gonna need, like, a buddy, right, who they can go and call and say, "Great, I'm about to build this application with these business flows and this purpose, and I'm thinking of building it in this way. From a security perspective, what might I want to know?"

Harry Wetherald: And then the security kind of brain can feed in at that point, help it build a more secure application. It then builds the application, maybe pushes it, maybe it goes to CICD, and the security kind of brain comes back again and says- Yeah ..."Great, now I've got more context of what you've done."

Ashish Rajan: Yeah. "

Harry Wetherald: Let me check it again."

Harry Wetherald: And then we maybe have a few checks kind of as, as things go through. It's probably roughly the right, the right setup. So not drastically different to how a lot of tech companies do it today.

Ashish Rajan: Yeah.

Harry Wetherald: But, um, but more AI to AI in various places rather than rather than a human getting a false positive and trying to deal with it.

Ashish Rajan: I'm curious, the security brain that you envision, is that, like... [00:34:00] Of how do you see this? Obviously, 'cause d- and I love what you said just there, because today as a CISO or a security leader, I'm looking at everything. I'm looking at AppSec, CloudSec, SOC, and- Yeah ... everything else that goes around it. The security brain is an interesting one because a lot of people are talking about there's a parallel, let's just say, an AI version of security being created.

Ashish Rajan: Uh, and I think the examples of Cursor and all the other tools is an interesting one because that's kind of fundamentally changing the way everyone's producing code. Now it's not-- It's like the PMs are producing code, designers are producing code. How do you see your vision where now that you're doing the cloud to code, how do you see that kind of like security brain form?

Ashish Rajan: And what... if you have an example of something that's like this in terms of how you see it, I'll be curious to know about that as well. I'm sure people would be curious as well as to, 'cause you're probably seeing a lot more of, since you're building the AI native ecosystem of security for code and cloud- Yeah

Ashish Rajan: how do you see the, the teams change or evolve, and what does the security brain look like? If you have some thoughts there.

Harry Wetherald: [00:35:00] Yeah. Our thoughts, I mean, it's all, all developing at the moment, but the thoughts are basically that in-- It's not unreasonable to say that we're not far away from most development teams mostly relying on coding agents to get their work done.

Ashish Rajan: Yeah.

Harry Wetherald: I don't think developers are gonna go away anytime soon. I think that we, in some places we'll have more of them, honestly, because there's gonna be more useful software to build. But the, the core work is gonna be kicked off by agents. Uh, and a lot of Um, the complexity is gonna be handled by those agents, and then humans are gonna come in to kind of, take certain steps.

Harry Wetherald: So there's two ways of looking at that. Either those agents, solve all the security problems themselves, right? And they become master experts in security. But to do that, they're gonna have to do so much beyond what they're doing today and, and what is optimal for them to do really. Or you say, "Great, there's gonna be security vendors or internally built security tools," either one, "that are gonna go off and gather all the data and information that might be relevant for a coding agent that they might wanna inform them around a security problem."

Harry Wetherald: So that'll be things like gathering up all the context in a way that the coding agent can use most effectively. So rather than just saying, "Hey, here's raw data from our code [00:36:00] and our cloud and all our controls and stuff," it'd say, "Here's, here's everything enriched on, into a easily understandable map," basically.

Harry Wetherald: And then great, well, I also wanna understand all the other vulnerabilities in my environment, all the other issues in my environment that this new piece of code might interact with. I wanna understand the threat model of my environment. I under- I wanna understand what's most important about to not go wrong.

Harry Wetherald: I might wanna understand what some humans in the security team have, like, defined as, as the worst things to happen or the, or, or not so bad to happen. And that's what I mean by the brain, like all that kind of information available in one place and available in a format that's very easy for an agent to use, coding agent to use.

Harry Wetherald: And then if I'm-- Cursor's about to write me a new application, it goes and gathers a bunch of context from there, rather than having to go and crawl a bunch of raw data across the whole enterprise to try and gather that all up in the moment it's writing the application. It just wants to instead say, "Great.

Harry Wetherald: What do I need to know from a security perspective? I know where to go for it."

Ashish Rajan: The true shift left basically at the production part, yeah?

Harry Wetherald: Yeah, pretty much but it, with a lot more context kind of- Yeah ... sharing hands rather than a, a quick bitty piece of advice or a quick alert [00:37:00] about a piece of bad syntax, right?

Harry Wetherald: This is, this is a, a lot, lot different to that world.

Ashish Rajan: Actually, it's an interesting one because to earlier what we were talking about, how do you separate the AI bolted versus the AI native, as I like to call them- Yeah ... uh, versions of people where the traditional environment has always been at least the AppSec one has been, "Hey, we integrate into your CICD pipeline.

Ashish Rajan: We integrate into your IDE." But the context was never the play or the conversation. Do you feel like security teams and specifically AppSec people who are, uh, probably like thinking of, "Hey, I need to do some AI-fication somewhere. I know my developers are producing code using AI." What's your vision with the AppSec programs that are AI native in a way?

Ashish Rajan: What is, what would they look like?

Harry Wetherald: Yeah, good question. Yeah, if you were starting from scratch today- Yeah ... kind of how would you think about it?

Ashish Rajan: Or even uplifting it as well- Yeah ... 'cause I mean, some people, I mean, enterprise probably already have one, so I'm curious about both answers- Yeah ... if you're starting today versus uplifting it.

Harry Wetherald: Yeah, there's a few kind of steps. There's the, there's the direct integration with the coding agent, which we just talked about there. I don't know if that's like- this very second, [00:38:00] the most critical place to start. I think it's a place that the coding agents are gonna-- we're gonna go, we're gonna end up with these coding agents always having a security kind of voice to lean on.

Harry Wetherald: I think there's useful things you can do at that level today. Probably the most impactful thing to do today is to get really good at the step that happens after that, which is, you know, you are able to very, very kind of surgically understand with new code that you're writing, or on a regular basis in your code base, where are the real problems.

Harry Wetherald: And that feels like if you're thinking the biggest difference from an AppSec program of five years ago, where we were using a lot of rule-based scanning, we're gathering up huge amounts of results.

Ashish Rajan: Yeah.

Harry Wetherald: As you said earlier, a lot of those results were bogus, so then we maybe had teams that were trying to just, like crawl through them and triage them, and then hand them over to developers in a relatively triaged state.

Harry Wetherald: That feels to me like the, like the most obvious place for us to change now with, with AI, which is a lot of that we should be picking up much more accurate findings.

Harry Wetherald: We should be picking up much more subtle findings, things that we didn't used to be able to find- Yeah ... but we now can, but we now expect AI to maybe attack, for us, and then we should be probably [00:39:00]thinking, "Okay, the developer's workflow now looks very different."

Harry Wetherald: So if I'm helping them remediate, how do I help them remediate this best? Is it, is it really a ticket in Jira with a long description- Mm ... of what to do, or is it a pre-built prompt that can just fly straight into their coding agent and give them the answer out the other side, or something along those lines?

Ashish Rajan: Okay. I think I like the analogy because I think to your point, it's about coming into the existing developer workflow rather than just, "Hey, this is the way security does it."

Harry Wetherald: Yeah.

Ashish Rajan: And not... Again, uh, and this is kind of goes back to the friction piece that I've, that we were talking about earlier as well.

Ashish Rajan: I mean, those are the technical questions I had. You guys have an announcement for the code piece as well. Uh, if you wanna share a bit about what people can expect from it- Yeah ... and, uh, what's different to the, the previous generation of appsec, like we were talking about.

Harry Wetherald: Yeah. So we, yeah, we launched, uh, Maze Code recently, so that's two products, basically.

Harry Wetherald: One in, um, in third party code, so SCA, looking at things like CVEs in the other people's code that you bring into your application. Yeah. And then one in your own code, so that's kind of similar to a SaaS [00:40:00]product.

Ashish Rajan: Yeah.

Harry Wetherald: That product will find you, will review every PR for you and try and find any potential vulnerabilities, but it will also do these kind of very long-running investigations across your whole environment on a regular basis.

Harry Wetherald: So that's really lo- reasoning across your code, reasoning across your cloud-

Harry Wetherald: ... and understanding, okay, there's a MFA bypass here, right? We've reasoned through a series of steps an attacker could take that would allow them to bypass MFA, therefore, this is something you should fix. It's not really assigned to any single pull request.

Harry Wetherald: It's not assigned to any one code change. It's just a regular kind of research or audit that we're doing across the environment.

Ashish Rajan: All right. Okay. Oh, so that- Yeah ... that's the code to cloud story that you guys are-

Harry Wetherald: Exactly. Oh. So yeah, the big difference that, uh, as far as I know, no one is yet using kind of AI agents to do these really deep running investigations and doing it across both cloud and code.

Harry Wetherald: The crucial thing there is that the context from both, uh, informs each other. So if I've got a cloud finding- I might be able to get, X percent of the way into un- understanding if I just look at the cloud context. Yeah. I can probably do some very useful stuff there. But if I then go and look at the code that's underpinning it as well, I can probably get another, you know, 20, [00:41:00] 30% kind of impact in terms of how well I can understand it.

Harry Wetherald: Yeah. And vice versa, so often in the past, our AppSec tools have been kind of looking, kind of when you think about it quite hilariously, at these tiny snippets of code that are getting placed into this massive code base that's getting run in this massive cloud environment, that's protected by this massive swathe of controls, and we're looking at these tiny snippets of code and going, "Nah, it doesn't look good to me."

Harry Wetherald: Right? It just doesn't... You know, when you think about it that, like that, it doesn't make a ton of sense, but we just haven't had the tools to be able to understand all that context together. Yeah. So yeah, the premise of what we, what we launched recently is yeah, two things really. How do you really reliably and cost efficiently use AI to solve problems in AppSec?

Harry Wetherald: Yeah. That's kind of one thing we're doing. But then B, also, how do you tie AppSec together with the other context that, that helps it? So cloud controls that sit around the cloud and things like that, so you have the full story rather than just looking at kind of snippets of code or single repos.

Ashish Rajan: Awesome.

Ashish Rajan: Uh, well, thank you so much for sharing that. Where can people learn more about the Maze Code, uh, announcement, and maybe connect with you as well?

Harry Wetherald: Yeah. On our, on our website at maze- mazehq.com, or yeah, you can follow me online on, on various different places, [00:42:00]which I'm sure we can link.

Ashish Rajan: I'll put the link, uh, on the show as well.

Ashish Rajan: Thanks so much for coming on the show.

Harry Wetherald: Great. Thanks for having me. Thanks, everyone. See you next time.

Ashish Rajan: Thank you for listening or watching this episode of Cloud Security Podcast. This was brought to you by techriot.io. If you are enjoying episodes on cloud security, you can find more episodes like these on cloudsecuritypodcast.tv, our website, or on social media platforms like YouTube, LinkedIn, and Apple, Spotify.

Ashish Rajan: In case you are interested in learning about AI security as well, do check out our sister podcast called AI Security Podcast, which is available on YouTube, LinkedIn, Spotify, Apple as well, where we talk to other CISO's and practitioners about what's the latest in the world of AI security. Finally, if you are after a newsletter, it just gives you top news and insight from all the experts we talk to at Cloud Security Podcast.

Ashish Rajan: You can check that out on cloudsecuritynewsletter.com. I'll see you next episode.

Peace.

‍