Why AI Security Is Moving Into the IDE

What changed over the past six months is a a better understanding that we should go as far back into the source of the problem as possible. When we started, we were all about coming in and saying, "All right, here's the fix for you. You know, I see your code. I see your environment. I understand what the requirements are from a security perspective and I'm going to to provide that fix for you ad hoc for your existing environment to implement. So we've taken that and the the journey that we went through over the past two and a half three years was first of all to understand that this is not just a security problem. This is not just a security problem. This is an engineering problem. Security is one of those elements like I mentioned before that that finds themselves at the the receiving end at

the DevOps engineers kind of task list of things to do to their environment. So that was the first understanding. We expanded beyond security and we can fix things that are not just security related. We can fix things that are related to SR to software reliability engineering that are we can fix things that are related to cost and performance optimization. So that's one. And the second one is we're no longer just fixing things ad hoc. We're no longer just looking at existing code and saying there you go. I fixed it for you. We decided to shift all the way left. And that that's kind of a security paradigm. shifting left, meaning getting as close to the development process as possible. And today we're at the IDE, we're at the development environment itself and and we're there sort of as a you know, as the good angel

on the shoulder of that engineer who's writing the code. So the second that someone starts building a a cloud environment, starts putting out out an architecture, before they even deploy the first version of it, we're there to accompany them and and apply fixes, apply and and kind of bring those different policies that I've mentioned to life almost at real time at the at the editor itself, at the IDE. So when I'm spinning up, when I'm just writing or evening prompting an AI like a cursor or or a co-pilot to start build or or add another element to my environment, GMok is there to apply the fixes to that code before it even makes it to, you know, before you even save it for the first time. So that's what we've been, you know, that's the the the kind of transformation of that tagline of it's

all about the fix, but we've moved it as early as possible to prevent any kind of rework because the second that an engineer puts something out, the second that you you code something and you deploy it, the last thing you want to do is go back and fix it or or you know, change it. If it's working, it's working. That's it. You want to forget it and move on to the next thing. So being able to address things and provide those fixes as early as when the code is being generated, that's been what we've been kind of focusing on on the in the past six months.