How Lovable Manages 100+ Daily Changes, Vibe Coding & Shadow AI
57m 2s
The discussion centers on the security challenges and strategic approach to AI adoption in organizations, particularly for developer teams. Traditional security and development infrastructures are struggling under the increased velocity and volume of changes driven by AI tools, which allow developers to produce output at an unprecedented rate. A key theme is the necessary trade-off: organizations cannot maximize speed with AI while expecting to maintain previous levels of security and quality; intentional choices must be made. The recommended strategy is to avoid company-wide, fear-driven AI mandates. Instead, leaders should identify specific, safe "air pockets"—contained use cases like prototyping—where AI can solve genuine problems without initial high risk. This builds value and stakeholder buy-in gradually. Furthermore, it is critical to guide developers toward a curated set of AI tools and manage access intentionally, as too many options or overly broad permissions can lead to fragmentation, security gaps, and reduced effectiveness. The conversation concludes that security professionals must become proficient in AI to support this new paradigm, both by leveraging AI themselves and by building secure enabling frameworks for the workforce.
This old rails that CICD's run on, they're just getting load tested and reaching its limits in every organization right there. Me asking AI about, okay, what is the good library for PII, IEI, Sunitization and Goal? And you gave me a library and said it's actively maintained. And the last commit was eight years ago. The more context you go to the AI, the dumb what it gets. Are you going only on speed? You cannot expect security and quality to stay at the same level. We literally like we step on the same problems we've been dealing with for decade, but now we speedrun through it. You may have heard of a company called Lovable where you could create websites in a matter of seconds, but to one of the most popular AI companies coming out of Europe and is being used globally everywhere to create websites in a matter of minutes. Not just a regular website, but you can also see the code as well. Now I had the fortune of talking into the head of security at LovableEgor at the Munich Cybersecurity Conference called MCSC. And we spoke about everything that he is dealing with at a scale up. He joined when he was employing number 40 to now there are 150 people with Lord developers, AI native. How does he approach security in an organization, which is AI first? And what are some of the things that they're seeing from the security that's required for developer adoption of AI, the project manager option of AI features coming out in huge volume? What does that look like? I have to say this is like part one of this conversation because he was so much to talk about. So I'll definitely be bringing back ego once again, but this best of the conversation was primarily focused on security for AI, especially when used by the workforce. And even how should security teams even use this? Like I've been talking about this in techriar.io for some time on how we as security people need to be more AI fluent as a word goes in terms of how we can use it ourselves in our teams, but also how we can create tooling and things that enable developers. And overall, it was a great conversation. I think if you are someone who's trying to figure out, what is my role as security person in this world of AI? What is my ROI for the use of AI? How is a builder or leader? You can increase the adoption of AI in your teams and maybe in your organization as well while being developer friendly. This is definitely the conversation that you want to hear. Definitely share this episode with other people who are working on increasing adoption of AI in their organization. Share it with the CTOs. And I hope you get as much value as I did from this particular episode. We're definitely bringing back ego again for another episode after this, but I just wanted to share this while we're so fresh in mind because this is very hot topic for a lot of people who are being asked by everyone in their organization. Hey, we want to increase the air adoption. But what does that look like? How do security play a role in this without creating a lot of resistance? This is going to be epic. I think this would definitely be shared quite a bit. So I just want to give you a heads up. Make sure you have a note pads out and definitely share this with other people who should be aware of this as well. And as always, if you have been finding episodes of AI security podcasts valuable and if you are here for the second or third time, maybe the fifth time or sixth time, I really appreciate if you did a quick second to hit that subscribe, follow button, no matter which platform you're on, Spotify, Apple, LinkedIn, YouTube. We're on all the podcast platforms. It's free for you and I only take a second, but helps us reach more people. Really appreciate the support that you guys have been showing so far. And continue to do that at conferences like MCSC and otherwise as well. I hope you enjoyed the episode of Igor and I'll talk to you soon. Peace. Hello, I'm Michael from another episode. I've got Igor with me to thank for coming in and maybe to start things off. If you can share a bit about yourself, your journey, cybersecurity and where you are now. Yeah, well, hi everyone. I'm Igor Andriy Shinko. I'm head of security first engineer who worked on the security at the lovable. Yeah. You know, lovable probably needs no introduction, but just in case you know, you missed it somehow. It's this product that allows you to create anything with AI. We started as websites. So you can create any website, you can host it, you don't have to code at all. You don't even see code. You can see code, but you don't have to see code. And then now, you know, you can add videos, audios, you can make it multimodal, people build games with it. So it's literally like the, you know, this, your imagination is the ceiling here. And I ran security for it. And we go into like hyper growth periods. So I joined, I was like number 40 or something six months ago. And now we're 150 plus. And our engineers discover the AI. And that's been such a wild journey. So probably we'll talk about that. And about me, I've been, I've come from engineering security background. So I started as dev ops and then moved to devsack ops and then yeah. And then it's all the other security roller coasters started from there. I worked in Sweden, Finland, Canada, been Shopify, Sana, that was the recent KWIPE. I worked there now, lovable. So I've seen things. And of course, I think now with AI, everything just exploded in complexity. And it's such an interesting field to be. And I look forward to this hour with you. Yeah, but I'm looking forward to this conversation. Well, I think so maybe the way I was thinking about the second divide this into two conversations. One is obviously coming more from a security for AI, where most people like yourself, who are the leaders as well. They had this exposure developers using coding tools, UNI and military. We had a lot of, we heard a lot of AI security stuff yesterday that we were judging. And there were a few products about towards security. We obviously have the AI. So there's so many AI things that are happening for AI for security. But if I were to just boil it down to the workforce and how the workforce have adopted AI, how do you look at security for that, especially in like a hyper scale of kind of environment? Because maybe baby steps where you start, how do you look at it? Yeah. No, I think it's changing. That's the key part about it. It's constantly changing. Or since I started lovable, it changed a couple of times because the companies are changing themselves, how they work, how they are, and AI is changing how how people work as well. So what I've seen is that with the discover, when people adopt more AI agents, then they adopt running AI agents in parallel. And it's all done in for the sake of speed, velocity and kind of maximizing the performance, maximizing the output. Every developer wants to be productive. Every developer wants to solve the hardest challenges. That of course, and then there is tooling for it. And I feel like we are lovable. We are living on the edge of it. So we are at the forefront of it. So we've seen what others will be seeing in six months, one year from now, maybe in one month. I don't know, depends on how fast you move. But of course, the complexity of usage of AI explodes. The rate of change, the churn of changes also explodes because now every developer can create maybe five, ten hundred times more changes than before. And for security changes risk. Because you know the state of the system or like you can, you can be like, okay, system in the state is reasonably secure because we've done a lot of reviews. We've done like, you know, there are automated things, there are things where they say, yeah, you can do. But in general, like, you can, you try to keep it in the secure state. But if the state of it is changing hundred times per day, you need something else, right? There is not enough humans and there is never enough, there would be never enough humans. And like, I see that old methodologies, they're just failing because of this train. It's like, if you bring, if you build your, if you build a small app with like, you know, flask or like something unscathed, you know, like some, some kind of development framework, which is like for starting. And then suddenly there is a million of users on it. It doesn't scale. You have to like, okay, now I have to move to something else. So similar, I feel like, like, this old rails that CICD's run on, that developer organization runs on, companies run on, they're just getting law tested by the churn of change. And I think we need to adopt that first. Yeah. And we need to understand, okay, how do we support developers enough? And other employees, I can cover that later. Because it's, it's just, it's being law tested, it's being a weight tested. And you know, like, yeah, it has its limits. Yeah. And probably it's very quickly reaching its limits in every organization, right? Yeah. And I guess you work you set as well. Obviously, you're focusing on security for AI for the workforce and what does that look like? There's the developers who are adopting the PMs who are adopting now. The roles are blurring as well. The PM is also now producing the bird. They also pushing the product. Developers now doing PM works with access is different as well. Access is evolving from being a developer who could only push the broad to now, they're, hey, I won't be able to access Figma or whatever else. They're like, oh, okay. I feel like it's very, the access control conversation is quite fluid as well. But my curiosity is coming from in terms of people who are looking at this and to what you said, but from the time many first came in to now, obviously, it's quite a bit of change. A lot of people are seeing the beginnings of this in their own addition today where they have this immense investment from companies investing into their development team engineering team to, hey, we want you to use more AI. We want you to integrate AI into applications. How do you think about this? And if I just go on for that security for AI layer for now, we'll talk about the work force using secure work force using AI. We'll talk about that first. For work force that has to use AI, whether it's the developers and there's a lot for complexity there, or whether it's the non-developers, how do you approach that? And in a way that to what you said, because traditional ones are failing at this point in time, my, whatever the IPS ideas has, has no context of semantics and all of that. So how do you look at that today? It's a very hard problem. And as you mentioned, it's even describing the problem with all the levels, I'm Chris Holtz, AI for Security. Security for AI.
- Right. - There is a lot of embedded problems. You cannot solve just one layer. You have to solve like through all the layers. And if we think about access, what it looks like today, that everyone needs access to everything. So again, if you're a PM who calls, how do you push code, right? If you developer who PMs, how do you update the roadmap? Like I even allow to do it. So do you be allowed to do it? That's a question. And I think we should go back. I really want to push back on the narrative of companies, like push sort of, there is this, I feel like a lot of companies drive their AI adoption because of fear of missing out. They're like, our competitors will get AI, they will get super good. We gotta force it down, people's throws. We get a force people to use it. And that's like nothing good comes out of it, right? Resentment, bad mistakes, security breaches, absolutely. So like I would focus on solving the problem here. And if the problem is like, okay, we're optimizing for speed. Or we're optimizing for this much speed and this much quality. And security is often seen as part of the quality domain. So you need to be mindful and intentional as an organization leadership about the trade-off. You're like, are you going all in on speed? Are you just like putting the gas pedal down to the maximum? That is possible with AI absolutely. But you cannot expect security and quality to stay at the same level as it was or as you wanted to. - Yeah, yeah, yeah, I do situation that's not the case, yeah. - Exactly. But also for advice, we're so let's say, I get a lot of questions from banks, like from big, big banks, like thousands of hundreds of thousands of employees, how can we adopt AI? How it's so scary. And like, well, my advising is finding this air pocket. So imagine like you were in the cave and then cave is like flooded. But there is air pockets where you can breathe and you can do something there. So finding those air pockets in your organization where it's safe to use AI to some extent and where it solves some problem. So it could be okay, let's do simple prototyping. No data involved, just prototype something. Do you want a new dashboard for login, for like your bank app, whatever? Like internal tool prototyping, you can do it, right? And then you don't connect to anything to start with. And then you get people to like it. And then a lot of people approach, say, yeah, with after we started doing it, we saw more value in it. And by then you find more air pockets where to put it. And then suddenly you realize, okay, they're interconnected. There is a lot of value to be uncovered. And one of my advice is like, don't try to use AI for the sake of AI, right? You just need, if it solves your problem, incredible, then you don't have to sell it to your stakeholders inside the org. You can say, hey, we can connect your development. And you don't say like with AI, or like you can of course. But if you manage to connect their development speed or prototyping speed or something else, like everyone will just praise you. And you know, as a stakeholder, you'll be highly regarded. You have a vision and everything. But if you start like, okay, I won't AI in everything, that's that's that will fail in my opinion. And I guess your point, so the idea is not to rush into it. Instead take a moment to understand where and what use cases ideal where to start. So if you are about the air pockets, where correct, there are always some air pockets that you can find for, like I think we were talking about this earlier as well with a few people. The idea that I want all the access and day one is poly falsepart. There's, I'm sure there's some access required, which requires you to define a use case. Now once you define a use case, you know where the air pockets are as well. But then I think the overwearing sensation maybe people have is that I don't know, I have to look at everything. So I want it to have access to everything so that when I get to it, but I think I don't know people know this, but the more context you give to an AI, the dumb what it gets. - It's just about to make it. - Yeah, yeah, yeah. - It's the same with people, right? If you have too much, like if you go to the supermarket and there's like 50 kinds of brands, you will be stuck, you will be like, what do they choose? And they also are doing so. - I think there is a behavior research saying that if people presented too many choices, they after making the choice, they're less happy than if they would have been if there were fewer choices. And they made like, oh, I just made this, I should one of two, one of them or another. Same with the access, right? If you sort of, if you have access to everything, you, you know, your AI just goes astray, it just comes up with some weird ways of solving the problem. And it drifts you away from actually the value that you're adding. Because if you can do pretty much anything, a lot of people like, I think a lot of organizations, they lose focus. And they start like finding this local minimus or maximus, depends on how you look at the chart. Where it's like, yeah, I mean, that's great, but is that the right solution for the right problem? - Yeah. - So yeah, I think really I of course, that enables a lot of experimentation. And you need experimentation. But also like, I think like, ideally, and we don't live in that ideal world. But like, of course, access permissions, like we started with access and workforce, like you should be able to solve problems with the access you are given or request more access, right? But you should not be kind of basing everything, like kind of, yeah, I need everything. And then I'll be able to solve everything. Then it's all nothing because you like focus. So from my perspective, I think if, like the organization should start first, I didn't find the problems they want to solve with AI. And then understanding, okay, this will require this level of access, this for these groups of people. And it might be quite broad, right? But then the organization needs to make that conscious choice, okay, speed versus quality, right? Where do we, where do we tune it? Do we put a gate on that access? Some, does someone have to approve it first? Or is it auto-granted? Or is it just available by default? That's also possible. Like if your organization has like very low threat profile and like no one will, or you think so, I will want to hack you or like, if a data bridge happens in all this, like I'm not a big deal, we're ready for that. I mean, there are organizations like that. I mean, they can move super fast. Yeah. But again, like it's not about using AI for the sake of AI. It's not about giving access so that everyone can use it. That's just, you know, that's like asking for trouble. Where it's more like if you do it intentionally and you know why you give everyone admin access on everything, well, maybe that's good for you. But at least you think about it and you do it intentionally. Yeah. And I guess you thought through the case as well. But maybe, don't do it doubly on this. How does one approach, so this of this, suppose for example, you define a case study, right? Okay, I'll quote a use case, but that's just one team. I got 2015. So I've got technically I've got 25 use cases. Some of them would may have a developer group is now starting to use AI. Some that could be that I have a SaaS application that's AI and I need to have. So they're obviously both parts to it. As a security person, if you just take the first use case of the developer using AI for coding, how do you approach that today in terms of the security of it while maintaining the speed and quality a balance of that is important? Yeah, great question. I start with the problems I'm seeing and more like for whoever listens to this, maybe it will resonate because there is such a big number, such a large number of different AI agents one can use. Starting from completely yellow clothe, both molded both things to solve any problem, to clothe cold cursor, you can use lovable, you can use so much AI. And then if you let your people experiment, you will end up with everyone using everything. So I find one of the bigger challenges is convincing your developers to narrow down their choices a little bit because AI enables experimentation. People get very used to it. And then you say, okay, guys, we can secure just two agents, but the third one is actually weird and it works in a different way. And like it's hard to enforce guard rails on literally every agent out there because they're all different and working differently, right? So then you start like, then people start feeling, okay, it's slowing us down, there is some general friction unhappiness. But I think this is a conversation that needs to happen. It's like, if you as an organization you solve certain set of problems, it's like, this is what the tools that you solve it with. You can't have all the tools from the market. Because then people, you know, you know, this tool you work well with it, but you don't know that one. And like it just creates a lot of fragmentation. So that's one thing, but more broadly on the topic of AI security for AI development. So as a developer group, you know, developers usually in many companies they have quite a lot of access. Maybe not directly, but they can request it. And I think a good metaphor here when trying to track model, like I think, okay, working or wrong in the AI development is thinking of AI agent as, well, it is an agent. A agent is there. So it has agency. So it will think that will act on the behalf of developer. So developer federates its access, its credentials, its knowledge to the AI. So you should almost see it as like, you know, another developer essentially. And if your developer can get access to something and you want to guard it from AI, you need to put something like a human controls in for instance, you need to go and request like a pamper and it's somewhere else to access production secrets. Because for instance, let's say you have developer secrets available for development environment for everyone, like, you know, you can easily update, you can everything, but then production secrets, you need an escalation for that. And then AI will.
not be capable of doing the escalations, we'll be like, okay, now you develop or need to go and grab that credential for me. But that will introduce healthy friction. And so about, you know, I don't have to tell you the idea of having guardrails, the blessed path, the healthy friction, where it's like you start moving off the blessed path, the more friction adds, but this is exactly it. So we need the same concepts. We like implementing or like we would try to implement it as part of DevSecOps, whatever in the name is, secure development programs. We need to apply them to AI in our own way and find a good injection point for it. So like, I find like I personally found using PAM as a good way to segment it a little bit, right? So you have different permits for different actions. And for all the tasks that people don't need to do every hour, you can grab it once a day, you can grab it like when on based on the need, right? But then AI cannot do it for you. And that's important. Like you make it so that I cannot go there, it cannot authenticate, it cannot go there and do it. And then because it cannot, it will find, well, either other way of solving a problem. But also it will not make that mistake where it just, because it can, it goes there and it does completely, something completely outrageous. Yeah, even without being hijacked by Malish Attacres or something like, you know, I remember laughing your home director, really one of the examples. So probably some controls around it. And another thing is of course the visibility of what happens, imagine that sprawl of agents, sprawl of development methodologies, how people, how people create the code. Like all companies will need some sort of telemetry on that. Understanding who is using with agents, where do they send data to, what are they creating, which MCP servers they're using, which tools, which plugins they're using, which is kills they're using, because there is now that our marketplaces of skills, they're at supply chain attacks against kills from those marketplaces. So we literally like we step on the same problems we've been dealing with for decade. But now we speedrun through it. So there is a lot of things that can go wrong. And I think as always, like, you know, if you look at the NIST framework or something, inventor or visibility of things, it's where the cybersecurity starts. You need to know what you're protecting. So the same thing my advice would be just like, yeah, go get some solution, build it yourself. If you are like, you know, super powerful AI users or buy it. And then so that you can capture how AI agents work on each computer and be ready for that to change constantly. Because people will discover, you know, tomorrow one big provider reads this new coding model. And that all performs or gets viral. And you know, everyone is on it. Yeah. I think I think I've said something interesting because the observability is an interesting one because a lot of times, I think blast shape and I started experimenting with Amazon bedrock and others were what I even Azure Google cloud as well. What we found was sometimes it's not a lot of telemetry available to apply control so we just assume that it's an Amazon thing or it's a Google thing or whatever. And so I think I with you on that, the first step is inventory. Understand where you have figured out some way to understand the telemetry way. Whether even if it's bad AI shadow way, whatever the AI may be, at least find some way because to what you said as well, I may think that my developer is only using cursor because that's what I mandated. But they could be going on using cloud code skills or whatever, cloud code or whatever. And you're like, oh, wait, I did not realize. So having some kind of discoverability is important. And maybe if we were to take a step further because you mentioned advanced users away as well. And I realized in all the conversations that I've been having in the advisory board with that we had on people have different definitions for advanced users. So a lot of people like, oh, I use chat GPD. I mean, personally, I think that's like, I mean, level zero level one I don't know for me personally, but where do you sit on the what do you consider is like a moderate user to an advanced user and does do security teams need to be at some level in their in off usage for that as well. And what would that look like for securities? Right. Well, I think if we were to talk about identifying the user group, let's say in our organization, there is definitely key key groups there. Yeah. And they differ by how much they do with AI, right? Like, what do they connect to? Because AI on its own is to say, you know, it gives you answers to some questions. Or like, it asks question itself and then acts on the result, right? Does the agent loop essentially? But but like, it's more about like, what what else comes to the picture? What else do bring? And in my experience, the more advanced users, they just bring more. They bring more context. They may bring more integrations. They they have bigger impact with it. And by bigger impact, they mean, okay, let's let's go from the top, right? Let's say the most advanced are some developers that run 10 agents in parallel using some kind of work to restructure using super advanced skills. Like hundreds of skills, hundreds of sub agents. Yeah. Like the surface of impact for those for that use is very, very high. Yeah. The risks are also because the surface is very, very large story. It's multiplied by the surface. Right? So this is a more risky users. Yeah. But also they're advanced and they probably have bigger impact on on like a product, for instance, because usually this this is some sort of developer there. And then that's going back to the world we started from where as the organization, where do you balance speed and quality and security? Yeah. So if you want them to be able to do it, I mean, fine, because like probably they will be like worth each of them will be worth like a small team of engineers in the previous in the past. But of course, there are some risks associated. So you should probably have some controls around this group. Yeah. But the controls that do not hamper their productivity if you optimize for speed. Right? So you can just like put some to them around anything external, leaving the organization. Okay. Let's try to protect against prompt injections. You know, let's see, let's see, you know, you take the expectations for prompt injection or something. Yeah. Let's whitelist, allow list some domains that we know are good and then see how that impacts their performance. Other complaining a lot. Maybe, yeah, maybe we need to scrap this because performance is important. Or if our organization is like, no, guys, sorry, we got to have quality and security in place. So like just let us know all the domains that you allow to we allow you to send the data out. Yeah. And that's, I mean, that's a pretty powerful control. Right? And then like you can build it. But like, I think there is like the core here is like whatever they work on. Like if there is like this box of we in which they are super productive, you should very be very careful of like going into that box or into that space because this is what makes them this super advanced. So we need to be mindful that advanced users more impact. Yeah. Then of Quarters, just like other developers that well use AI, they like using it. They still review their code. Probably they buy the fold. Their code is more qualitative and secure. Yeah. Just because if they if they don't rush, they don't do as much context switching if they don't run 10 agents in parallel, they have more time to think about it. And that's also it's a good group of users to have. Yeah. And I would optimize. I think, you know, like I think it's global. We also optimizing for having for catering for needs of both groups. So you have super advanced, super productive ones. And then there are ones that are also very productive. But they're a bit more like, you know, they move slowly on purpose. Yeah. Yeah. A slower on purpose. And it's still very fast compared to like traditional development two years ago or three years ago. And we need both groups. They just need to focus on different problems. Yeah. And then there is a group of, as you say, there is a pms using cursor or code on web and running web agents. You can connect, get her repository. You can let them do it. And how we approach it is very simple. We allow people to create pull requests. But to merge them, you need to someone else to look. Yeah. Yeah. Someone like someone from advanced or less advanced developer group to look at it and then merge. Yeah. So this way, like everyone can create. Yeah. But then it's like it stays outside of production. And then you also like they don't, well, we prefer they don't use like CLI tools, right? They don't mess with something that they're less, less proficient with. Yeah. And also something that is more powerful as a tool. But online agents, you know, you go there, your repository is connected. You can ask for changes. You can see, you know, if you have a good deployment system, you can see the changes live in some better deployment. Yeah. Great. Like that's your surface. Like what's the worst thing that can happen there? Well, they're there. Of course, there are things that can go wrong. But I think this is a good way to enable them to be almost developers, right? They will become like creators. Yeah. We'll bring value without without you blocking them all the time. Yeah. So yeah. And I mean, there's a different security models in each of these groups. Yeah. And I guess you pointed as a person who's looking at doing this in their organization, you should identify what those groups are and figure out somewhere because you're point, I'm glad we started with the inventory with the built a piece. Now that we established it, the level below that is like, hey, if I identify all these different groups you have, what they level of usage is and based on that, you can have some like, hey, whether speed is important, quality is important. But having the informed decision of where would there be a human approval kind of coming in and how that would go through because I guess to even add another latest sub agent piece that you would talk about for advanced users, a lot of them run them autonomously. They just run overnight. Could you as a developer has gone back to sleep? Next morning, wake up the sub agents of Dandai job and you just read the code. Like it, you can be really advanced in this kind of things.
as well today. So maybe that's the the workforce as you're engineering team, the super doc engineering team. What about the securities role in this? Because you have started this conversation and I'm kind of glad you called out the traditional SCLC, which you may have had done death cycle for a long time. You would have had the SAS, the DAS, everything going for a long time SCAs and all that. What is the role of security in this new world? That you see? Crucial, absolutely crucial role because if somebody runs 10 agents at parallel overnight, that's a lot of changes. As you're in just here being pushed to production, who reviews them? Well, sometimes humans, sometimes agents. So all of that has to be somehow assessed or like security has to be injected in it. And there is a bunch of solutions of the market that guarantee or claim to guarantee the kind of agent time security. So things that inject guard rails into the coding. So let's say the agents are coding, but then it calls some tool. You can build the tool pretty easily for yourselves, right? It could be an MCP server like some API, which says, okay, follow these guard rails. Yeah. These are the important things for this context. And then the agents are creating and then once it's stopped creating code, when it has a diff, the diffs them back to the tool saying, okay, it doesn't make sense. Do the guard still make sense? Yeah. The ones that wear in place, right? So something like that is needed in my opinion, because like you have to teach agent how to write secure code. And another thing that we saw working pretty well is just explaining, given some very general high level security model context to like, call them D or having a knowledge for like, you know, each agent works a bit differently, but they're all similar in FAZI in terms of like, you can create some rules for for agents how to behave. And then this would be like, okay, here's your security context. Yeah. So just put like high level business threat model, saying, okay, what are the key components of the product? What is what needs protecting? What needs attention? Where you need to move slower. And with that knowledge, agent knows, well, quite, quite a lot. And then I read a conversation online recently that you need to be actually restrictive in your prompting. You have to say, don't do this, because if you say, do that, it optimizes. Yeah. Yeah. Yeah. Yeah. Also, you're, you're might listing what is good than that. This is such a fun thing, because in security, we always prompt that we, our internal prompt in our head is to prefer allow list over denial list. But it's not for the agents, it's revert. Because if you, if you do only allow list, it will always always do the focus against that. And like, the real world is much, there is so many more passes, but it will always choose the passes that you say, you're allowed to do this. Yeah. And I think you do, to kind of double that on what you were saying as well, because that model used to work for us because we had solutions that were designed for it. Yes. But in today's world, I mean, because we have, we knew that we knew what an excess is, we knew what a sequel injection is. Exactly. So there was, there was a pattern for us to go with. There is no pattern. Yeah. It was a finished surface. It's like, it feels like we're now dealing with a much larger attack surface and the surface. Yeah. And we see them. Yeah. Yeah. Changes, it was. Yeah. But I see like allow list were good. Like if you, if you're static allow list, that's great. Yeah. And if you have instructions for agents, those, those things work differently. Yeah. Right. So then, yeah, telling them what not to do is, is a good practice. Yeah. 100%. Do you find, I'm, I'm not you call it out as well, because I think definitely, I definitely encourage people to actually call it out in their system prompts and we can go on to all that as well. But so with the security teams that are now working with these developers who are in these different August usage levels, A to what you said, and I think that's where you kind of meant as well, the traditional security controls to require. It's still in the SCA, you swing the SaaS, all of that. But the volume has changed quite a bit. Right. How, and now you've been deficit cost before as well. Because what do people have? Desk of teams, they go, and I know so many people who have gone on the path of saying, actually, it's getting all well. I did just raising their hands are going, I have no idea, I'll be with so how are you guys approaching this volume of change coming through? Right. I think one of the key solution, kind of key value on logs here is getting the right tooling for for this AI age. So for instance, in the SaaS world, there are two distinct tooling categories. There are these old master dance that has been there forever that are in every big companies, CI/CD pipeline. And then of course, the AI features. Of course, they say, yeah, we have this AI under Azure, there's amazing, yes, somebody via. But try running it and then compare it to the new, like you can find some new SaaS, they don't even say their SaaS because that's a cursed word. New AI security for code solution that performs a Genetics scan, right? Where it tries to build the application business model where it gets the code, builds like, you know, it's internal representation, it understands how the data is flowing, how the what are the user flows, and then try running it against your code. And you see very different results. And the second tooling will be much better finding the DDI based tooling, will be much better finding business logic issues. And things that actually are very high on the over asked top 10, yeah, there's normal, the classic over asked top 10 list, misconfiguration, like access access, wrong access patterns. And those are the things that are cursed and that we want to protect against, right? Access says because there are so many good frameworks nowadays that are used and AI is primed to use the good frameworks, you know, if you write in TypeScript, you know, AI is perfect in times TypeScript. Of course, it's still possible to get access says, but it's much harder. Yeah. But what the real problems come from business logic, from access controls and so on. So AI is good at spotting, yeah. But another thing is what's important, AI is good at taking feedback, right? So you can always like, if your tool offers you to send feedback back to the AI, and not just, you know, the old tool would just update some regx pattern. But in this case, imagine the tool telling you about the business logic issue and they say, no, no, it doesn't work like that. And you explain how it works actually in the real life. And then it takes it and learns from it, and it takes it puts it into internal memory file. And the next time it runs, there is no such issue, and it better understands the context. And what happens when there is a critical mass of changes of comments like that from developers like that context source from this, from the search of truth. Yeah. Then it starts being very, very good at what it does. Interesting. Yeah. And we've seen it. We've seen it in action that was actually working super well. Yeah. And again, another thing is because you mentioned that the amount of changes is pretty high. It's pretty pretty pretty pretty. Relive is quite high. The volume is super high. Like the tool needs to be performance, you know, it needs to complete the scans in like in very short time. And then it has to be able to run like with thousands of scans per day. So like asking that from a young company, I think you should be one of the buying criteria. Right. Like can you reliably put up with our change pace that may actually 10x from the moment we get you to the moment where you know, it starts working for actions. Yeah. Yeah. So like it puts high demands on the vendors as well. Yeah. Because all the changes happening, you know, the volume of changes that are happening. And then the other thing is, I think, you know, you mentioned that. Yeah. Well, there is a lot of, I mean, who doesn't love that or remember who loves that? Did it ever work? That's a good question. Now we talk about a lot about like automated access service management and discovery and so on. But SaaS provides you a theoretical feedback, right? In theory, it should be like this. Yeah. But we do need some revolution. I feel like in the AI pen testing or AI surface discovery space, I think AI SaaS is there. Yeah. The rest solutions that work well. Yeah. If they have the features that I described, maybe some more features coming soon, you know, it's very quickly evolving, evolving. But AI pen testing or AI does, I feel like it's still very generic. But I feel like AI could be a right solution for this problem because you need to be able to say that theory and you need to be able to meet theory and practice. Yeah. And then in theory, it's good in practice. Oh, it's not so good because the agent has an agent solution that deploys 200 agents tries to break your app, broke it. Yeah. And then it knows where exactly it broke it and gives you a screenshot and then you can quickly follow up on this, right? So you need something, not just giving you a there is a vulnerability, but you need a screenshot or you need something to run the code execution on your computer and be like, Hey, here is a screenshot. I got I see your credentials or I see what you do in real time or I got your service as a sage keys dumped and something like that, right? Then that's that's real feedback. And then you call the loop. Yeah. Because so SCA is still relevant, but the volume of SCA increases, I guess, but I guess maybe that may not be that dramatically different. Or is that also evolving? Do you point about the volume of SAS? She's increased the volume of SCA is also increasing? I also think SCA is the most maybe one of the most overlooked surfaces, especially in the age of AI, because I just posted on my LinkedIn recently about me asking AI about, okay, what is the good library for PI? I sent itization and go and gave me a library and said it's actively maintained. And then I went I went I checked it on GitHub and the last commit was eight years ago and the library had three commits already. Yeah. So it was literally somebody pushing the first commit is create a repo, right? So there was two more commits. That's it. Right. That's right. Yeah. So like and that's the supply chain problem, right? How do I trust?
that my i brings the right package into the play, there is the whole thing with dependency confusion, right? Two similar package names. You just, oh, I know there are some researchers that prove, and I think they were at Blackhut recently, that they have a cruel method of generating package names. So if you know that your company, your target company, uses a package name X, you can generate a name that in 1% of users, or in some low percent, but not 0% of the AI invocations, AI installs of this library will be confused, and they will, they, they exactly that library that they created and prepared and put on NPM, registry or somewhere else, will be downloaded. And that was, that's a scary thought, right? So like the whole, what happens after, like that's for security teams to lock down and manage, and how to avoid that. So there is, that's, that's a very large surface, and then now it's extended by skills. Yeah. And are there any other marketplaces? Your point is third party as well. This one just that the code that you, so we were talking about product conscious developers, engineers, all that using code generation thing, but it's also SCA from I am using a AI tool that has a third party, like you pointed skills that is used, or I'm using a SaaS service, which is used for observability that has a AI capability as well. They're, they're extension of AI now, not just from a SCA open source library being used in my code, but open source library being used in my third party, which is also AI capability as well. This is like complexity in that in that context as well. I'm curious in terms of approaching, like, we spoke about a CA SaaS desk and the volume of increase has this happened. How should people who are watching all this through this? How should they, they should they make their teams, they've set up a team AI, start using cloud code skillset all of that, she start addressing the volume, or do you find that because it's, I'm trying to think of a way for because most people have the mandate for hey, just show me a increase AI usage in your team. And we spoke about the use case part, whether it's the right use case in order, but in this particular scenario where the volume is quite high, is that a use case for people to start considering AI capability in their teams? As like, if I have an abstract in today, is that maybe the direction that I should encourage them to use start using some of these AI capabilities to do this? Or is that the wrong approach? I mean, I think the answer will be the same. I think the approach is slightly wrong. It will be more like, I think you should ask the question, okay, with with existing tools and humans in the loop, or people we have with existing expertise, can we do something about it? Yeah. If the answer is no, absolutely not, we're getting over around, it's just like we're drowning in the alerts and everything, then you're like, okay, let's look for a solution. And okay, is the solution to bringing you to, sometimes they're super good tools for that particular case? Or you can of course start building your own thing? And I listened to some of your previous podcasts and then like, were you guest of telling about the tools that they're building or like the agents that I think with Calab who are saying okay for the vulnerability management and so on, and then it works and it patches everything. Like that's a great use case, right? I would encourage, you know, when you feel like, okay, you're dead end and your management is like, yeah, let's use the AI, but you're drowning in alerts and you're like, I have no time for this. But also like you put from both ends, like start experimenting, right? What is the most, what takes the most of your time? Is there a way like, could you describe it as a problem to an AI agent? Yeah. And ask for, okay, how would you solve it, your AI agent? Or is there a way like, right? Yeah, I don't know, bash script, let's start with a bash script, like go simple. And then you realize, okay, there are ways to solve it and then you run against product, again, some, maybe not production, but some subset of data and you realize, okay, it helps me. And then you can find your own way. It doesn't have to be the tools way, it doesn't have to be forced, AI use it's way. I really love how recently the conversation changed from, hey, let's put MCPs into everything. And now it's like, oh, let's not use MCPs for everything because there are some super good CLI tools that AI is already very capable of using and they're much more deterministic than using MCPs that sometimes run, sometimes don't. And you know, there are some troubles with that. Same thing here. So like use CLI, use regax, use whatever you know, you know, you were the skilled one. And AI is just tool to solve this problem. That's right. And yeah, and I'm likely at the end of the day you'll converge to you building some AI agent that uses the mix of the things and probably maybe buying some tool for part of the problem. That is too heavy for you to solve here. Yeah. Do you actually do you end up using AI, whatever you yourself as well? Like I think do you end up using, oh, obviously, but there's productivity or whatever the case may be because there's a lot of thinking on the fact that the future workforce is AI fluency should be high is the word all of people use where the team AI fluency should be high. The leaders AI should be high. Yeah, yeah, I mean, you I think like how to drive the AI adoption is actually of course not through the pushing and down people's throat. But through the tooling, right? Through the ecosystem that you create internally in your organization. So what you need to do, you need to have a lot of good skills, good connections, that good primitives that people can use with AI when they tell their AI agent, hey, go grab me a log logs from my development server or go grab me logs from our observability solution. But you have to be that right? You can create a skill that performs the analysis of the logs and you can be just like saying something like, okay, I'm investigating this incident. Please, you know, just follow up on this IP where do you see it and tell me more? Tell me more, I need to know more, I need to know this particular cases for its usage, where and how and what. And then it goes and it figures it out for you. So for instance, we do have an incident responder skill, right? When we get some some suspicious alert from our soul or something, there is very there is an easy way to trigger an agent to go and investigate it and bring back some results for you. And but the skill needed to be created, the connections like the data connections needed to be made, the MCP servers sometimes had to be built. Yeah. And I think that's the overlooked part. That's like that's non-sexy work. Yeah. That organization usually like, yeah, let's just put co-pilot or something into everyone's environment here. But then what is it connected to? What it can do? How people use it? And another is another thing is educating people, having those knowledge sharing sessions where you tell, okay, here are the skills, here's how you can use the skill and here's what you can extract out of it because it's much less deterministic. Yeah. Because AI uses the skill. Yeah. And then you realize, oh, the combination of these three skills allows you to actually build like almost like AI incident response, right? Yeah. And similar with any other skill. So it's like it's ingredients, it's unique. And then you get like a new nice dish and you're like, okay, I want to recipe of the dish. And then you put it like, okay, this is one of the team's recipes, right? So I think it's a nice way to think about it. I mean, that's the new wall run of the whole multi-agent world as well. Because you start with the smallest problem for I just want the agent to be able to go talk to say, eight up your sense case and get the latest audit trail information for this particular insulate. It could it could be a simple use case that and then you go, okay, so it can do that. Now, we add let me add another layer. I want you to tell me about SV buckets as well or a Google bucket or whatever. Yeah. And you start building this still little ingredient list, slowly. And you start seeing a pattern for, oh, wait, this is technically a response to if there was an incident in the VS, I would want it to do this recon and give me the information. I think to your point, that's where the sub agent people are, I'm running multi agent block. That's where that comes in from. Would that be fair? Yeah, yeah, absolutely. But I there is a common pitfall here. And a lot of as we're all engineers or many of us are engineers, we like sometimes we tend to like more complex solutions because they're more technically beautiful. They're like, I'm installing the entire class of problems. I want to have my AI agents running super autonomously solving all those problems. And you try to do it and then you you spend a lot of time on something that you know, you maybe don't have to spend time on it. And I hear a lot of like people jumping from using NOAA to having something completely autonomous, solving everything. But like in between there is so many niche like those for us the air pockets for those air pockets within your organization. There is so many niche use cases of AI. You can use it securely solving the problem, bringing the value. And I think we should we should like what is that curl walk run? Yeah, I know just like go run and then like fall and then you know, it's all like miserable story. And then you're like, okay, let's get rid of the AI. Let's go back to how we were before. I'm glad he said this because I guess maybe I want to find a question on this is if you were to start and I get you gave some good examples of where people can think about using this. Are there any obviously hundreds of AI tools out there? Have you found any favorites of the moment that are good for good. I imagine even similar to the developers of product managers that are similar skills sets in security as well. They would be advanced. So AI users, medium AI users and probably some people are just like in that beginning stage of oh, my scene is going to make the skill. I'm just going to use the skills and that would make my life easier. I'm just a productive just a good thing. You find that there are it could be a it could be an AI tool or it could be an ASC headset or it could be a use case that you find that people can start experimenting with or wanted to use cases. We spoke about the instance response as a use case. Are there any because there is the governance aspect as well for people over there? There is appsec as well. There is security as so many more. Are there any other pockets of security where you found that AI could be useful and any skills set the
do you think were helpful to build that? - Yeah, I mean, I think all the areas, because like each team works differently, right? If your team has challenges with addressing SaaS findings, let's say you have a SaaS, but you still have to verify the findings. Like I would create a skill, a set of skills that pretty much helps you verify the findings. And what you can do is actually go to GitHub comment, fetch that comment, then build the app and try to exploit the, or like, try to confirm that it's a real problem, right? So the same thing that would a real security engineer would do, they would try to okay, in my like test environment, okay, if that works like as a tool saying, I need this permission, I need this user, I need to perform this request here, I can do it. If you equip it with skills to send a pair, request to your test environment, read the logs, and so on, but like, you see, the complexity is not in using AI, not like adding AI, the complexity is in creating those skills ecosystem, like all the infrastructure, AI infrastructure, that is needed to actually reliably confirm, or perform that action. And we just looked into one pocket there. This is just confirming SaaS findings, investigating instant responses, or investigation and instant response, surely. Let's see, we just recently had the case where we like send the S-Bom, yes, that's the thing, we send S-Bom to a bank, and then they can back okay, you guys, like this vulnerability, we want you fixed, and we're like, okay, well do it, no problem, because, but come in, there are some issues that they wanted to be addressed, and we run, we had the skill for AI to run the reachability analysis, and then we're like, okay, I mean, it's not critical severity, something, but I mean, it's good to take care of this, right? It's like just maintenance, good maintenance effort. So that reachability analysis is a good example, and you can have something like running out, almost eventually, right? You can get all their reports from SCA, then you do reachability analysis in some cloud VM, where you can't even try to exploit things, you can go as far as possible, but thinking about AI as just the tip of the iceberg, everything about the infrastructure below it, and ability to give you the ability to access, good access, not all around access, but good access to use tools, MCPs, you name it, right? It's all in code, use bash on your computer, maybe not, that depends on the skill, that all come, you need all of that, and then it becomes like, okay, this is our superpower. But before that, it's just like populistic thinking, like here is a simple solution to a complex problem, what can go wrong? - Yeah, I mean, I've got so much more to ask you, but I think I might have to do a part too, 'cause it's like, I'm just going to start tying, 'cause I know you need to go back as well. Maybe I'll ask the, I've got three fun questions as well, but I definitely promise you to do part two for this little thing, that's definitely required, there's a whole other set of conversation about security for AI we've covered, but they haven't done the AI for security kind of thing. So we need to come back to it. But the three fun questions are good. First one being, what do you spend most time on when you're trying to solve the AI security problems of the world? - Outside of work? - Could be outside of work, yeah. - Well, most time on, well, I spend most time as work, 'cause fortunately, or fortunately, they're better, fortunately, because I think, I'm like, I think a lot of people who work in this AI first companies would agree that, like, we work a lot, not because we are forced to. - Yeah, a lot. - It's so much fun, it's like, oh my god, you see the world changing, like, at your feet, and you have also the ability to influence. And that's the most incredible thing. So I'm like, I'm almost don't want to do much outside of it, but also, like, you know, we're all human beings. So like, when I'm tired, for instance, or when I'm like, okay, I can't go anymore, I need something else, like, what, like, I really like doing something that has to be zero-interact, show value. Zero, like, like, turning my brain off. And for that, I play some online shooters. You know, I just go online, I put it out my PlayStation, and I just play some battlefield. So, yeah, and I'm not good. So if you see some bad battlefield player, that could be me. - Yeah, yeah, yeah, I mean, I'm a little free of handle. Second question, what is something that you're proud of that is not on your social media? - Wow, that's a hard question. I mean, I'm not super active on social media. - Oh, I'm like, I would love to be more active there. But it's like, I just see, you know, like, all the focus, I would think to be not to be on social media as well. - Yeah. - Proud, proud, no. I mean, I think I'm proud of my team. I know it sounds cheeky, but like, the team we got, and like, the people, I get to work every day, and like, in the security domain, at the level, they're just the most inspiring and crazy people ever. And like, they just like, such power houses, all of them in their own unique way. So I think this, you know, like, the field, and like, this kind of building, being in that molten core of this field, attracts some really, really interesting individuals to it. So I mean, I'm just so looking at all that experience, saying that I'm trying to learn as much as possible. And like, in both technology and like, just human way, you know, and I'm getting inspired every day with every interaction. I mean, that's just something crazy. - Yeah, awesome. And finally question, what's your favorite restaurant or cuisine you can share with us? Wow, what am I, I guess? - I actually really love that. I love all the food actually. Like, when there is company events or something, I say I eat everything. So yeah, you love it. It depends. - Are you saying rich cuisine? - Car and favorite. I mean, my favorite cuisine is unhealthy food. Everything that's fried, you know, deep fried, you mean comfort food, is that it? - Yeah, the comfort food. I love burgers. I love the good burger, good serve. I'm good. Good Indian food. Like, I mean, there is more healthy and less healthy Indian food. But the one that is like greasy and you know, just you full of the taste. I always take butter chicken or something. Like not just the chicken myself, but the butter chicken, given butter. Yeah, I just go in all the, and of course not doing it too often. - Yeah, yeah. - But yeah, awesome. And we can people find and connect with you if they want to know more about the work you're doing and everything else. Link chin, whatever. I can obviously put the links for it. But where do you know me hang and where can we put find you and connect with you? - Right, I promised myself to do a bit more like LinkedIn posts because I think there are some things I'm seeing in the field that are worth mentioning to others. And like probably, okay, I guys also seeing that or am I the crazy one here? So I will be more active there. And yeah, I think that's a good place to follow me. - Awesome. - I'll put that in the short, but thank you so much for coming on the show, man. - Yeah, thank you for having me. Thank you. Thanks for tuning in as well. See you next time. - Thank you for watching all this thing to that episode of AI Security Podcast. This is part to you by techriot.io. If you wanna hear or watch more episodes of AI Security, check that out on a securitypodcast.com. And in case you're interested in learning more about Cloud Security, you should check out a sister podcast called Cloud Security Podcast, which is available on Cloud Security Podcast.tv. Thank you for tuning in and I'll see you in the next episode. Peace.
Podcast Summary
Key Points:
Traditional security and development frameworks (like CI/CD pipelines) are being overwhelmed by the rapid pace of change and increased output enabled by AI, reaching their limits.
Organizations must intentionally balance the trade-off between speed and quality/security when adopting AI; prioritizing speed alone compromises security.
Effective AI adoption should start by identifying specific, low-risk "air pockets" or use cases that solve real problems, rather than enforcing broad, unfocused AI usage.
Limiting the number of AI tools and managing access controls is crucial to maintain focus, security, and effectiveness, as too many choices or excessive access can reduce output quality and increase risk.
Security teams need to become AI-fluent to both use AI in their own work and to create tooling that enables developers securely.
Summary:
The discussion centers on the security challenges and strategic approach to AI adoption in organizations, particularly for developer teams. Traditional security and development infrastructures are struggling under the increased velocity and volume of changes driven by AI tools, which allow developers to produce output at an unprecedented rate. A key theme is the necessary trade-off: organizations cannot maximize speed with AI while expecting to maintain previous levels of security and quality; intentional choices must be made.
The recommended strategy is to avoid company-wide, fear-driven AI mandates. Instead, leaders should identify specific, safe "air pockets"—contained use cases like prototyping—where AI can solve genuine problems without initial high risk. This builds value and stakeholder buy-in gradually.
Furthermore, it is critical to guide developers toward a curated set of AI tools and manage access intentionally, as too many options or overly broad permissions can lead to fragmentation, security gaps, and reduced effectiveness. The conversation concludes that security professionals must become proficient in AI to support this new paradigm, both by leveraging AI themselves and by building secure enabling frameworks for the workforce.
FAQs
Organizations should avoid rushing into AI adoption out of fear of missing out and instead identify specific 'air pockets'—safe, low-risk use cases where AI solves a real problem without exposing sensitive data. This intentional approach allows for gradual integration while maintaining security and quality standards.
Using a wide variety of AI agents can lead to fragmentation and security risks, as each tool may operate differently and be difficult to secure uniformly. Organizations should encourage developers to narrow down their choices to a few vetted agents to maintain consistency and enforce guardrails effectively.
Traditional security methodologies struggle to keep up with the high churn of changes in AI-driven development, where developers can produce changes much faster. This constant state of flux requires adaptive security approaches that can scale with increased velocity and complexity.
Security teams need to become AI-fluent, understanding how to use AI themselves and creating tooling that enables developers securely. They should focus on balancing speed and quality, ensuring security integrates seamlessly into AI adoption without creating resistance.
Access control must be fluid and intentional, as roles like developers and project managers overlap. Organizations should grant access based on defined use cases and needs, rather than giving blanket permissions, to maintain focus and security while enabling productivity.
Providing too much context to AI can reduce its effectiveness and lead to irrelevant or insecure solutions. Limiting access and context helps keep AI focused on specific problems, improving output quality and reducing security risks.
Chat with AI
Loading...
Pro features
Go deeper with this episode
Unlock creator-grade tools that turn any transcript into show notes and subtitle files.