Name: Cyberhaven Unlocked: AI Data Security
Uploaded: 2025-11-19T19:01:33.230Z
Duration: 43 min 40 s
Description: Cyberhaven Unlocked: AI Data Security

Transcript for "Cyberhaven Unlocked: AI Data Security": Hello. Hi, everyone. Welcome to this Hyper Haven ice unlocked, series of webinars. We are excited to, have you join and learn about the latest and greatest in cybersecurity and data security in particular and, in Cyber Haven, product. So today's topic is gonna be security for AI. In terms of introductions, I'm a CTO and the cofounder of Cyber Haven, and security for AI is my absolute favorite topic. It's, evolving very fast. It's, hard for any of us to keep up and follow. But at the same time, it's unlocking a lot of innovation and potential and productivity in our organizations, and that's some things that we are, embracing, here at Cyber Haven. So, today, we're gonna talk about, our view on how, security for AI, could be done today, what matters, how what what are the key pillars of it. We're gonna also show you some very cool and exciting demos about functionalities that we released in our products that all of you could use right today and access in in our consoles that give you some visibility and control and, of of what applications your company is using and what data goes to generic applications. And, we'll talk a little bit about the future, what's timing, what you will get inside the Haven over the next few months. So let me start by just walking you through how we at Cyber Haven view what enterprise AI security is about. I'd like to think about it in terms of three pillars. So first is, AI ops usage. So our, employees of our companies are adopting AI ops very fast, and, sometimes without really a lot of enterprise visibility or control. It's it does remind, how SaaS apps were adopted, you know, in the early days of the cloud by enterprises. However, with AI ops, I feel there is a big difference. First, AI app vendors are really incentivized in the storing and retaining the data that users put into this ops because the data is what enables them to train their models, improves their ops, makes them better. It's, kind of the oil of the AI world. So, unlike old school SaaS, AI ops often have tons of services that allow them to store and use the data. And and that's particularly affecting free tiers or personal tiers of these apps. Second big difference to SaaS is that, enterprise users, employees are being heavily pushed to use as much AI as possible by, you know, their managers. The CEOs are down because it increases productivity. So they end up finding apps, starting to use them as quickly as possible, often times without really working with the security team to make sure these apps are safe to use. All of that results in AI being adopted much faster and, with less control and with a lot more chaos around it. So, your security program must include, controls that give you visibility and also ability to control, to limit the usage of AI applications. That should include the ability to discover the apps that are being used, in use to do the inventory to, control, whether companies are whether employees are using personal accounts with ops or company accounts, and to get visibility into shadow AI applications, that may be used without enterprise knowledge. Besides just control and inventory, it's very important to, get accurate risk assessment of these applications. Questions like, what's the reputation of the app vendor? What are the, compliance standards like SOC two that they have or not? Right? And what their privacy policy is and the general data use policy. Are they gonna train their models on your data or not? Getting that risk assessment is, crucial to understand, which, AI application should be allowed versus blocked in enterprises. So that's your pillar, AI usage control. The second pillar is around data security. So what data is going to AI ops? AI is very data hungry, and, generally, users are incentivized to put as much data into AI as possible because it helps them with, you know, summarizing, understanding, analyzing data, driving, actions and so on. But, depending on the app in question that may or may not post security problems or compliance problems. So, we need visibility into what data goes, what types of data, what kind of regulated data goes into which AI applications, and ability to enforce governments, like prevent the AI from going into, SaaS applications, AI applications that are not approved for that use cases. Data security around AI is, actually becoming more complicated now as we are going into a genetic world as AI tools are offering connectors to data, including MCP connectors and other types of connections. Right? So today, all major, AI app vendors like JPGT, Gemini, Cloud allow you to connect, it directly to your data silos, to your, you know, Google Drive, Office three sixty five. And, with MCP servers, users can connect it even to databases and, like SaaS, IaaS type of applications. Visibility into that is, very important to be able to control the data flows in the AI world. Those are the first two pillars. And today, you will see demos of both of those functionality inside the Haven. So we will show you a dashboard that allows you to control and limit, the, AI application usage to do risk assessment and to control data as it goes to and through AI applications. On the MCP, we actually have a beta functionality that gives you visibility into all MCP servers in your company, including running locally by your developers. That's the thing that, beta, please reach out. We are looking, for for beta testers. The last pillar that is actually even more exciting to me is around agentic AI. So as we know, like, we are moving towards the. To help us create widely in the schools like Google or or or. And the is actually could be important in other So, Agentic is actually something that we at CyberHaven are, looking and, building security around. The questions in the genting.ai are, around inventory. You need to know what agents are being in use. Agents inventory changes much faster than up inventory. People spawn agents, turn down agents very quickly. We need to have visibility into access and permissions of each enterprise agent. We need to be able to control prompt injection because of the prime vector of attacking AI agents. And finally, we need to have visibility into what agents actually do with the analytics around their behavior. I'm gonna, talk a bit more about this. And, I'd like to make a point that, actually, AI agents in many ways are similar to humans too. And dealing with AI agents' security is not so different from dealing with inside the risk management. Of course, there is traditional application, posture management around it and data security and so on, but, it's, with with with with how agents behave. They actually behave like an identity on its own. So the classical, threats we have was inside the risk management. Like, we have malicious insiders, negligent users, misled users. They map very well to what we see with AI agents. Malicious insiders become malicious agents. For example, an agent could be running in your environment, through some supply chain attack or, like, planted intentionally. It was intentional goal to do some, something bad, like, to steal data. It could be misbehaving agents. Misbehavior could be caused by misalignment or hallucinations or, you know, just bugs in the agents. And they could be compromised agents, because of prompt injection that is unsolved and, won't be solved in in in the near future. Prompt injection allows, attackers to really take control of, agents running in your environment and makes them do, unexpected things like stealing your data. That argues for, like, the worlds of, DLP and IRM and agent security to merge. And the the that's how we're thinking about agents inside their haven, and, that will dictate our future product road map in this era. So, with that, I would like to, hand it over to Sean who will show you some cool and exciting demos of today's functionality. Awesome. Thank you very much, Boba. Share my screen. Hello, everyone, and thank you again for joining our webinar. My name is Sean Daley, and I'm a customer success manager over here at CyberHaven. I've been able to see firsthand how AI adoption has exploded recently along with the need to secure AI data. A customer's biggest challenge is visibility and control. A security for AI dashboard is designed to give you that clarity, focusing on three pillars of AI risk, which is apps, data, and users. First, let's find out how to navigate to the security for AI dashboard. I am in there now. Usually, when you come in, you'll be in the risk overview page. If you click on the home icon in the dashboards in the top left over here, and then you click on Security for AI, it'll bring you right into the Security for AI dashboard. One thing that I'm gonna do as well is I'm gonna adjust the amount of data on the look back to ninety days. To do that, if you go here in the top right and you click on ninety days, click apply, That is gonna change all the tiles to ninety day, to a ninety day look back. You do also have the option for dark mode, whatever your computer preferences are, or light mode. I'm gonna leave it in light mode for the purposes of this webinar. Alright. Let's start with apps. This is where the journey begins in understanding which AI applications your employees are actually using and what risk profile they carry. Speaking of risk profile, it is important to understand what this is. The risk profile is generated by Cyber Haven's AI powered risk IQ for GenAI apps. This evaluates each app using a defined set of security factors and assigns a five level overall risk, which is very low to critical. We train the model based on publicly available data scanning AI websites and other public research, data on each application, and we have 800 plus Gen AI apps that we are continuously monitoring within the security for AI dashboard. You will see the risk profile and the number of apps on the tile on the left over here. So you'll see the number of apps right here. You'll see the risk profile, critical, high, medium, low, very low. I can click on any of these to adjust only to that risk profile if I'd like. And then if you click back on the tile that you just selected, it'll bring you back to all apps and all the time frames that you're looking for here. You also see the actual risk profile within the right tile. So looking at the actual app name over here on the right and the risk profile right here, one thing that you can also do is I can click view more here at the bottom and get a larger view of the most used AI apps. In doing so, you're gonna see the AI application name. You are gonna see the risk profile for that application. You're gonna see the amount of users using that application, the amount of data flowing between, or between the user and that application, the usage over time, and then this will open up into the risk overview page as well. One thing that I I like to do is adjust this to the critical only. So if I wanted to see only the critical apps or the most critical apps within my environment, I can click on this little icon here to filter, and I can click on critical, click apply, and then I'm getting a view of only the critical applications. Now that I'm here, if I wanna deep dive into one of these apps, as an example, I'll deep dive into deep seek for right now. If we click on deep seek, it's going to bring over a slide over, and that slide over is going to give you the information for the risk summary, which you're given as critical. I can hit read more here and read everything that I want to on this page. But what I can also do is click view full assessment and get the page in one view. When I do so, it's gonna bring you into a page like this. What I can do here is read what's going on and the reason for the critical here. So DeepSeek's overall risk profile is critical with significant systemic weaknesses identified across all five risk categories. Those risk categories are data sensitivity and security, model security risks, compliance and regulatory risks, user authentication and access controls, security infrastructure, infrastructure and practices. If I wanna see any of those, I can drop down here into any of those categories. I have the drop down arrow arrows for any of these if I wanna read the risk summary and the reason for the critical that we saw at the top. Just know that you can go to any of these and see the drop down, but if you want to export this as a PDF, I can do so here. The way that I look at this, if you're interested in a new, AI app as a company or you want more information about it or you even wanna send information to anybody within your teams, you can do that by exporting as PDF. One thing that we have as well here under the AI apps under deep seek is I can go into the risk overview page. Clicking on this shield icon here is going to bring me into a page looking like this. When I go into this page here, I'll see risk overview overview here on the left. I've got the datasets. I've got all of the matching events. I've got the destination, which right now we're only looking at DeepSeek. I've got the AI apps as a category, which DeepSeek is under, and then I have users over here at the bottom right. As an example here, if I wanted to, go and look at one person, if I wanted to look at Steven here, I can click on Steven's name. I can click on events, and then I'm driven only to the events that is related to Steven. As we see here see here, we have the sensitivity. We have the dataset. We have the severity, the policy. One I one item that I'll come back to is PII here. I'll show you another tile that I can deep dive into Steven again with just a certain dataset if I wanna only look at one dataset. Alright. Next, let's move on to another critical component, which is the data. We need to know what sensitive data information is being shared and what new data is being created. This top left chart is a major red flag for any security team, and it's going to track the unprotected sensitive data that violates your existing DLP policies and is being sent to generative AI apps. This includes things like source code and PII, and you can hover over this graph here to see all the information related to those applications. This top right chart tracks how much sensitive data is being created by the Gen AI apps, and it shows where it is going. And you can see all that information again by hovering over the line right here. Let's scroll up. This bottom left chart is giving you a real time picture of your enforcement actions. The dash line shows a number of events and incidents observed. The shaded areas are giving you a breakdown of the security response. The red area is showing the instance and full policy violations here at the bottom. The darker gray is showing the policy responses where Cyber Haven's platform is automatically blocking, warning, monitoring all the data based on your rules. Being able to see the volume of block actions proves that the platform is actively protecting your environment. Finally, this tile on the bottom right shows you what kind of data is at risk. You can also view this in an enlarged state. I'm gonna click view more here at the bottom. And I'm gonna get more information within this tile. So I've got the dataset. I've got the sensitivity. I've got the AI application used, which I can hover over the eye icon here to see those applications. I've got the users, so I can hover over the eye to see the user. I've got the usage over time. And then, again, I've got that shield icon that we saw before. So like I said, when we were looking at deep seek, if I wanna deep dive into just a certain category or a certain dataset and this one's based on PII, I can do the same thing and click on the shield icon. Clicking on that shield shield icon will bring you back into the risk overview page. I can see all the datasets on the left here. I'm looking at just PII. I'm looking at the matching and or the corresponding policies. I'm seeing all the locations here. And then, again, I have those users. So if I wanna go back into Steven again, I can click on Steven's name. I can click on the events, and I can drill down to the PII events related to that dataset under Steven's name. When Pat goes on to his session after me, he's gonna deep dive a bit more into the data and the information that we're seeing here. Alright. Our final pillar is based on the users. Technology doesn't leak data, but people do. We need to identify their the key risk or who the key risk actors are. The user trend here on the left is showing the total number of users interacting with AI separated by the risk level of those applications in use. The red band highlights the users interacting with critical and high apps. One thing you can do on this dashboard is you can hover over these. You can also click on view all users. I can see all their users here in a list, and clicking on any of these users is going to bring you into the insider risk page over here on the left. This table on the right is your prioritization list of users. It ranks the top users by their interaction and their risk score. I can click view more like I did above to see this in a larger view. So now similar to what we just saw before on the tile to the left, we're seeing the user. We're seeing the amount of data. We're seeing the apps used by hovering over the icon again. We're seeing seeing all the events related to that user and then the most used dataset based on that user. And, again, if I click on any of these, users, it will bring me right into the insider risk page here. So this last pillar is answering the question of who is driving the adoption and risk so you can conduct targeted training or intervention. Last but not least, one of my favorite parts of the dashboard is if I want to look at only certain tiles here, two of my favorites are the most used AI apps. So I can star icon that app. If I come down here to most active users, for AI apps, I can star that one as well. And now anytime you go into the dashboard page that we saw before, it's gonna bring you right into those tiles here for those favorited icons. If you click on this dashboard icon here, it's gonna bring you into the security for AI if you wanna go there or back to the bookmarks. I'll go back into the security for AI dashboard again. In summary, Cyber Haven, the Cyber Haven security for AI dashboard provides an unparalleled three sixty degree view, turning the abstract threat of AI risk into actionable intelligence across apps, data, and users. We move you from I don't know what is happening to I know I now know the high risk apps. I see the sensitive data flowing in and out, and I can identify those high volume users. This allows you to enforce targeted data centric policies that enable productivity while ensuring security. Thank you very much, and I'll pass it over to Pat to deep dive even more into the data within the CyberHaven platform. Thank you, Sean, for going through the data protection for AI dashboards. Just waiting here to share my screen. Alright. Perfect. So thanks again, Sean. My name is Pat Collier. I'm one of the data protection analysts here at CyberHaven. What I'm going to cover next focuses on the risks overview page where we'll look at new generative AI application visibility within events. We'll also take a look at creating policies and datasets using our new GenAI conditions. We'll also identify enterprise versus non enterprise AI applications in your environment and we'll also use that distinction inside policy logic. So we'll walk through a few real examples using my own user activity, but first I do want to start back on the data protection for AI page here. As Sean had showed you guys earlier, there are a few sections in the dashboard where you can directly pivot to the risks overview page where we can see all of our historical file operation event logs. So there are several options in console here for pivoting to the risks overview page. If we take a look at the most used AI applications we can open up this widget And as Sean had walked through, we can use this badge icon here to open the risks overview. And I'll do that here for one of our applications for Google Gemini. So if I open this page, what this is going to do is it's going to automatically build a destination specific query using our Genai app name condition here in policy and it's going to filter that specifically for Google Gemini. What you'll also notice in the locations panel is we do have this new AI apps categorization as a location and we can also see Google Gemini listed there below. If we pivot to events, within the event metadata, we can see all of the data within the last thirty days flowing to Google Gemini specifically and within this metadata, we can also see the generative AI app name, which is Google Gemini, and we're also looking at some of our other regular metadata including the URL which is gemini.google.com, as well as the authenticated account to that web application session. So what I want to do with these two new attributes that being the generative AI app name and the AI apps category is walk through how we can curate some policies internally to look at sanctioned and unsanctioned and generative AI as well as look at enterprise versus non enterprise AI as well. So if I pivot to this view, I do have a few policies that I wanna go through and we are looking specifically at my user activity. What you'll notice in the location panel on the top right is I have been experimenting with quite a few different generative AI applications over the last thirty days. So whether this is me testing out different models, just exploring or comparing tools, I have evidence here that I have moved data to a variety of different tools here. Now what you'll also notice here is we are making a distinction between enterprise tenants or enterprise workspaces within some of these applications and the public or personal workspaces here as well. So you'll see an enterprise flag for applications like ChatGPT. You'll also see this for Google Gemini enterprise versus the regular instance of or the public instance of Google Gemini. And we also are able to measure those flags for Cloud AI, Copilot and Perplexity, all of which have enterprise and public or personal offerings. So we're able to do that with some of our latest browser extensions. They're able to read a one time global state variable to determine that the active sessions that the user is moving data to are an enterprise workspace, versus a public workspace. And you'll see that distinction here in both the sources and destinations of events. Now this distinction is very important because historically we'd only see flows to chatwt.com or copilot.com. We couldn't distinguish if these are our specific tenants or potentially secure environments. And as I go through this, I'll use CyberHaven as an example. Here at CyberHaven, we are sanctioned or our corporate AI security policy allows us to utilize JWT Enterprise and Google Gemini Enterprise. We purchase these services, right, we pay for these services because they are or they state, right, that they're single tenancy, they're encrypted, they have valid security controls and infrastructure, and because these enterprise versions do not, use our data to train public LLMs. So we want to ensure our employees are using these enterprise versions and our and tenants. We do not want them using all of these other AI applications again because we don't want to use personal or public GenAI tools, for the reason of not exposing sensitive data to public LLM training models. So what we can do, for policy, the first one I'll go through is, again, using CyberHaven as an example, is we want to monitor the usage of our sanctioned enterprise applications. I have a policy here called flows to sanctioned generative AI. This is primarily for visibility and for auditing, we can see what users in our environment are leveraging our sanction tools, we can see how often they're using them and also what types of activities or workflows generative AI tools are useful for in our environment. So with the flows to sanction generative AI policy, I can open this and edit, I'll open this over here. You can see we're looking at flows to sanction generative AI. The description or the purpose of this policy is to monitor flows to cyber havens, enterprise, CheckTpT or Gemini instances and I'll show you how I build this policy using four conditions. These four conditions will stay consistent across all the policies that I'll demonstrate today, so trying to keep it very simple. But when we think about policy, we are talking about data moving to a specific destination or a specific action occurring on data. And in this case again, we're looking at sanctioned generative AI for us which is Gemini Enterprise and Chattopty Enterprise. So with that new AI app categorization, we can specify a location type is an AI app, so the destination for our data is an AI app. And we can also use that gen AI app name condition which you can see here in the available policy conditions and attributes, generative AI app name, which is the name of those generative AI apps, we can specify the ChatGPT Enterprise and the Gemini Enterprise instances. In addition to that, our corporate policy requires us to use our cyberhaven tenant on these enterprise applications. So we can also use our cloud active user attribute which is the authenticated account to that web application at the time of the session or the logged in user to that account to also validate that our users are logged in with their cyberhaven.com account to our enterprise tenants. And in addition to that, we'll look at specific actions, so we're looking at copy and paste and upload actions which are the traditional actions we'll see going to web based, tools. So with a policy like this, we do get visibility now into all of our user activity. This is just specific to myself, but all of my user activity going to enterprise tools that are sanctioned within the environment. In the destinations here, you'll see ChatTpT Enterprise and Google Gemini Enterprise. We can pivot to these events. What you'll see is over the last few days here, I have been doing some regular workflows utilizing these sanction generative AI tools. You can see I've copy and pasted data from Microsoft Visual Studio Code into Chatchp Enterprise. You can see that I was moving data from my Notepad endpoint application to Gemini Enterprise, some content from Postman to Chatchp Enterprise. So within the event metadata here, again, we can make that distinction, the browser extension is letting us know that this is the enterprise workspace application and also that the user is signed in with the appropriate account denoting that all of this activity is sanctioned activity in accordance with our security policy. So a policy like this where we're just logging flows to Sanction Generative AI allows us to see who's using sanction tools, how often they're using them, and for what types of actions they're using it for. Now from a DLP perspective, sure the sanctioned usage here is definitely insightful, it's it's great for visibility, it's great also for monitoring return on investment for large AI licensing or investments. But the real value here is preventing unsanctioned usage or monitoring unsanctioned usage. So we do wanna take a look at all those other tools or the shadow IT, the shadow AI in our environment that users are moving sensitive data to. So we can use very similar policy conditions to also create a policy looking at flows to unsanctioned generative AI. So this is going to be any, AI application that is not Google Gemini enterprise or ChatGPT enterprise within the cyber haven tenant. So I can edit this policy as well and show you how I've built this. Again, we are looking at flows to unsanctioned generative AI applications. We are looking to monitor flows to all JAI apps where the user is not logged in to Cyber Haven's enterprise ChatGPT or Gemini tenants. And so I can blow up these policy conditions again and I'm using those same four conditions that we had used before, with a little bit of variance here. So we do want to look at the the destination for data as being an AI app. We also, in this case, want to specify ChatTBT Enterprise and Gemini Enterprise, but this is for instances where the user is not logged in to our tenant. So it is possible for users if they have some sort of educational institute that they're a part of or some other third party organization where they have an enterprise license to another tenant that they could also log into that on their corporate device and we want to ensure that users are only logging into the CyberHaven tenant for these services. So we can say that when the user is not authenticated with CyberHaven on these applications, we want to know about it because this is unsanctioned. In addition to that, we can use an or condition to also look at all AI applications that are not our sanctioned applications. So the Genai app name does not contain Checkat gpt enterprise or Gemini enterprise and all the copy and paste activity to those locations. So when we filter down and take a look at this policy, you can see here all the destinations, none of these destinations contain the enterprise tenant that is sanctioned within our environment. All these tools are considered unsanctioned tools and unsanctioned data flows to generative AI tools. And if we take a look at some of these flows, what we can see here is the browser extension is making that distinction. It knows that this is a personal or public, workspace for ChatGPT. In this case, it's also giving us details of the logged in account, for that session. So I'm logged in with a personal account here that does not have a licensing agreement with ChatGPT. There's potential here for my data to be exposed to public training models, and we can prove that here with the generative AI app name and the login account. Now there are multiple applications that we can see here. There are instances where I am unauthenticated to Perplexity AI. There's instances where I am authenticated to Perplexity AI but it's still not the enterprise version, and the same thing for Claude and some other applications here. So looking at data flowing to these unsanctioned applications irrespective of size, all representative of potential data leakage risk, right, the capability for models to, you know, continually learn based on small amounts of information over time and also the risk that these models pose when they're found without, proper security infrastructure leave organizations open to a great deal of data leakage risk, which is why it's very important for us to monitor the flows to all generative AI tools specifically on sanctioned ones. Now another policy that I do wanna go over is our flows to critical risk generative AI apps. And as Sean had showed you before, we are performing risk assessments utilizing deep research from our own internal AI models to evaluate other AI models and their security risk. So we assign these risk profiles and as Sean showed you before, we can look at the applications within the environment over the last thirty days in which users have moved data to that we are denoting as critical risk AI applications. Again, for a variety of reasons, if they have historical data leakage, if they don't have the right compliance frameworks in place, there's a variety of criteria that we're using to evaluate the risk profile but we can also leverage this risk profile in putting together more strict policies within our environment. So depending on an organizational risk appetite, we can block all unsanctioned AI if we wanted to, But if you wanted to ensure that we were only blocking users from using critical applications and maybe low and medium risk applications are okay, we can do that specifically within policy. So what I've done for the flows to critical risk AI apps policy, if we open this up, is using those same conditions, I can specify those three critical risk applications that we had seen before listed here, to target them specifically. And in this case, I can create incidents so that all other AI tool usage, we are monitoring. But in the case that a user moves data to deep seek or deep swap, our SOC team gets an alert and they can triage this immediately. In addition to that, if we wanted to block or warn on the movement to any of these applications as well, we have that variability to configure within policy itself. So if we take a look at this policy specifically, this is going to filter down all the way to the critical risk applications that I've moved data to within the environment. So making that distinction based on risk assessments can be very very beneficial here in targeting some more strict policies within the environment. Now so far, we've looked at data flowing to AI applications but there's another equally important risk, which is data coming from artificial intelligence tools and the output, that those tools generate. So, one of the examples I'll go through is is especially important for something like AI generated code because as we know, AI models can be inaccurate, they can be incorrect, AI models can hallucinate. So when development teams are generating code via AI tools, these models can introduce embedded vulnerabilities. They can introduce, errors within the logic. They could introduce embedded dependencies or or whatever plethora of issues that have potential to be introduced to that code Without proper quality assurance for some of that stuff entering your internal systems or your DevOps pipelines or production environments, there is great risk in utilizing the AI output. So we are able to monitor that usage here as well. So using datasets, we can use those same GenAI app conditions to monitor the data coming from AI applications going to your other internal apps or systems. So what I've done in this case is I've created a dataset looking at AI generated code, and we can open up this dataset as well. And we can use that location type, that we used before for AI apps. So this is going to look at all data coming from AI applications moving to other locations within the environment. And with that, we can also combine this with CyberHaven's ability to perform content inspection on clipboard, data or download content. So we can specify that we want to utilize content inspection policies that will match the AI generated content for specific programming language syntax. So combining both the AI app location type and these content attributes for source code, we can easily identify source code being generated from these AI applications and view where that data is flowing within the environment. So for example, we've got that AI generated code. I've got a simple policy here looking at the flows to different endpoint applications. What we can see within the events here is there are multiple instances where I have gone to a variety of different AI tools. We can see the sources here, different variants of AI tools, where I am asking those tools to generate specific code and inputting that into whether it be an IDE or specific development related app. So in this case, I've asked Gemini I'm sorry. I've asked DeepSeek to generate, some code here, testing for CVEs, specifically Log four j. And I've copied and pasted that to Microsoft Visual Studio. You can see the same thing for Gemini, this is some JavaScript related to an API request that I'm utilizing in Postman, and there's also other instances here where I am using the Gemini enterprise instance to create an uninstall script and putting that into Google Docs. So this provides us visibility or provides organizations visibility, into the types of output that users are, utilizing within regular workflows. This can help to prevent, you know, unreviewed or risky AI generated code from entering production or DevOps pipelines. So all in all, we reviewed identifying AI applications across the environment using policy and dataset conditions and some of those queries. We did some distinguishing between sanctioned and unsanctioned generative AI applications. We built some policies for enterprise, non enterprise, and critical risk applications, and we did monitoring for both the AI generated outputs and the outbound data sent to AI flows. So all these capabilities are part of CyberHaven security for AI platform. You can incorporate any of the content inspection, warning, or blocking and monitoring capabilities with all these policy configurations to look at AI tool movement. And the hope here is to give organizations deep visibility and control over how their users interact with generative AI. If you guys are interested in hearing more about, some of the developments here for AISPM, feel free to reach out to your CSM. But that wraps up my portion of the demo, and I think we can hand this back to any questions we may have to answer live here. No questions. Alright. Well, I think this wraps up our webinar here. Thank you all for joining. We appreciate you guys listening to us talk about AI security, and we look forward to developing the capabilities moving forward. Thank you all.