0:00:02 Emily Wearmouth: There's been a lot of talk about the potential risks that Frontier AI models might present, and today's guest is going to give us an alternative perspective. He is a red teamer within a security team, and he's been using frontier models to great effect. So welcome to the Security Visionaries podcast, Mohit Kulamkolly. Mohit is a senior engineer on the red team within Netskope security team, and it's great to have you with us, Mohit.
0:00:26 Mohit Kulamkolly: Thank you. Thanks for having me. Yeah, happy to be on the podcast. Yeah.
0:00:31 Emily Wearmouth: So you have done a couple of blog posts, and they prompted me to reach out to you because what you talked about within those articles was some work that you and your broader team have been doing using these models within your red teaming efforts. And I wanted to talk through those a little bit, and there's a couple of different, I'm going to call them experiments. I hope that doesn't make them sound too small. There's a couple of different experiments and different models that you've been using, and that my intention is to ask you lots of questions that hopefully unveil all the details and discoveries that you've made as you have gone. Since getting access to frontier AI models, and I believe Netskope joined "Glasswing" in June this year, your team has been running some really informative experiments. You've been putting those frontier models in the way of Netskope's own security products, if I understand correctly, and looking to see if they can find serious security bugs, and in particular, memory corruption bugs.
0:01:26 Emily Wearmouth: Now, our listeners come from a really broad church, and so could you start us off, Mohit, explaining for a listener that perhaps has never touched vulnerability research themselves directly, what is a memory corruption bug and why might it be considered one of the more dangerous and harder to find categories of security flaw?
0:01:45 Mohit Kulamkolly: Yeah, sure, sure. Yep, that captures it accurately. So let's start from what memory corruption bugs itself, like you rightfully pointed out. So a memory corruption bug happens when a software mishandles its own allocated memory space in a wrong sense. So this is managed by the operating system, but then it is allocated and decided by the software itself. So when this happens, it leads to vulnerabilities that can trigger multiple other effects within the OS, which is not expected behavior. So why is it dangerous? Because, so we'll take a step back as to why it is dangerous to understand it more better. So we can broadly divide the operating system into two parts. So one will be the user mode and the other will be the kernel mode. So user mode is where all the programs stay, all our programs, and kernel mode is what is related to the operating system.
0:02:44 Mohit Kulamkolly: And user mode time and again needs things from the kernel to execute certain actions and everything. So this is where the attack surface begins. So if a program crashes within the user mode, it'll stay within the user mode itself. And when it starts to ask things from the kernel, attacker can also see that or attacker can also use it. So then through that path, it is able to crash things in the operating system as well, which leads to more vulnerabilities. So that's why it is very dangerous compared to other vulnerabilities.
0:03:15 Emily Wearmouth: And what was it you were trying to find out by pointing these AI models at those memory corruption bugs?
0:03:22 Mohit Kulamkolly: So basically Netskope operates within the system within the entity of a client's operating system. And from there, if a vulnerability is being triggered, that is a memory corruption vulnerability. Like I said, it can result in the downtime of the system or it can result in privilege escalation vulnerabilities and all of those things. So the goal here was to see if a vulnerability within Netskope client particularly can be escalated into something that affects the operating system. So we are breaking out from our program into the bigger picture, which is more catastrophic compared to just the Netskope client crashing. So yeah, that was the goal.
0:04:03 Emily Wearmouth: And before we look at how you use the AI tools, how would you normally go about looking for those vulnerabilities before you had Frontier AI?
0:04:13 Mohit Kulamkolly: So before it starts off from trying to figure out what the attack surface is. So there are APIs that are written for these kind of communication that happen from user mode to kernel mode. So you try to first figure out what APIs are there and how the program is being written, totally from a black box perspective. When I say black box, we don't have source code, nothing like that. So that's when we started. And from there we will try to see if a payload that we send or a data that we send results in a crash within a system or within that particular operating system. And we keep trying it over and over to figure out what payload or instruction this is in the fault. So that's when we try to develop fuzzers on our own. That's what we have detailed now. So I've developed fuzzers that helps figure out these vulnerabilities.
0:05:10 Mohit Kulamkolly: But having AI in this picture escalated to a whole new different level of testing wherein there is much, much more expertise that is required to even step into this domain. And then because of the advent of AI, we can escalate it more further.
0:05:29 Emily Wearmouth: And I'm going to quote from your blog post here. So in the first phase of work that you did, and you were using OpenAI 5.5, have I got that right?
0:05:38 Mohit Kulamkolly: Cyber model.
0:05:39 Emily Wearmouth: You said that your starting point was you can't just ask AI, find me a bug and trust the answer. You have to give it the same tools a real human bug hunter would use and force every claim it makes to be checked against a real running system. So to take the points there in order, first of all, why is it dangerous? We may know this. Tell me explicitly, why is it dangerous to just trust a model's word that it found a vulnerability? And what might go wrong if you skip that verification phase?
0:06:09 Mohit Kulamkolly: Yeah, sure. So before I dive more deeper into it, I think I might end up contradicting the statement past a while because that's what Mythos taught me with the new experiments. So what happens with these cyber models, OpenAI 5.5 or the cyber model is that they are trained on a humongous amount of data, all security vulnerabilities and findings. So it allows to hallucinate in situations where it has to make assumptions rather than information. So if you just ask the model to find the vulnerability for you, what happens is that that's the only thing it knows. So it has to conclude from its assumptions that it has initially made. So in one way it is good, which we figured out in later part. Initially when we wanted to write out, we have to make sure we are as deterministic as possible about our findings. So that's when we decided, okay, let's go ahead and start with what we know.
0:07:11 Mohit Kulamkolly: Let's try to expand on that, and then we will go into the chapter of what we don't know and what the model can do.
0:07:17 Emily Wearmouth: Okay. And so walk me through what you've actually built here. What does a lab for a setup like this actually look like?
0:07:24 Mohit Kulamkolly: Yeah, without getting into very specific details of how it is, on a very high level, it is just that you are giving a vulnerability researcher the tools that it needs to do. I mean, it needs to need to have for it to execute certain actions. So think about it, there are virtual missions in which the software will be running. There are virtual missions in which the tools will be running. So I just connected all of them together, connected the dots together and gave the model this, and then asked it to hunt for a vulnerability in a very specific way that I would look at it with whatever my experience was with the previous hunting efforts. So that's how we started with it. That's how the lab looks like on a very high level.
0:08:12 Emily Wearmouth: I'm going to ask a potentially tricky question. So there's been a lot of stories over the last week or two about agents and AI breaking out of sandboxes and doing things that perhaps answer the task they were given, but certainly not in a way that we would be comfortable with. Are there any specific guardrails that you are putting around these experiments anticipating that it might try and break out? How are you making sure that it doesn't?
0:08:36 Mohit Kulamkolly: Yeah, so that's very good question because particularly in this context, when an agent is asked to do a specific task, we don't say it to do it in a very specific way. That's what I did initially, and that's what I understood might be a limiter for the agent. So to break out of that, what we created was individual sandbox environment. So every virtual mission has a sandbox environment, which it cannot be broken or which cannot be accessed if we explicitly don't allow it to do it. Especially in the case of these testing Windows machines and everything, instead of running a Docker container or such concepts, virtual missions works the best. So that's the level of isolation that we have built for individual toolings and the kind of access that it has to it. And we do all this testing on a separate system and mission without proper internet access.
0:09:34 Emily Wearmouth: I guess that keeping it off the internet is one of the key things to restrict its ability to go rogue. You also mentioned in the article that you wrote that you built this around a target machine that's specifically allowed to crash and a separate machine watching it with a debugger. Why did you keep those separate and why is it useful to actually allow it to crash rather than stop it before that happens?
0:09:58 Mohit Kulamkolly: Yeah, so that's the whole concept of this memory corruption vulnerability and why this is interesting. So whenever a system tries to find that a memory is being mishandled by a program, so it goes to a fail-safe stage. So that is a crash stage what happens. So when you are trying to test an individual bug, when you're trying to test an individual payload on a microscopic level, so the best way to confirm it is initially that the bug exists is to see if it crashes or not. And if there is a crash that is absurd, that means there is a mishandling of memory that is happening. Then we can later discuss how we can escalate it, what system productions we need to get around, so on and so forth. So these things come up in a later stage. But also to add on to one interesting thing that you mentioned, why not we pause it just before it crashes?
0:10:53 Mohit Kulamkolly: So there is a system like that as well. So we do that also in-house. It's a snapshot fuzzing infrastructure that we have built wherein we try to pick up just before it crashes so that we can replay it millions of times so that we find new variants of our vulnerability. So yeah, that's the whole context of it.
0:11:12 Emily Wearmouth: And I've got one more question on this phase of the experiment. I reserve the right to ask more, but at the moment I think I've got one. It sounds like a lot of the model's early hypotheses about bugs turned out to be wrong. That it was using outdated assumptions about the software. And I wondered why did you determine that that was happening? And what, if anything, did you think the model learned from being wrong and going through that phase of getting things wrong?
0:11:43 Mohit Kulamkolly: Yeah, so what happens for these kind of software is that it is difficult to test this kind of software because it is very much dependent on the environment that it is deployed on. So if there are small tweaks that are made to the operating system, let's say there is a function or let's say there's a program that is supposed to be running in the background, it is not running, the software won't behave in the way it is supposed to behave. So this is one of the reasons why the system, it not only needs to adapt to whatever environment it has for vulnerabilities, but at the same time, it needs to also figure out the next step as to based on what outcome it gets from it there. So it's not just that, okay, this is the standard operating procedure, go about it. So you have to make sure the system accepts that or the software is ready to accept that standard operating procedure and it works before you start throwing in payloads.
0:12:39 Mohit Kulamkolly: Because if you are not putting in an AI here, what will happen is that I'll send in a lot of payloads and then the AI won't or the software won't even respond to it. So how can I test it? So that's a reason why the model did that correction. Yeah.
0:12:54 Emily Wearmouth: Right. So what we've been talking through to this point was your phase one. So you had humans, you, designing all of the steps, and then the AI was asked to execute tasks within a process that you had designed. I want us to move on now to your second phase. Now for your second phase, you did change model and you started playing with Claude Mythos instead. Was there a reason to change that or was it just that you were originally looking to run experiments through both? Or was there a benefit that you felt you'd get by moving to a different model?
0:13:30 Mohit Kulamkolly: Not really. We just got new fancy tools and new analogs.
0:13:34 Emily Wearmouth: We've all been there. Okay. And on this second one, I'm going to try and sketch out what was different, and then I'm sure that you'll illuminate a little bit further. So rather than you designing every step and then asking the model to execute, you asked the model to decide what to investigate. You then asked it to prove any bug that it found against a real system. And then what seems to be quite a critical element of this one, you also required it to have a second independent copy of itself double-checked against that proof. So you are giving it more of the process to do, but you're also then building in more checks for it to be doing because you are removing more of the human from the workload there. Can you walk me through what made you, from finishing off and concluding about your OpenAI experiments, what made you design it in this way?
0:14:30 Mohit Kulamkolly: So we had our lessons from OpenAI when we started the testing with Mythos. So under the hood, all the security, all the models. So they all are basically prediction systems. Even though we say things like they developed new software and everything, they just predict what is next in a very efficient way based on the context what is given to it. So the more and more you restrict on the context or more and more you put the context on a leash, what will happen is that the kind of information that it is able to produce will also decrease. So when we were testing with OpenAI, we produced it a fuzzer. We asked it to build on top of that. Now we wanted to see if since we gave it the fuzzer, that is why the only thing it was able to build out of it is an extension of that.
0:15:21 Mohit Kulamkolly: So we removed the fuzzer out of the picture and then we taught it how we build the fuzzer and how you can do that by yourself. Either you can do it that by yourself or you can just do whatever you feel right for reaching this particular interface of the program. So that's why we wanted to give it a shot that way. So instead of guardrailing around it. So it worked out very well. So we understood how the model behaved and creative ways it took to find out a vulnerability. So that's the crux of the issue.
0:15:57 Emily Wearmouth: Were there any extra considerations that you had to give because you were handing over more control this time? Were there different ways that you were structuring things or any additional guardrails that you felt you needed to put in place?
0:16:10 Mohit Kulamkolly: Yeah, more isolation. I think more isolation was what was key for it. The model, not on our working system. So we had a separate laptop just for testing of this. It was off grid. And then yeah, we went all in this time. So instead of asking it to use the tools that are there on the system, we just made sure it is isolated more and more. Yeah, that's all.
0:16:35 Emily Wearmouth: Okay. And then I guess by building it in with that double checking what it's producing, that's also extra guardrails around the conclusions that it's drawing, I guess that you're building into the model.
0:16:47 Mohit Kulamkolly: Yes, yes. Right.
0:16:49 Emily Wearmouth: How did you avoid it convincing itself it was right? How did you keep that double check separate enough that it wasn't able to. I mean, one of the things that we've seen in the last week was an agent that went out and literally went to the extent of creating deep fakes of employees in order to get sign off on something internally. So we know that AI knows how to convince. How did you make sure that it wasn't just convincing itself or this secondary check that what it was doing was right?
0:17:21 Mohit Kulamkolly: Yeah. The major thing about this is what we discussed previously as well, the model being a prediction system and context being a key part here. I'd like to take the same concept here as well, the context. So almost all the time, 100% of the time when a model gets something wrong, it is because it does not have the right context or it has junk context, I would say. So the reason why there are two separate systems is for the same reason. So whenever a model looks at new work, it just means that it is looking at from a plain context to window. So in that way, it does not make any wrong assumptions that was previously created. So in the case that you mentioned as well, so it all boils down to what the model needs to achieve. So the goal for one agent might not be the goal for the other agent.
0:18:16 Emily Wearmouth: Ah, interesting.
0:18:18 Mohit Kulamkolly: And based on what you said as well, the initial goal might not be creating deep fakes of that particular employee, but rather to get around this sign-off system. So it'll do rogue whatever it can do, but then model did not do anything harmful from its context, but from external context it did. So context is a king. Yeah.
0:18:40 Emily Wearmouth: So I guess you built in a bit of friction between the two stages that if it's not checking its own work, it's a different AI agent checking some work so that they're not teaming up and you keep some delineation between the two. That's a really interesting design point.
0:18:58 Mohit Kulamkolly: Exactly, exactly. Yeah.
0:19:00 Emily Wearmouth: So tell us about some of what this one found. How did it work? What did it turn out?
0:19:08 Mohit Kulamkolly: So yeah, we got a lot of good results from these particular two of these initial experiments that we did. So around 17 to 18 vulnerabilities we were able to get just on open source softwares. So these softwares are something that Netskope uses for building our products. But then these vulnerabilities are found on the upstream packages and then they were reported to the right personnel whoever is managing it. And then there were these memory corruption vulnerabilities that I discovered. So there were 15 to 20 memory corruption vulnerabilities as well. And then finally we had for the differential check, four or five of them we found. So this is not the shared scale of thing, 20,000 vulnerabilities were found, and this is just a small scale that I'm talking about, 15 to 20. The reason or the key part to notice here is that each vulnerability when reported from a customer or when reported on Netskope will account to an IMF.
0:20:15 Mohit Kulamkolly: So those IMF incidents will lead to huge loss for that particular entity who has suffered it. So we finding it within our products is saving us a lot of money and then ensuring trust on our customers as to what we are being stood up to.
0:20:35 Emily Wearmouth: Yeah. Now I wrote down again from your article something that I wanted to explore that looked particularly interesting. There was a bug that the model found on the kernel side, and you told a story about a crash that didn't happen until it figured out something subtle about how memory gets allocated behind the scenes. Do you want to just walk us through at a high level that particular example?
0:20:59 Mohit Kulamkolly: Yeah, sure, sure. So I think this vulnerability was in a configuration parser. So this configuration parser basically copied the registry value to an exactly sized pool allocation using a string-length copy function. And this string-linked copy function did not have an outbound check that was there. So out of bound check. So because of this reason, this is a textbook out of bound vulnerability, and it can be exploited very easily. So here to get to this vulnerability, there was nearly five or six preconditions that needed to be satisfied. So preconditions will be simply as simple as looking at whether the software accepts a specific type of name of service or if it is a different thing that it accepts or a different version that it accepts. These are all preconditions.
0:21:54 Mohit Kulamkolly: So after it figured out all the preconditions, still the crash did not happen. So it had to jump into the debugger, try to dumb the allocator. And then it figured out that the OS apparently appended something called a null terminator, which is very common. And then the allocator rounded off that buffer into a full table basically. So this caused an out-of-bound read to not land where we had it to land. So then it figured out the allocator geometry as to how it is happening, and then it changed it exploit to exactly match to whatever is expected to trigger the fault. So that's what happened there on a very high level. Yeah.
0:22:35 Emily Wearmouth: Part of why I asked you to explain that was because I wanted to experience the mind blow moment. I mean, the complexity and the layers of detail that this is getting into, if you were to envisage a world in which you had more manually reached that outcome, I mean, what sort of length of time, how many man hours? What would that look like? Or do you just think it would only happen by accident?
0:23:02 Mohit Kulamkolly: I mean, it would be days and days of effort. And then like you said, it would be accident as well. So because it's very hard for these things to be figured out because when you're looking at a debugger and trying to find out where the allocator went wrong, it's hard because you need to make sense out of lot of information that are there. You might not be expert at that particular very specific domain that you're looking at, but then you have to know all of these things to make sure you connect the dots. So again, yeah, it might be an accident that you can come across these issues or months and hours of effort to find this vulnerability.
0:23:40 Emily Wearmouth: There was another one that I found interesting in your article. It was a bug that took multiple days and thousands of attempts to nail down, even with the AI. So you talked about a human equivalent would take days and days. Even with the AI running, this one took multiple days and thousands of attempts. What kept that process moving? What changed between the failed attempts and the one that finally worked? And why didn't it time out? I mean, how long, if it had taken instead of thousands of attempts, if you'd have been into the hundreds of thousands, would it have just given up and not found that? I've asked a few different questions there. Take your pick.
0:24:18 Mohit Kulamkolly: No, makes sense. So actually for that vulnerability or finding that particular instance, why the process was difficult was because we did not have source code for it. We did not have symbol table, we did not have nothing. It's a full black box testing that we did. So the thing about that is for these kind of vulnerabilities, when you are trying to find them out, there are multiple nuances that are there before you even get to the vulnerability itself. So for the AI for timing out part, it is the way it was designed that you are going to face a lot of these backlashes that your initial hypothesis might work, might not work. You should not be just waiting for one hypothesis to complete while the other one for you to move on to next. So instead of a linear fashion, it was mostly a parallel fashion.
0:25:09 Mohit Kulamkolly: So agents spin out sub-agents as and when required for exploring these ideologies till you find or figure out the right way to approach it. So that's the reason why it did not time out mostly. I think it ran for a few days for finding these kind of vulnerabilities, particularly because of the complexity and availability of less information. But yeah, sub-agents did the trick there.
0:25:34 Emily Wearmouth: So I'm going to zoom out a little bit, and I think it's worth, hopefully, listeners have got the hang of the fact that these two articles that you've published are well worth reading. So we'll include details about where you can read more of this detail in the show notes. But let's zoom out for a minute from the exact experiments that you've run and have a think about what does this mean in the broader context and what does this mean for some of our listeners when they're thinking about their own environments and perhaps they don't have access to all of these frontier models at this point? I guess the first thing my brain goes to is if this kind of capability, it's not exclusive to Netskope. There's a wide list of organizations that have access to these models, and even the models that aren't deemed frontier models are getting cleverer.
0:26:17 Emily Wearmouth: So if this technique helps you find bugs within your code and your systems and they're available or tools quite like them are available to anybody, what does it mean for the average security team that perhaps doesn't have a research team like yours and is on the receiving end of other people using these systems to attack and find these problems? When you look at that challenge that the industry is facing, how do you see it?
0:26:47 Mohit Kulamkolly: Yeah, so what is eventually going to happen is that the models are going to get more cheaper and cheaper because of the way that it is advancing in case of security as well, in case of every development perspective. So I think what is going to happen is some of the other models, everybody can access now open source open weight models as well for exploring these things. So what I would recommend for any security research team, whatever they're trying to do and they want to start to do, is to start giving these AIs the right tools. And then the right tools that you give to the AI, the more you'll be surprised and the more exploration it can do by itself for figuring out these stuff. So instead of looking at it like a complex tool that is required for connecting it to a different tool that is there.
0:27:42 Mohit Kulamkolly: For instance, let's say that you need an MCP server that needs to be used to connect a tool to it, but you don't have an MCP server for that. So you will need to write it from scratch and then build it on top of it. So that's a learning curve that you might need to jump across to reach that side. So think about it just like even MCP server is just whatever APIs that is being exposed, you're just connecting it to AI, that's all. So it's just simple code. Try to figure that out. And then if you're able to connect your tool, if not, you're able to connect with the tools, you have to start writing things on your own or use AI to write it. In that way, once when you start giving the tools the sensory things, the eyes, nose, ears. And once you have that, once you have all this information, the tools will start processing or the AI will start processing the information the way you want and then it'll give you better results.
0:28:37 Mohit Kulamkolly: So yeah, that's the way I look at it.
0:28:40 Emily Wearmouth: Do you think that an approach like this is going to materially change the way that software companies or technology companies ship their software? Is it going to change the timelines? Is it going to change the expectations or the costs? What do you think those implications might be?
0:28:57 Mohit Kulamkolly: Most definitely. So yeah, like I said, what is going to happen is security vulnerabilities are going to get more cheaper to discover the more and more the AI advances. So what is going to happen is that the fix will get more expensive. So with the rate we are shipping the software right now. So the fix for these vulnerabilities are going to get expensive and then will be harder to execute. So when we have how Netskope has this from even before the time when AI had it, so we have our own SDLC of development. So in that software is not a second thought. I'm sorry, security is not a second though. It's a thought initially from your whiteboard when you start thinking about a product itself. So if you go by that particular approach, so ask AI to build a threat model for a product just after you have a PRD or a product requirement doc that is prepared.
0:29:54 Mohit Kulamkolly: So that itself will give you an idea about what to anticipate while you're building the product itself. So more content Context for the AI, anyways, AI is going to build this stuff. So you can give more context to the AI so that such vulnerabilities don't exist in the later phase of your software.
0:30:08 Emily Wearmouth: That's a really interesting idea because through these experiments, you were taking something that was already built in all of its complexity and asking AI to rummage around and find problems with it. But you are suggesting that actually you could use these systems when you've just got a product concept and some sketches as to what the architecture might look like and already start getting the AI systems to poke holes in your plans so that that security rigor is really genuinely running from the beginning point. You don't have to put time and effort into building something that might not work. You can start finding problems before it exists.
0:30:45 Mohit Kulamkolly: Exactly, exactly. Precisely.
0:30:47 Emily Wearmouth: Hadn't even though about that one at all. So if a security team wants to do something, and I think I guess specifically a security team that is responsible for a piece of a digital property of some kind, now that might be because they're a vendor or it could be because they're building private applications and private elements within their stack. If they wanted to do something like this for the first time, what is the very first step that you might be concerned they might skip that you would want to just pull them back? You've talked a little bit about some of the things that they could start doing themselves. What's the thing that you want to go hold up, but do this first?
0:31:26 Mohit Kulamkolly: Yeah. Okay. No, makes sense. So what I feel like particularly for these findings is that AI, let's not think about the hallucinating part at all. Let's say the AI finds all vulnerabilities. So if the AI is able to find 20,000 vulnerabilities, it is not right to throw these 20,000 findings at your developers and say, ask them to just fix it. So that's the one thing that we should be careful about. Finding vulnerabilities is one thing, but having a remediation plan for it is the other important factor here. So before even we start throwing in these vulnerabilities, you have to start to have a discussion with your developer to understand where should we start looking at the vulnerabilities and what are the key factors there. So only when you have that synergy, then these vulnerabilities will be useful as well. Else it will just stack up in your long list of vulnerabilities as non-fixed, 20,030,000 of them.
0:32:26 Mohit Kulamkolly: So that's the one thing that I would have in mind before I jump deeper into or start using these fancy tools.
0:32:34 Emily Wearmouth: That is a great point. So yes, get all the detail right of what you are doing and the right rigor and guardrails and approach, but zoom out a little bit and think about the impact that your program is going to have on others and don't just start creating a 500 times increase in someone else's queue because they won't like you for it.
0:32:54 Mohit Kulamkolly:Exactly.
0:32:56 Emily Wearmouth: Brilliant. Well, Mohit, thank you so much for joining me to talk about all of this today. The minute I read the articles, I knew I had to get you on, so I really appreciate you making the time. And I also sense that this isn't your final experiment. We said it was phase one and phase two, and I can see from the glint in your eye that there's a phase three perhaps already happening. So where should our listeners go to keep up with the work that you're doing and the discoveries that you're making?
0:33:23 Mohit Kulamkolly: Sure. Yeah. Most of this work will be documented on the lens blog on the Netskope website itself. And yeah, if at all that there's anything else, additional ones, we'll also post it on community sites of Netskope. But yeah, there will be more things coming the way for this testing.
0:33:41 Emily Wearmouth: Fabulous. I think we might have to get you back on the podcast and hear about them as they happen. Thank you very much, Mohit.
0:33:47 Mohit Kulamkolly: Thank you, Emily.
0:33:48 Emily Wearmouth: You've been listening to the Security Visionaries podcast, and if you've enjoyed this episode, I definitely recommend you take a rummage through our back catalogue, which you can find on any of your favorite podcast platforms. And our more recent episodes are also up on YouTube if you want to see our smiling faces as we talk to you. So enjoy those and I'll catch you next time.
){kind=icon}
