
A quick show of hands like if you have if you like have to secure at least two or more co like AI coding tools in your work let's keep that up if you have to do it for three let's take it a little more higher four okay that's at least few of us have like the problem I'm going to talk about today okay so if like raise hands again of that four raise for four if you can if you're confident that you have them insecure like you can say they can't go rogue Yeah, that's I think we have a good like we can have a good discussion today. Yeah, let's see like why is the problem
right like these the AI coding tools they like spread across so many variants there was like a few years ago there were like copilots then came the agents like the agentic mode coders and there were like the flavors of them were like self-hosted basically or oss and there were like what now there are other flavors like there are no developers but they they are also capable of like doing the building the apps publishing it all the way right so they're w codings basically I just captured the top like some of a few like main main categories like and also this is little dated like if if if I if I got a chance today I
would have even added like the cheapot list chatbot which can build your python code if you have not seen that I think there is a there is a thread going on like somebody like uh showing that like there are no guardrails on that and it can build like there are various ways people can build code now so and like this is no more like say the olden days of like vormac right it's not even preference It's kind of like use cases are there like there are marketing teams who want to do like quick prototype and publish something or like there are like some of the use cases you want to run agentic mode as well or like some of the
times the regulatory restrictions you want to host them in house like you can't run on the public like models basically so the problem statement is like is it's a huge area basically for like that's why like we don't have the solution fully yet like yeah none of us could resend even I couldn't resign for the Uh before we go further um uh quickly about me, I've been I work as a security engineer for last 15 years. I would call myself a AI security student for the last 3 years. Like yes, it's daily learning for me personally. Uh I currently work for Cerra Systems. We have the fastest AI compute. If you haven't if you don't know what cerebrra
systems is like we have like almost 10x from the regular AI provider like something that would take like uh 60 seconds on our our systems the AI inference you'll get a response within like a minute within a second basically before cerebraas I was at co city I was building like securing the distributed data stores there before that I spent a long time almost more than 10 years in Juniper networks where I built like various type of network gear from like all the way to like firewalls to like uh edge like the core routers in the telecom space. Uh I was part of like most of these journeys. I was early security engineer there and kind of seen from all the way
from bootstrap to maturity and like I usually follow like two good and one bad. So I like yeah I did have like one of the fellow like I tried to get some book done but I could not get it done. So that's why like I like the talks that they are easier for me. uh I I'm not active on most of the the social media like social connections I LinkedIn I'm open like feel free to connect and if you want to follow up on any sessions so feel free to connect before some logistics I think we already did talk like slido can be used for questions or I can like be available after the session outside or like uh
I'll be a available in the career village tomorrow evening so for I'm open for discussions there like any opinions I give here are like mine and I do want I do like the besides because there is no vendor bias here I'm going to keep the same if I mention any tools I it is not my endorsement or critic it's just that the example used if you want to know my favorites or anything I can take off stage before I think this slide is like why I like decided to do this talk like when I seen this incident I decided like okay I need to I need to talk on talk about this and I like I decided like besides
is the good venue for it and like what's happening here, right? Like this is not malicious at all. This is like a user error kind of thing. And like what happened here? Somebody was running in a YOLO mode and they ran it from their home area and the the AI agent did a mistake here and it went and deleted their entire home area and the whole Mac was nuked. Imagine that this happening in like an enterprise setting or maybe like 100 100 users hitting this this similar this was one error but like similar there can be a campaign or something that's hitting and like 100 max are nuked and imagine your IT department basically that day
it's not one of there are like similar classes of the problems I'm going to flash few similar ones yeah this is like a code execution like the code injection kind of thing like we seen in the cursor. There are similar on a rule code extension. Oh yeah, I think I thought once I missed the prompt injection. This was a well-known prompt injection in the Amazon Q. Okay, there's I think I missed the border for this. But I just want like one of the other variant of is like I think this was seen in the the singularity attack where attackers use the AI tools in the machines of where they breach to like do further like like make
use as part of the tool chain basically. So like yeah the just want to show the spread of the problems. Okay, before that, yeah, that's like a 200 IQ kid. That that's what I call the AI coding tools. Basically, it's it's very very smart. You can ask it anything you ask it not to do something, it's it's going to if you want to find it. So, you put restrictions and it's going to find ways basically. It's going to say like, oh, this is blocked. Can I go this path? Basically, sometimes if you didn't in yellow mode, it's going to go and run it for you. So it has lot of skills but I think it still lacks judgment and it has
lot of power. Right now we have given it like we run it in like yolo mode only is like or permissions or it can like it runs in your machine it runs as you and it can read most of your secrets. That's one example of it. So that's the okay we now understand the problem right so let's take one step further like as a security engineer what we do right we have a problem we kind of threat model it I hope everybody here knows threat model what that modeling is and then otherwise there are a lot of good sessions in this besides happening on the threat modeling I'm take like there as you talked right
there are various flavors of the AI coding tools I'm going to take a a agent AI coding agent that's kind of extreme on the security side. So I'm taking that. Uh let's take a look what is an AI coding agent, right? It has like LLM as its kind of intelligence and it uses it for reasoning the use reasoning model for like thinking. So that's kind of the core of it and that can be your like say within your enterprise or it can be coming from like a third party hosted or it can be a there are cases where like random places also people are done like unsanctioned ones. So and it also does has like other tool
chains as well. And coming to the insights right it's going it talks to like user provides the prompt and it can read from the internal docs or your Jiraas various systems what you granted access to or if you don't grant access if you don't block it it's going to go and fetch those things basically and like it reaches out to the various web to like the it builds that like these training models have like cut off dates when it does train to if you want to get latest one it's going to reaches to web and like going to fetch those data unless if you restrict it it's it has access to the whole web basically and
there's another problem is like the third party plugins every every week there are new flavors of it was MCP then there there came like the plugins there came like the skills there are like it's it's every week is there's a new thing happening so it's third party risk is a major from the AI coding tools and it usually runs in a developer laptops and or the dev machines and it has full access to the local file I'll send the keys or it can run shell commands basically in most of the time privilege mode and after that the effect is usually like it generates the code that goes into like your internal SCM or like say as a PR change or it imports new
dependencies or new tools within your de machines and it installs like maybe npm or pip or like it can push into productions as well down as you see like through the CDCI or like other pipelines. Similarly, it can control your cloud as well. So this is like kind of a high level how it how the AI like agents looks like works. And if you see here like one other view of this would be like adversaries right like what can go wrong basically like as we seen like there are external attackers the those can be prompt injections from a external repo that a developer has to like understand what's happening in this repo that can have prompt injections basically that
can be in the comments like or like there are various other ways the prompt injection can happen or the dependency poisoning so I think early days of the coding agent slop like there was a new entirely a category of attacks started like slop squatting like it's just a hallucination the type squ type of squatting was used for hallucination basically so and similarly like a malicious insider right previously if you take an example like there is a insider who want to get a malware or run something in like an environment they had to go through a network pipe basically and firewalls usually caught that now like somebody anybody can like ask LLM Right? Like the good ones going to say no but
they're easy to jailbreak basically or people can host them as well. If you have internal hosted ones they usually they're not that good with like the guard rails. So they can build your malware in house. So it's not going to have your traditional firewall boundaries where which detects a malware coming in and block it. So people can build them in-house now or like similarly what we've seen in the case of claw deleting the home director at careless insider basically runs like false for prompt injection or code injections or like like sometimes runs like stupid like they should run in restricted mode they just run it like full free basically yeah like the AI agents can also be
compromised we've seen in the case of Amazon cur like the agent itself was compromised like we seeing like the skills and plugins are like compromised like these are similar to other third party code repos like they get compromised and if you're running them or you pull them and like you you will be impacted basically another problem is like a lot of the times we send the prompt out for the AI code or like there is sometimes the code goes out if the third parties breach or a SAS breach if they if you don't have the right data retention so your code or the your IPs are at risk so this the other side captures like I
already in the picture. So like the various interactions in this case.
So how how does this map from the threads to enterprise risk? Right? So a code can be like there can be like the compromise at the code level that like the human didn't review or human didn't approve can get into your like product code basically. So those can be a reputational risk for the company or like say your products even if you have like running some kind of SAS applications they may get breached as well. The next one is like privilege misuse or the trust abuse. Similarly the agent running in the full force can like go ahead and do something that the human didn't authorize. The another risk is like the data xfill. It can be both IP or the secrets to the
infrastructure that can be like Xfilled and like can be used to like attack your infrastructure. The supply chain attacks we've seen like very this is a very huge attack surface for the AI coding tools one all the way from the tools itself or the tools it like the dependencies it pulls in for as part of the code. So those is is like it's a very huge attack surface in the case of like agents like the accountability is another risk basically who did what is like is not easy to track on the regulatory side like if you have like a government contracts or you are like some of the third party that IPS you have you don't want to expose to the
the AI tools those are like if you mistakenly expose them like there are like regulatory fines and other things that also needs to be taken care on the other like the right side column most of them like these are some of the AI specific use cases attack surface that can turn into risk like autonomous execution can like some of the not authorized cases can be like a risk to the enterprise and these AI tools are nondeterministic by the nature so the traditionally like the security guard rails are kind of deterministic we can rely on them to work like a previous generation like of the guard rails were like having tools to tell through a like an rule files
right so those were like one of the early adopters like adop like production so those were like nondeterministic basically you tell the like agent to like behave this way but like those can be easily they usually bypass them and obviously like these adoption of these tools are so easy and like they does not need to follow like traditional like a huge previously like most of the if you if somebody want to buy a tool they have to go through like uh PO process because these things are like developer friendly somebody can put in their credit card and buy it for $50. So the sprawl of this across enterprise is huge and prompt injection I I do consider
fonts as a feature but like yeah this is turned into injection basically is is a big problem but it's kind of a feature of you can like you're not forced by the the system prompts like you want to change something like I I personally feel as a feature but like as a security person it's like it's like an it opens up a lot of attack circuits.
Yeah, I did miss one. I don't want like I don't I didn't wanted to capture that like the spending limits, right? Like the the early version of that was around 2018 like a SAS developer would say like oh I I I bankrupted my company because I left a EC2 instance running overnight. Now it's like a new version. and the wipe coder would say like I I bankrupted my company because I I let an AI agent run overnight and like with the wrong model basically thus yeah it's like in a summary like the enterprise risks are elevated because like adoption of the various flavors of the tools.
Okay like now we understand the risk like let's take a pause here and like let's take the next s next part of the session to see let's we can add some guardrails around it. I do want to call out like this is the best effort like there will be still gaps remain this is evolving area like I want to call that like even if in a picture you see that god is not good enough and even the human at risk there.
Okay, one more like exercise like how many of you here like oftenly almost every week get a request of a new AI tool to be added to our enterprise or like a model new model to be added or a plug-in to be added like yeah like it's it's a everyday problem now like I want this tool there is a leaderboard change like oh there is a new model like that's the top of the top of the leaderboard I want that too like oh you just requested that yesterday and you want that now new thing today that's this is going to be a it's going to be really painful ful going forward with this. So the one of
the approach is like define a MVP of the security requirement and if something that does not meet it does not enterprise like I know it's really hard but that's the best effort like to set like at least we have a baseline of the things that kind of aligns with enterprise. So this is like again this has to be like based on the enterprise risk appetite. It can change but I'm just capturing the samples of the areas that usually should be focused. One is like the tool should like align with the enterprise SSO and should have like MF and other IM guard rails that any mature the application will have like secret should be like usually like
how we how we provide the secrets like based on the scope of the task the secret should be like provided like in the scope and also like restrict the rest of the like it should not have like full access to the machine or like it should be like restrictable basically. Similarly like the another major area is like data residency and like your data should not there should be it should not be used for training or like if you have a strict zero data retention the vendor should like align with that. Similarly like the visibility right there is like at currently like lot of tools run without you don't like they do lot of tool calling internally they like
interact with various systems that goes unmonitored and like that's one of the major areas needs to be focused if you're bringing something like you should have for the visibility and accountability you should have those hooks enabled or the tool should provide those visibility capability so that you can hook into the enterprise space. So like usually like every major enterprises have sim so that like your saw can monitor what's happening if something going wrong they can like take action. So that even these tools should hook into that. We'll talk into like some of the areas later why this is critical. audit logging right basic audit logging and if forensic capabilities something go wrong and some for the some of the critical
operations it should always provide like capability for the human to like interrupt and there are like some of the AI specific threads like the model should be like it should not decide what model you will use if you have like allow you to configure the models you want and like it should like allow you to like specify which country the model is served from and like pin the model version they should not change like overnight like that way like you don't have the unpredictable behaviors. There are a lot of third parties like keep on changing every day. So it should give you the enterprise the control to like what we allow, what we don't allow and
what we pin to. Basically like we have seen multiple cases where like the changes in the back end or people can third attackers can influence the versions and like a good version kind of acts maliciously. It's the same problem we've been seeing like and we keep repeating like we have seen in the the code right we want to pin to hash but we pin to versions and people change the tags basically do different thing and we are seeing the similar stuff in various like the MCPS and other things we repeated but we want to make sure that we kind of align with the third party risk and the untrusted input boundary like models each model behave differently for
like prompt injections or each tool have the different guardrails and those should like like we should validate should have like some kind of continuous validation of those as well. And for the riskier like riskier operations the they should be like allow capabilities to run them in sandbox mode to like reduce the risk and allow like the humans to like take calls whenever there is risky operation needs to be done. Just want to repeat like if the baseline is set in the best case scenario like does not meet it should not allow or it should be tracked as an exception. Once we have like the MEP defined and like once we start getting the tools the
next step would be like making sure like they through their like whole life cycle they stay secure. So kind of like it starts with multi-layers like install first then kind of operationalize it can kind of four and six capabilities. So I'm going to cover in the three stages
after like once they pass the kind of a bare minimum security gate like next would be like kind of enabling them at scale. So like one one of the controls usually should have is like what code it can read uh and like all the like the if there are like regulatory requirements or like third party kind of like legal requirements not to allow some of the code. So those should have like capability not to allow everything basically.
Similarly when we deploy like in the in the MEP we say like these are the models that we want to use or these are the endpoints like a single model can be served from various endpoints as well right. So we want to make sure that we kind of roll out in the similar control that we decided this is the like requirement and those should be like enforced through the installation process and like the third party like which are like allow list them like we disalized those only should be like allowed to use and similarly like the privileges right we scored for like the privileges so those should be enforced as well and monitored continuously so they stay
within the boundary and also like when when you deploy they restrict them to like not to read the secrets like the the SSH keys or like the passwords and other files. I I'll show an example of it in the end of this presentation but like those well- definfined files like say Linux flare of it or it's a Mac flare of it or a Windows player of it those should usually be like restricted and like human should like authorize if agent or coding tool want to read them. The next controls for installations would be like the what code built by the AI tool goes into your code repo with like kind of like this is kind of a standard appetite
practice like branch protections, human reviews or the security pipelines. So those should be enforced and all the AI agent should the fetch your like repositories from like the third party packages from your internal internal proxy not from the internet to allowing it to like pull malicious packages. The another major like the main point would be like to integrate into the existing security ecosystem. One is the IM or the SSO so that like it's easy to onboard users or like offboard them and similarly like send the logs to your existing SIM and like some of these agents like have high risk like then they should be like part of the EDR they should be monitor from your EDR
and we do have seen like the the coding tools or like the AI tools CLI tools you being used by as an tool chain from the attackers. So it's good practice to monitor them through DDR.
Once we have installed and rolled out like then the next stage would be like kind of keeping them secure in the like like operational like wherever there is a risky these agent mode like we want to run without like say some cases we'll need to run without like human intervention right so or like a low kind of human intervention so those should always be considered for like some kind of sandboxing based on the risk it can be VM container like there are various ways to do it so those should be considered and also like they should not have unin uninterrupted network access. They should be all like allowed listed to like read from some of
the web pages or like say your internal pages and some like that you trust for documentation other purpose and usually they should not be allowed to send data out then like say your code repos or like your internal deploy pipelines that not like random to the internet and if there is a like usually like these they have settings at where most of these controls would be like enforced through settings. So usually those like configuration should be monitored. They like many times like these agents have seen is like they like somebody want to bypass them like they provide the like oh I'm blocked because of this you can go ahead and change it to the users and users accept that and it goes
and like drifts from its config like that's been a very common trend and like the prompts right like it's a good practice to monitor what users are putting in like maybe secrets a lot of people take take and dump it into the prompt that may have secrets it may have your customer info or your critical IP it's a good practice to monitor the front for like any sensitive data or to make sure like your IP is not leaked or your secret is not leaked and also the network basically monitor what's happening the very important like I think I want to highlight like the developer training of the securia usage going back to the cloud case right like it was a it was
mostly a human error where they ran it in their home directory which is usually is not advised that kind of like each tool comes up with best practice if you are adopting something and make sure that the whole user base knows like how to use it securely and even the com it's good to like uh train people what is the common best practices do and don'ts with the AI coding tools
continuing the like life cycle of the AI agents right one is like once we do install then like like we are maintaining it but there is governance as well like in the AI I generated code should always be treated as a third party not as a first party like whatever the policies you have for a third party that should be kind of like followed not treat it as a first party because it's always can be influenced by somebody like maybe training or like there as you seen like the supply chain can be compromised so usually treated as a third party code and like most of these tools like they do have like maintain the provenence
like AI generated but they allow like humans to bypass them it We've made practice that like we keep the provenence like this is AI generated or AI assisted code instead of like humans overriding that and putting is my code that should practice should be practiced like previously like now it's getting adopted people are okay to tell it's AI assisted generated previous like maybe a 6 months ago or year ago like people were like oh I I don't want to use that they want to be like avoid it but now it's getting a mainstream that people are okay to like keep that provenence but it should be kind of like monitored and and enforced and also Like these models like some of
the like this is very widespread of tools right like the some of these have tend to like bias outputs if you have like front-facing like to like web pages and other things it's not you you should always monitor if there is bias of the material generated so and like if you monitor those like should be like corrected as well. Another another part of is like be ready for any incidents like if you deploy the AI tools like like a lot of people try to jailbreak it because it does not align with what they ask it to do and like there are a lot of jailbreaks published people try to like need to monitor and those should always
be like zero tolerance and or other other way of that is like people use the the AI to build malware other things internally. So those also should be like carefully monitored and like taken like zero tolerance policy applied there and like another part of the incident response is like have run books for some of the very specific AI tooling AI coding tooling cases like if there is AI vulnerable code got generated and like your it got into production what happens right be ready for those scenarios those are getting very common now or like somebody put thing in the prompt and it got leaked maybe from the third party breach reach. So needs to be like
handled those as well and like outages right like these tools go down and like if you have like automated pipelines how do you manage those basically and like even the patching of these tooling right if you rolled out to thousand people how do you patch those because these does get very often CVS like there is common injections or prompt injections or like or the third party risk so these needs a constant patching so the runbook should be like ready to patch handle those as There are very specific licensing issues with like large adoption like say a AI code may take a licensed code and put it as like a piece of code within your like first party code. If
you just take like a license as a file level thing it does it may have loopholes basically. So you need to apply the pet level oss license validation as well if you're using AI to AI for code generation. And also like track the versions and support timeline like you may end up like like these change like support timeline change for these tools very often if they like if you're unsupported you need to make sure that you maintain those as well and the model updates like the the older models usually tend to have some like the guardrails issues. So you need to kind of keep up to date with them as well. Another thing I just highlighted the
last point like we seen in the like meme right like the high usage rates like these tend to like maybe within an hour sometimes they may end up like consuming around like thousands of dollars of tokens basically there has to be guard somebody doing a human error or like a agent going like not rogue but like getting into loop mistakenly and going out of like spending a lot of money. So those also should be like have controls around that limits enforced.
Okay.
I just want to like go through one of the samples of like how does this look like some of the things right like I'm going to take a example of Claude here. I do want to build this uh in the next few weeks to like all the major uh major tools and publish it but I target was to get it by today but I could not get it done but I do want to like at least take one example of how does it look like? Uh I think I'm not like how many of you use like a manage settings for claude if you if you use cloud. Yeah, it's it's a really good control like at a large level how you can
enforce a lot of these guard rails basically forcing a mode it operates in like um yeah this is kind of disables the yolo mode that's one of the dangerous mode I think they even have like they the cloud calls it dangerous mode basically and it does not allow people to run in that mode at least when like you can enforce that in the restrict like some of the critical environment ment. So like this kind of another another like lot of the common problem is like people use the enterprise but they they want to mistakenly like they use their personal tokens personal login which may not have like say like the data may be used for training it may not have
similar guard rails as your enterprise plan has. So kind of this helps to like enforce those like those limitations. There is one more problem with some of these tools right like the the permission fedig. So this is one of the like ways to like kind of like some of the riskier operations to allow by default not for prompt so that like it kind of people read the riskier commands permission prompts and not just allow it basically. So that's one of like balancing between security and usability kind of wins like take the security like win for the security like if people kind of come out of the the permission fatigue and read through and like allow.
The next block is kind of like ask permissions where like is to like get the riskier ones like make sure the human review it before they approve it. These are some of the fall is like where these are like maybe kind of not dangerous but there's a possibility somebody might have like put in a secrets in some of these files or like the the the it's pulling in a package that we don't want to see. So all those things like push it for a human reviews and there are like some of the things we don't want the AI tool to read right or want to do basically like rm command or like reading your secrets basically. So like
those can be like put in here like this is like my this is my paranoia list but like based on your like risk appetite you can add like as like control this list basically. Another one we talked about like proxying the package import through like allowed proxies. So that would be like something like this. It will pull the packages from the way like you want the organization to follow not from internet. The other one we talked about like the prompt not having any secret. So this like this is a deterministic way of like reading like a secret from like making sure like it does not follow a pattern. and s like another way like pushing the
all the all the commands like all the tool usage basically all the actions the tool like the AI tool took like auditing. So this is kind of the the operations that we kind of get out those audited. Some of the like allowing the third party like how we want to allow and force various methods would be like the more configs can be added to like control the third party plugins and other things. So this is a sample and like the the earlier version of it would have been something like it's mostly intent based the cloud would have been the intent based not deterministic u the this is rule file like cursor and all the all the coding agents support
this right like where you tell it like not to like read the various things follow like like not not read my direct this read this don't read it because it's my third party and like like don't read the secrets. Similarly, how we have in the manage settings which enforces this is kind of like the intent based mode. This is an interesting case I observed was like you add in a hook like it used to suggest people to like bypass it. This is kind of a secondary guard to like how it was giving options how to like kill the hooks basically. So this was one interesting case I found some time ago. and kind of enforcing how the code
generated kind of enforcing your like security as secrets DLC practices you want claw to follow
a sample hook how it will look like right I'm just taking
We'll come back for it. Okay,
it's basically shell script pattern matching. Uh, okay. It's fine. I'm going to go back. How the time Okay, we have time.
Okay. Okay. Ready? Yeah. Once I think we do have some idea of like we discussed that like kind of define and like minimum like viable security requirements kind of like how to enforce it kind of it will be a plan like define your minimal take enterprise risk kind of define a security requirements that all the agents should follow and then like the next auction would be like kind of like validate existing tools right like you may have the open risk like those should be tracked as exceptions and then like build like an enforce secure by default guardrails that can be like enforced to the some of the tools that to make sure like the risk from
these are kind of acceptable like usually the ownership of like security requirement should be with the security team and like like validating like existing tools and other like inventory should be like engineering security I think it should be much more that's a mistake for me like it's not only engineering there are marketing tools various departments now even the sales everybody has like AI coding tools now. So that it should be entire enterprise basically and kind of sorry the guard rails would be like between security and your platform team and like sometimes like even the many to involve like where is your procurement team as well so that would how it will look like just want to call
out like this is a existing problem like I think most of you acknowledge that and it's just that like we want to like get that resolved thank Thank you for everyone. I think I do have some time for the questionnaire.
>> Thanks. >> All right. Thank you very much. We actually have three questions on Slido. So, uh thank you very much for those who have submitted their Slido questions and then after that we can ask some uh live questions in the room if you have those. But we'll start here. Uh Slido, let these be voted on. So the top voted question is besides OSS license question should we worry about restrictions on forbidden LLM use cases in licenses? Can you repeat that? >> Should we worry about restrictions on forbidden large language model use cases in software licenses? >> Yes, I think it's been seen like at least uh it pulling in the packages. It should be your pipeline downstream that
verifies. There are cases like it pulls in the packages it want making it align with what you accept is on the like you to make sure that it like you have the guard rails for that like you some of the cases like say GPL may be okay for like use some cases but how you use it ll the the AI tool does not take care of it that's on you to make sure that you enforce that >> awesome thank you next question how do you monitor prompts is that automatable or manual. >> Yeah, prompt like some of the tools do provide the capability through hooks and other ways like where the prompt can be intercepted and monitored for various
rules you want to enforce. Most of the at least the the top tools at the moment do modify that but some of them don't like uh which are like kind of web based right so they you don't have any control on those so they don't have those capabilities but some of the front or the main coding agent tools do offer those awesome thank you um third question on the slideo can you share some real world examples of badly written vibe code introducing malware vulnerabilities or data leakage that enterprises have had to address. I I wanted to capture >> sorry uh just one quick moment guys slido is anonymous so we got your reputation feel free to drop the question in slido.
>> Yeah sorry go ahead. >> I think that there are like various I think we have seen right like the w like really really messy w coded apps I I wanted to capture that I could not find in time. There was a very good example of like a web web form where login form it shows like I sent you like the token like say six-digit number sent you to your number basically it's showing like I sent you like 1 4 5 6 7 that number reference in the form and it it's and that was one of the example I think it happened in one of the enterprises few like not a major one but a new startup somewhere they
built an app and like it was there basically Kinch of not showing it in the front form which does not serve the purpose of MFA like I sent you this token through this SMS like or your number it just displaying up front that if somebody got your password they can just use that up front and get in. Yeah, there are like lot of cases that wipe coded apps have been like have the really bad security posture and there are more I can I can discuss like I think of of not here. >> All right. Uh, we have time for live questions in the room. If anyone here in the room has additional questions, >> I I have a question.
>> Yeah, let me bring you the mic.
Thanks. Um so the MD file you you showed on the screen it works for one or two devs but when an enterprise has hundreds or thousands of developers having these files on endpoint like on the developers machine itself um or potentially vulnerable itself because let's say that they know they download an open source tool um or package and it has cursor skill file integrated into it that can potentially you know bypass all the controls you have on the >> um on the on the client side right so how would you scale this >> yeah there is uh many of these tools have like hierarchy and I I just want to repeat like the the rule files is not
deterministic or it's not like a enforcable thing or like most of the enterp like is at least in the last few months like are going to deterministic kind of hooks or like this manage settings as shown right those are kind of enforcable and the the rule files itself can be like you have a hierarchy of those where you push it in a various first path like say at least in the I'm just taking example of flot here like you put it in the etc like the in the Linux etc cloud code and the hook that would be the highest precedence next comes like your working directory and then it goes to usually your project directory it has the hierarchies
basically like the prompt injection is still like a problem but like if you have right guardrails the probability of that gets reduced from the top down the preference top down I think other tools also some of the other tools also cursor and other supports that but like it but it's not universal though like some of them like only rely on what's in the like the code or your repo or the working directory basically so yeah some of the top ones does have like hierarchy ones that enterprises can force and the some of them like it's Actually, >> that's a good question. >> Another question,
>> sir. On one of your slides, you mentioned uh the need to track um all code that has been touched or generated by AI systems. But over time especially in a large enterprise I would assume that eventually all code >> yes >> is touched or affected by a output >> in how would you do this tracking as third party code and what kind of different security controls would you in practice apply in this context? >> Yes, I think the the idea is like at the moment like the I think that's a near future where the AI code would be very perfect like I that like that state we are not in right now. So right now like
there may be various ways why we want to treat that as third party but maybe in the future where AI coding tools can be like build secure code like all the controls we can have till then we reach that state it's good to like track them like as a third party and apply your controls how you will treat a third party code kind of it's a it's a temporary feature till we reach the like ideal state any more questions all right hearing none Thank you. >> Sure.