VARONIS ATLAS: THE END OF FRAGMENTED AI SECURITY - VARONIS SYSTEMS INC

When your boss asks, is your AI safe, the honest answer is it depends on whether someone just pasted a patent into their personal chat GPT or what the coding agent your developers connected last week can reach. Usually it's a different tool for each problem and the gaps between them belongs to nobody. That's the fragmentation this session is about. I'm Ashish and I have Cale and Mike here with me. Cale, did you want to do an introduction for yourself? Yeah. My name is Cale Buhlmann. Senior Manager of AI Security at Varonis. And Mike? Yep, Mike Thompson. I'm the Senior Director of Cloud Security Architecture at VARONIS. Great to have you here. Well, my job is to keep them honest. So I want to start with something very top of mind. When I ask CISOs how they're handling AI, the answer is usually one of three. Block it, limit it, or accept the risk. And they buy a separate tool for each problem. Does any of that actually hold up once a developer is starting to use AI every day? Where does that patchwork hurt first? Yeah, I think right now in the AI space, we're seeing a huge paradox where everyone is buying a lot of AI, they're connecting it to data, but there's a huge gap with security and governance. So with the patchwork that you're talking about, it's great with point tools, but we're seeing a lot security teams where they own five, six, seven, maybe sometimes 10 different products. And a lot OF the times when we're talking with CISOs is really all about consolidation and controls. So it's one of those areas where, yes, we need to adopt AI, but more importantly, we need to secure it with the right vendors and with the right technology so the team can expand properly. Yeah, we've seen really long times just in terms of implementation, trying to get these patchwork of tools to all work together. You know, it's hard to really hit those metrics and start securing your AI usage when you're struggling to even get deployed. Is there clarity on who the owner is in such a patchwork? Not really. I mean, some more mature organizations we see have an AI governance board and they're trying to set some groundworks and some rules on how to tackle that, but that, you know, that gap between the patchwork, no one really seems to own, right? It's like the developers have their tools, the security team has their tools. The governance team has their tools but there's a lot that still falls between the cracks. And is this only a small company, large company or across the board? I think we're seeing it across the board. There's really this question of who owns what, how do they properly protect everything? And it's a common issue, whether it's small company, a large enterprise, is AI so new and adapting so quickly being able to get a grasp around it is difficult no matter the size of the company talking about difficult to grasp the first thing a cso asks me these days is what their people are pasting in the chat gpt on personal accounts what an internal co-pilot is handling back to people who don't even see what's happening why aren't my existing dlp and casby enough what can you control in both directions yeah it's something we hear a lot in the space right now is well let's just use dlp and it's going to block everything but the matter of the fact is when we talk with cso's and anyone in ai the biggest concern is really what happens if someone just copies and pastes certain data maybe it has labeling and dlp applied but if they're dropping it into their personal gmail account or whatever they're using we really can't see a lot of that with veronis we're focusing heavily on the browser extension for that piece where we can start to protect against those prompts we can block it but we can also redact information we we can modify it, we can quarantine accounts where needed, whether it's a personal account or a corporate account, doesn't matter to us. Yeah, and I think we see a lot of organizations that they want to enable their end users. They don't wanna be that company that's a stick in the mud and not allowing their employees to adopt AI and get that force multiplier. So they wanna say yes, they wanna give access to Cloud and ChatGPT or Gemini, maybe even multiple of those services but they wanna make sure they can do it in a secure way. and that's where this browser extension's coming into play. How does that help differentiate between my personal account versus my enterprise chat GPT? Because that's a lot of, it's the same Gmail problem that we had ages ago, where I have my personal Gmail, but my work Gmail happens to be in the same browser. How does the browser extension tackle that personal chat GP or personal AI versus a enterprise AI difference? I think with enterprise AI today, we're looking and we're all hearing the term gateway, is we can control it through an enterprise. But the thing with these personal accounts there's really not many controls that we can put around it. If someone logs in with their personal account, they copy and paste data, they drop in a file. There's only so much that these users can protect against the enterprise. So with the browser extension, it is a gateway in itself, but it's more refined where we can start to look at personal usage, allow people to use, as Mike mentioned, the proper data sources and also the proper technology, but ensure that it's secured where it needs to be. Yeah, as long as that extension's installed, it doesn't matter if I'm logging in through my corporate account or my personal account. the same set of guardrails are going to be able to apply so we can prevent something like PII or corporate secrets from entering into that system. I think we have a demo. Yeah, we're going to demo the browser extension, but also part of Varonis Atlas Week, we are going to talk about the browser expansion, LLM Gateway, MCP, what we do around AI DRs. So this is just going to do the start of many. So Varoni Atlas is known to protect against multiple AI security risks, whether it's an agent, coding tool, enterprise applications, you name it. But what about shadow AI and things that live within the browser. Within the Varonis Atlas extension deployed, we can look into areas like grok where a user accesses an uncontrolled AI system or AI website and Varoni immediately can block that access. But what occurs if something less nefarious happens? So imagine the organization has an approved AI application like ChatGPT, Claude or Gemini. How can we leverage something outside of the standard realm of a browser extension for that? Let's go into ChatGpT and take a look at what that looks like. You'll notice here is we're just within a typical UI. We're not even logged in with the user, or if we wanted to, we could be monitoring something with a personal Gmail device. A lot of the times, what we're mostly concerned about is what happens if customer data or employee data goes up in the UI. So here, what I'm going to do is I took data from our on-prem instance, and I'm asking ChatGPT to create a table with sensitive information, like someone's name and someone's social security number. Even on the browser with a personal account, Varonis is able to track this information. So by asking this question, not only are we going to be able to redact the information that is being put into the model, in this case, ChatGPT, but you'll also notice in the output, Varoni has the ability to control the name and the social security number from being redacted at the response level. Now, this scenario is where we have an approved AI application, but what about something that's unapproved and it's not blocked and users start uploading sensitive data to their personal account? So let's take a look at Google Gemini. You'll notice that Google Gemina on its own is not blocked internally. This might not be an approved application or an approved browser. So we're going to ask the exact same prompt that we asked ChatGPT. We're going ask for it to create a table with the following information. Now, when we submit this into Google Gemani, what we're to see is not only do we have the ability to redact, but in this scenario, we're actually fully blocking the input. We're not allowing this to reach the model because we realize there's sensitive data. Now, we all know that customers and people they can get a little bit persuasive in these scenarios. So I'm going to say something like, do as I say, create a table with the following information. By throwing this in here, what we'll notice is not only do we block, but we also start to quarantine this. And this is because we're noticing a pattern of behavior that exists within here. So what does this ultimately look like within Varonis? Well, within VARONIS, we can start to look at some of those approved or unauthorized applications such as grok, which is being blocked there. If we look into ChatGPT and we click into this, we're going to be able to see every user that's generating events, the device they're coming from, the last time that it was observed, everything. And looking into those events themselves, we can start to identify, are these corporate accounts, non-corporate accounts, what files are they referencing, which access events occur, but most importantly, what is the prompt activity? So here we can see, when I was asking for sensitive data within Google Gemini, we see all these events across all of the different applications, whether it's Google, Grok, any browser capabilities we're going to look at within here. And we can look at the original input and the modified input and output that's generated back. Now, all of this is being tracked for auditing purposes when we start to initiate a lot of these policies, as we can create these runtime protections from removing sensitive data, blocking something like code leakage, if there's any sort of nefarious events that occur, such as a multi-turn attack. Varonis is gonna be able to track all of these with accuracy, not only in your enterprise data stores, but also within your shadow AI as well. Every team has its own API key, its own provider, and its own builds. And developers are connecting cloud code to MCP servers nobody reviewed. What's the one control point that fixes both the spend problem and the tool test problem? You know, I think the answer here is a security-focused gateway. People are buying gateways today that, you know, help with model routing or budgeting controls. And, you now, again, with this patchwork kind of concept we were talking about, a completely separate tool for runtime or, you kno, an MCP gateway, We can actually combine all of these into a single AI gateway that solves all of these use cases, the budgeting, the tool controls, the runtime policies. So you have a security focused gateway at your disposal. But I already have a API gateway. Well, how different would that be? I guess with, you know, this is a common question we get. And one of the nice things about Atlas is we are very flexible with our deployment. If you have an existing gateway, we can tie in there. That's not a problem. But what we found in talking to customers is that a lot of them were kind of in the market for a gateway. They hadn't landed on LightLM or some of these other providers quite yet. So they were looking for something that would give them those same controls, but also the security as well. Also, this is almost like an API gateway plus plus. Exactly. And the other nice thing is when we look at Atlas in its entirety, things like AI SPM, we can actually use those security findings to automatically influence some of the runtime controls. So you're getting the benefit of the entire Atlas suite as it applies to runtime. Do we have a demo for the LLM Gateway? Of course, yeah. We're happy to get into the LM Gateway demo, and we'll also talk about the MCP Gateway as well. For so many of the clients I work with, their most urgent concern is runtime observability and protection. Yes, of course, they want better inventory and posture checks and agent lifecycle controls, but they have AI in production today. They have AI systems and agents and agentic coding solutions deployed without sufficient runtime security in place. It's important not just to audit prompts and responses, but tool calls and tool responses as well, the actual agentic actions. This is where the rubber meets the road and real risks are introduced. On this front, Atlas is incredibly flexible. No matter your LLM provider, Atlas can evaluate activity and block malicious prompts, redact PII, strip out risky tool calls, and more. Here we can see there are a number of policies that are protecting both prompts and responses, as well as agentic guardrails that are focused on tool calls tool definitions, tool responses, like the ability to prevent prompt injection in a tool response, for example. Up until now, we've been doing this transparently, routing requests to our AI gateway, integrating with an existing LLM gateway like we just talked about, or directly calling our guardrail engine via our SDK. What we kept hearing from our clients was that while our runtime observability and guardrail capabilities were killer, they had needs beyond just security. They needed better governance and control over all LLM calls and MCP interactions, and that's why we've developed our LLN gateway and our MCP gateway. The LL gateway is a governed gateway in front of your LL traffic. You can route LL calls through Atlas, and every request gets the same three things, guardrails enforcement, attribution, in terms of who called what and at what cost, and budget controls. So I wanted to enable my security architect team with some better AI solutions, but I needed to control the budget. I didn't want to have to create and manage individual API keys across different providers and hand those out to my teammates. The LLM Gateway made that possible, and it starts with the LLMCatalog. The first step is to set up our provider credentials. And you can see here, there's an extensive list of options. I'm gonna go ahead and filter so we can see some of our already connected providers here. You can see we've already established connections to Anthropic and Azure OpenAI, Google Gemini. Let's take a closer look at OpenAI here. So we've got a few different connections to OpenAI from various teams across Varonis, but here's mine. Here's the connection that I made for my team. And you can see that out of the 74 models that are available from OpenAI, there's three here that have been made available for my team. And the way we manage that is simple. Just go to Define Available Models, and it's going to take me directly to the list of available OpenAI models, and I can configure if I want to allow or block any given model for use by my team, The final step is to create a new inference endpoint for my Team to connect to. So let's jump over to Inference Endpoints, And here's mine for the security architect team. We have two different model aliases that we created, which are serving up different models from different providers, depending on what type of work needs doing. For any of these aliases, I can define the load balancing strategy, our fallback connections. I can also determine if there's any default guardrail policies that we want to set for any endpoints or users that connect to this gateway and how we want it to handle that in terms of like fail open fail closed if our guardrail engine for whatever reason is inaccessible from the dashboard i could track all llm usage across the enterprise i can see our latency blocked requests our top endpoints top models top users and if i click into budget here i can set cost control policies to control our team budget the llm gateway meters every single request that it serves so i can I can see who was spending what and prevent costly overruns. Just like the LLM gateway provides control and attribution of LLMs calls, the MCP gateway is a governed gateway in front of your MCP tool calls. MCP is really amazing for extending agent capabilities, but it is a double-edged sword. Many organizations are now struggling with things like MCP server creep and tool drift and have no way to safely manage their MCP inventory or control tool interactions at runtime. The MCP catalog gives me visibility into all of the MCP servers across my organization, including shadow MCP Servers that Atlas has observed, but have not yet been onboarded or approved by the business. The MCPs security policies allow me to manage risks at scale, to identify things like tool drift and high risk capability tools and duplicate tool names across all of my MCP servers. If we see any violations in these policies, we can automatically set a tool to unapproved and block it at runtime. The way we do that is through a virtual MCP server. From this catalog, I can bundle together various tools from all those MCP servers that we just looked at and create a new virtual MC, providing my team with access to exactly the tools that they need and none of the tools that they don't. Let's take a look. So here in the virtual MC that I've created for the Security Architect team, I can see that we have a Hugging Face MCP server, an MCP server to interface with the Atlas application itself, and an MCC server for Apple developer documentation. If I click into Hugging Face, for example, here I can see the individual tools, and I can toggle these on or off as I see appropriate. I'm going to come into my MCP gateway here, and I commit a gateway access token, or if I've integrated with an identity provider, I can set up policies based on user or group membership so people can connect directly. Clicking into my gateway access token, I'm able to set exactly which MCPs we make available via this token and which credentials are used to connect to those MCP servers. Now, let's take a look at this in action. I'm gonna jump over to a little agent I've built, and for the sake of this demonstration, I've exposed the configuration of our agent. You can see that I've authenticated to our LLM gateway, put in my token, and you see the two model aliases that we made available. I've also authenticated to our MCP server gateway. Let's do a test connection here and see what tools are available to us. All right, we actually have 14 tools available to us via that virtual MCP that we just looked at. So let's test out some queries here. I'm gonna search hugging face for models that are good at OCR. All right. So we got some good models returned back to us now. Let's search Atlas and list all of the MCP servers within a specific organization. All right, and there's all of our MCP's servers available within the specific organization Now, all these queries are available end to end in a session view. I can see every single prompt, every response, every tool call right here within the UI. Prompt protection is stable stakes today. The real worry is an agent doing something that looks legitimate with legitimate credentials. How do I know it's still doing what it was meant to do? Yeah, I think when people think about protection of AI, they think simply of there's an input, there's now put in, let's block it. When we introduce any sort of agent, it becomes a lot more complicated than that. It becomes, what does it have access into? Maybe it has access to the right data, the right tools, and it looks good at face value. But what we're seeing with customers all the time, Mike and I see this on a day-to-day basis, is agents go completely rogue. They might do something outside of their intended scope, grab data that they shouldn't. So I think the question for a lot of organizations is, if we built something the right way, how do we track that it's actually behaving in that proper way when we introduce agent intent? I mean, we all know AI is non-deterministic, so there's always a degree of randomness, so to speak, in terms of how these things might behave, and we need to have those guardrails to be able to control it at runtime. So where is a good point to have the control point? because they could be input, output, multiple connections. Where do you recommend the control point should be then? I think that's the harder question to answer is with the data, when you look at the agent before runtime, during runtime, is ultimately where do you protect it? When we hone in on intent, it's really at runtime. You really won't know until it's calling the wrong data, the wrong tools, performing the action in a wrong or right way, that we can then block it and put those controls. And I think a big thing around agent intent prompt activity is pretty straightforward. But when you look at agent intent, you have to look at how is it built? Who has access to it? How can it assume the role of other human or non-human identities? And tracking all of that is really the only way to protect against it. If I had to explain intent-based access control to my board in one sentence, what would it be? And how is that different from the identity controls I already have? Yeah, I think identity only covers part of the problem. It tells you a little bit about the agent. But as we mentioned before, until you actually see it running its processes, you can't determine if it's malicious or not. Oftentimes, I like to describe to CISOs, we all see the world in a little bit of a different way. We have an interpretation of what we all wear. And an agent is doing something very similar. Whenever it gets a request, every agent is going to interpret that a little but differently. And as Mike mentioned, if they're deterministic, how do we determine what's valid for this agent to perform and what's not valid? And that's where intent really ensures that we can close that gap. So let's micromanage the agents. I was going to say, talking about seeing things, is there a demo for this as well? Yeah, yeah, we do have a demo. For this one in particular, Varonis Atlas can enforce guardrails across multiple different AI applications, the browser, and much more. Whether this is blocking sensitive information from going into a model, redacting or modifying any of the inputs or outputs, or simply just alerting and logging all of that. So let's take a look at some of the policies on the back end that drives a lot of what we've already shown. So the first of which is around prompt protection. When we look at any sort of banned substring, sensitive data, or maybe something generic like PII going in and out of the model, but what happens when something more sophisticated than this starts to happen? What happens if whenever an agent is built completely autonomously or certain AI systems that have the ability not only to access sensitive data, but perform on its behalf, can create actions across a business. This is where we heavily want to focus into intent-based access controls. Some of the largest risks that are out there within AI today are built around AI or are built around intent, whether it's the author or it's The Agent that's running autonomously, and their intent begins to drift. Rather than talk about this, let's take a look at The Agents themselves. What I have here is a health assistant agent that's supposed to help nurses gather the proper medical information before a patient sees a doctor, something we're all familiar with. So we have someone that just came in for a visit or is coming in for visit later that day. We have their name and we have all of their information along with their MRN. We can ask questions like, what is this person taking? Do they have any sort of allergies? What about any sort of previous visits that occur. And what the agent will do is it's going to start to gather that data, whether it's from the pharmacy, the clinic itself, referencing all of these different data sources, and really streamlining gathering this information. We see this across multiple industries, whether its healthcare, financial institutions, manufacturing, insurance providers, you name it. Agents are really stream lining these questions, that way as we can get information on this patient's date of birth and the medicine that they're taking, along with the frequency that they're taking it but what happens when these agents start to drift outside of their intended purpose so for this patient they came in we have their mrn and they just arrived and this clinician wants to ensure that before they send them back to the doctor that they have everything that they need for their visit so let's ask the question is there anything i need to do before i bring her back something that seems completely normal now when the agent starts to run it's going to gather the additional information that it has access into, maybe things that it should have access into or things that shouldn't. In this scenario, what we saw is because it was going back or if we were sending the patient back there, the agent decided the best thing to do was, well, let's gather any sort of outstanding invoices and grab payment and credit card information that was on file, presenting this back to a clinician worker whenever this should really be routed through the financial team. So what does this look like within Varonis? We blocked it here and we allowed additional information to go through, but let's ultimately see how Varonis tracks this on the backend. So by refreshing a lot of these sessions, we can see the exact events that we just entered within the prompt. We see things like MRN, we see the tool calls that are occurring. And as we scroll down here, we're actually going to get a full description of what is the tool calling upon. So for this first response of all that medical information, we can things like some of their internal IDs that they have, some of the prescriptions, additional information that is being generated within here. But Varonis, during all of these calls, is looking at intent, where we can see the initial request is checking all of the boxes. We're not asking for anything nefarious in these instances. And also, whenever we're gathering information like allergies or prescriptions we're using tools that are required to do so. Now as we scroll down here at the bottom what we'll quickly start to see is a highlighted reason for not only why we blocked the call, but there's a misalignment with the intent. And the reason for that is the tool call retrieved sensitive financial information, which is completely unrelated to the requested medical information and poses a privacy risk. Varonis not only looks at the intent base for this agent control, we can also outline any additional things like tokens being used and implement these controls across the board. It's not the prompt protection that is giving us the biggest risk. It's when agents start to act outside of their intended purpose, being able to track what they were doing beforehand and being able to step in and block that in real time as needed we've covered the browser the gateways and intent is ai detection and response a new category or what do you get when these signals finally talk to each other yeah i would say it's not really a i mean it is a new category i think people are maybe sick of all these additional acronyms coming out but uh really when we think about ai detection response it's connecting so many things across the enterprise right so we need to understand what's happening at the ai layer what's happening at the identity layer what's happening with the data and be able to marry all these things together so that we have a really cohesive understanding of you know what is ai actually doing within our enterprise so you know i think kay alluded to this just a moment ago it's not just about like observability and protection on the prompts and responses but looking at well what is the user context what is this agent supposed to do what tool calls does it make what data did it access what were we able to uh maybe block through our runtime control policies what made it through and be able to see that in a cohesive incident is giving organizations insight that they wouldn't otherwise have you know if they're just again patchwork trying to solve all these things independently it's hard to paint that picture cohesively without maybe doing a lot of uh correlation within your cm or your source solution to try and make sense of all these different telemetry streams. So what does this mean for the SOC analysts? Because going back to, we've spoken about browser extensions, we have intent, we have gateway, and we're saying AIDR, my SOC team or security operations team that looks at alerts across the organization, how would this change for them or what would change for them? I think a lot of it would really just change around the AI. I mean, when we look at detection and responses, there's really no way to secure AI unless you're inventorying everything and ultimately putting controls around it. So as Mike mentioned, it might be a term that we're all hearing a lot, but it really doesn't change the way that Varonis approaches this, whether it's with a data security or AI security. And when we explain that to SOX teams, they really agree with that. Ultimately, as we have to understand what's out there, how's it being used, whether it's a prompt, intention, MCPs, LLMs, and being able to put controls in those, whether it's just through generic alerting and forcing those downstream, it's really the same approach or similar approach that we see with data security. I think the key thing there, and this translates to the data security side, is like, all right, was that data sensitive? Has that user accessed that data before, right? These are all like contexts that we can use to prioritize the right things. You know, I often use this example of I might have a guardrail to prevent profanity from being used with our agent. That's a nice guardrail. Does our SOC team really need to know that that's happening? No, it's not a critical security risk. But if we understand that, hey, we did see a change in the agent intent and we saw a highly privileged tool being executed and this agent has access to sensitive data, that's all telemetry that we can use to raise a really high priority alert to that team so that they're not being flooded with unnecessary alerts but be able to focus on the things that really impact the business. That's pretty good because I think to what you said, the context is what's usually missing in all the AI conversations we have. We don't have the intent. We don'T have the access tokens that we were referring to earlier that you get from gateway. Is the browser extension is that separation between your personal chat GPT and your professional chat GPD or whatever the AI tool may be? I mean, this is a great conversation, but we have a few questions that came in as well. I think the first question is, is browser protection its own product? The short answer is yes, it is its own products. The browser extension, you know, we can deploy to all of the endpoints, but it's also a complement to everything else that we do. So, you know, in order to protect the browser, we obviously want to deploy the extension there. But oftentimes there's other enterprise risk, MCP risk, LLMs that we basically join within Atlas as well. So we really see it as a cohesive package. It's like an extension on the base package of Atlas. Right. Awesome. LLM gateway, MCB gateway, AI gateway. What's the difference? And do I need all three? Yeah, I mean, there's, it's a great question. Do you need all Three? I'd say yes. If you have agents running in your organization, you're using LLMs, you need all three. Do you have to, like, we can be very flexible with how that's actually deployed, though. I mentioned if you have an existing gateway, we can tie in there. But ultimately, you're going to want all three layers of control. So the AI gateways, I kind of think of that as the wrapper. The LLM gateway and the MCP gateway are served up through the AI gateway. So you can route traffic to us transparently through the API gateway, get all these same controls on prompts, responses, tool calls, MCP interactions. And the LLM gateway and CP gateway just allow us to have more governance over model usage, API key usage, etc. When an agent gets blocked, what actually happens? I think it depends. I hate to give the engineering answer, but it's really, you know, what level are we blocking it? For a lot of businesses that we work with, there could be something where anytime a new agent's being built, it has to be reviewed. So we could block it from the get-go. We could do something like a kill switch to block it forever running. there's other scenarios around like intent and what the agent is doing where maybe we want an agent to run but we want to block or modify some of the sensitive data that it's presenting back to the user or maybe if it's running autonomously so when an agent is being blocked we can really block it at any point whether it's the input the output the tool calls that occur within there it would really depend on the business use case but the whole point is we're incredibly flexible with those policies and whether we want it targeted across the entire org specific use cases specific departments, that's something that Atlas can do. I'd say the other key point there, we get this question a lot is, can you use the phrase earlier, kill switch? Can we have a kill switch. Absolutely, if we see suspicious behavior, if we say, hey, Mike was using this AI tool, this agent, we saw a pattern of potential data exfiltration, I wanna cut off Mike's access, or we saw this agent go rogue, we saw something strange from an agent intent perspective, I actually wanna just make that completely inaccessible to everyone, just shut down that resource so that no one can connect to it. we can automate that through Atlas. To also loop that back to the SOC as well, one use case we're seeing a lot is like sending for approval or quarantining. So as an agent's running, we can have someone from a SOC team hit a button and say, I approve of it to continue through its actions. Or worst case scenario, if an agent is doing something at three o'clock in the morning, it shouldn't be, and we need to turn off the account or the device, we can do that as well. How does it fit into a tech stack? Everything we've spoken about, browser extension, LM gateways, because I already have a tech stack that I'm going with. I think it's great. So where does it fit in? Yeah, I mean, I know we've said countless times today that Atlas is very flexible, but it's true. And I think when our clients come to us and want to test out Atlas, a lot of the time spent is really figuring out, okay, exactly how we're going to make our tech stack work together, right? Do we have an existing gateway? Do I have an endpoint agent today that we want to use to bring the local inventory into Atlas? So I think the answer is, it depends. We can be a one-stop shop and really solve all of your AI security needs. But if you already have a couple of different point solutions in place, very flexible integration patterns to make sure that Atlas is communicating with your, you know, your ZTNA solutions, your endpoint solutions, your SIEM and SOAR providers. So it's flexible. Yeah, it's an important point, too, because being flexible, I feel like when people think about AI, they think of Chat2PT, Cloud, AWS, and Microsoft. a lot of what we're starting to see is this transition with large and small enterprises where they're just building their own. They're building their owned custom LLMs. They're a custom web application that is hosted on AI. And I think the flexibility of Varonis is we can support a lot of those enterprise sources. But also, like I have a hospital system that they built a completely custom chatbot for patients and nurses. We can also plug into a lot of those as well. So existing stack, it could mean something that maybe they bought or purchased, but if they're building it too, Atlas can support that. It's like a homegrown LLM can still be integrated as well. Absolutely. Yes. Oh, this is an interesting one as well, do my developers have to change their apps or agents to go through the gateway? No, you don't have to. Again, you can. You can point, basically replace the base URL that you might be hitting, like the OpenAI API endpoint and replace that with an Atlas endpoint. You can plug into your existing gateway. We can deploy hooks files to all your agentic coding solutions end users, but you don t necessarily need to make any changes. If things are already routing through a gateway, we can continue to use that gateway. So again, that kind of architectural nuance might depend on exactly how you want to push this out into production, but you don't necessarily need to make any change. Oh, this is interesting. I love how questions keep coming in as well. Does this work with coding AGFI Clot code connected to AWS, Microsoft, and other enterprise sources? It does, and we're seeing it a lot. We hear from customers all the time is, hey, we're using Claude on the desktop and we're connecting it into AWS to pull from our databases or maybe Microsoft. And a lot of the times there's like third-party connections within those. So for Atlas, we can monitor Claude code, Claude co-work, enterprise Claude, but also if it's connected up into a third-party source, we could also intercept that traffic beforehand. Also after the responses have been generated to the user. So it's really versatile in the way that we can analyze the prompts, not only on the input, but ultimately if it starts to touch sensitive customer data, that's the stuff that customers are going to want to care about. I think another cool use case I had this past week was a client that had some internal MCP servers that were only accessible via their network. And they wanted to enable cloud users in the web to be able to interface with those, but they're only trusted from inside their boundaries. So they're able to use our MCP gateway, which is hosted locally, use that as a custom connector in cloud and make all these local MCP servers available to their end users. Awesome. Oh, we have a Varonis customer. I'm already a VARONIS customer. How does Atlas connect to what I have? Yeah, a lot of what VaronIS is built around is data security. So being able to identify where's their sensitive data, who has access into it. The beauty of that is because Varonис has been doing this for 20 years, is adding that data context layer, we can pull that directly in with Atlas. So if we're already classifying data across Microsoft, AWS, Snowflake, not only are we going to be able to see that sensitive data but we'll be able to see which agent can connect into it, what users can basically assume the role of the agent and access the data. I feel like I hear two big questions from customers. It's where do my agents and AI have access to sensitive data? And then the bigger question is, what can I do with that access? And that's where we start to look at the intent and start to shift the conversation a little bit more into the AI focus. But yeah, we can integrate with any existing veronis. Yeah. So to Carol's point, we already have that data security visibility. So if we can start to look for toxic combinations to say, hey, this agent has access to this sensitive data set, and it has a tool that allows it to potentially send email externally, we have this toxic combo now of sensitive data risk and exfiltration risk that we can easily identify. Adding to the intent thing you were saying as well, so you can add intent onto it as well. Does browser protection cover AI inside SaaS or desktop apps, or is it just AI websites? You know, the browser extension, when we deploy it, one of the main use cases we're seeing is for personal accounts. We hear the request of, you know, Atlas is already monitoring the enterprise. What do we do about the shadow AI that's out there? So there's multiple different ways. I think the beauty with using the MCP, LM gateway, just monitoring the prompts with Atlas through our native integrations and using the browser extension. We're really giving companies that flexibility that Mike was talking about is being able to connect into all of these different sources, control it from like a personal account and shadow AI access, as well as what's being used in the enterprise? Now, the beauty or risk of it is we see a mingle between the two all the time. Maybe you're grabbing customer data, using it into a personal account, or someone takes a personal account, tries to connect it into enterprise data sources. So when we look at it from both directions, Atlas, whether we're monitoring it from the browser portion or we're monitoring it through the enterprise source, we can keep track of that activity. What's the difference between prompt protection, agent protection, and intent? Don't they all look at the input and the output? Yeah, I would love Mike's input on this as well. But we always get the question of, can you guys block like social security numbers? And the answer is yes. We almost like to say that's a really easy use case. Mike used the perfect example earlier of the profanity. Might not be something that the security team would want to look at. And as we start to have more of these conversations, as prompt protection is really the tip of the iceberg, a lot of vendors and a lot of the market, they come in and they say, we have a gateway, we can block sensitive data. But that's not the biggest risk that's out there. We're starting to see a huge shift with intent behavior, agents that are being built, more on the side of like where we look at human interactions. And then we go into the world of autonomous agents and autonomous AI, really building that intent. And I'm probably beating a dead horse here, but it's really the biggest risk that we're starting to see when we get into financial institutions where they're trading on Bloomberg terminals, or maybe a healthcare institution is gathering information on a patient for research or for surgery. You can't leave it up to the agent to make the right decisions. there yeah i think um like the prompt and response is sort of table stakes now i mean we talked a lot about like the the risk of the tool calls themselves you know we hear these horror stories of you know i was working with my agentic coding solution i asked it to update my code and it deleted my database the prompt wasn't hey go delete my database right no one's putting that into their prompt you know it's a an agentic orchestration decision was made at some point that took an action that you didn't want so to be able to set things like prohibited capabilities and say hey no matter what tools might be available like maybe our mcp servers are drifting over time now we have ways to control that but let's just say i'm not keeping a close eye on all my capabilities i can just set a policy that says these types of things should never happen and control the actual genetic actions beyond just that prompt and response layer i think the next question that came in is pretty much what i was thinking as we were talking about this as well who in my organization should own this like we've spoken about intent we've spoken about the gateway the browser extension who owns us in the organization we get this question all the time every every day uh and i think realistically people i think understand this they just maybe don't want to admit it themselves no one team owns ai there's stakeholders from all across the organization legal has a say the business obviously has a saying like they're trying to you know hit metrics performance metrics by introducing ai into the organization security has a say. The C-suite has a say with the financial controls that you want to put on it. I also think it's one of those things where typically there's one team that owns it. We, if I had to pinpoint one, it's typically around security or compliance where there's a need for the business to pull it in. But it also from there is we drastically grow to different teams as well. And I think what's important with Varonis is when we sell Atlas, we also provide full services that come with the product. So when we do deployments, when we need to build custom configurations, When we need to, as Mike mentioned, if you're using an existing gateway, building something on your own, we don't just leave it up to customers to connect it and build it themselves. Varonis will jump in and help with almost all of that. Yeah. And I think the other nice thing is that within Atlas, there's great role-based access and granularity in terms of scoping different data sets and resources within the platform. So if you have a certain team that's only responsible for a small subset of the organization, you can provision their access in Atlas so that they only get the information that they really care about. So we can really tailor it depending on the appropriate stakeholder audience. Next question is, if I can do one thing next quarter, where do I start? This is also a great question. I kind of alluded to it earlier when I was talking about the LLM gateway and the MCP gateway. I think it's all about runtime. And that's kind of been the theme of today's conversation with the agent intent and the browser extension, the gateways. All of this is about runtime. And when we see clients, you know, kicking off their projects to onboard Atlas, I think a lot of them are starting with runtime because they have things that are already deployed. They have stuff in the wild today that doesn't have sufficient security controls. So they say, all right, let's kindof rein that in. Let's make sure that we have the stuff that's already deployed today secure. and then let's work Atlas into the rest of our operations, right? We will get it into the development cycle. We'll start running penetration tests against the things that we develop before we push them into production. We'll be doing continuous security posture scans. But before we do any of that, let's make sure that what we have deployed today is safe. There's also a lot of teams that they're looking for with AI very quickly, whether it's to their managers, to the board, to the C-suite, is they have to prove that what they're doing is quantifiable. And even with guardrails, we find of course there's the security risks but when we look at like llm costs and being able to quantifiably show how we've controlled token spend financial controls or runtime guardrails around risks it really quickly ties well veronis and atlas to the value that you're getting out of the platform based off of it so it's probably another driving factor the question about the last quarter made me think that when you talk to customers what's the biggest risk they're talking to you about i really think it depends on the customer you know we see organizations of all different sizes there's some that you know they're not that mature yet their biggest concern is shadow ai so the browser extensions are really going to solve that problem for them or people that have been maybe developing uh with the co-pilot studio right they're kind of branching out into citizen development and now they have some new risks being introduced as they're trying to enable more citizen development across the organization so things like the the agent intent becomes really important yeah um and then the most mature customers you know their their building enterprise applications that they're shipping out right not just for internal use but shipping ai power products to their customers in which case you know they really need to be on top of the the cost overruns and the the like the mcp server interactions i think we also see we've talked about guard rails a lot but oftentimes with customers they don't know what they don t know i talk with customers all the time where they say hey we might have you know five or ten agents we kind of we connect in and there's hundreds if not thousands and there s ones that are touching a lot lot of sensitive data. So a lot of the risk is just not knowing what's out there and how the business is using it, whether it's enterprise data sources, or as Mike mentioned, something that's custom built for it. So providing that visibility, I think is really eye-opening for a lot of organizations, big or small. All right. If you see a poll popping up, we'd love to get your feedback on today's session, hear what went well, what we could improve. And if you are interested in Atlas and learning more, you can schedule a meeting with us directly and we'll dive into more details and discuss you know how we can help with your ai risk fine question is my personal question if i'm a cso and i have heard about all these things we spoke about the the whole idea started with fragmentation and i'm trying to look for what's a good place for me to start on my roadmap for improve my ai security what's the good place you recommend is something people can start working on for monday you know i think there's so many different places that they could start but ultimately when i talk with customers i get this question all the time is like there's so much information where to restart i think it's really starting with the discovery and understanding where the biggest risk is obviously we have to understand the business use cases like what are they trying to solve for short-term initiatives but without understanding how things are being built some of the risks it's very hard to prioritize that i had a customer where they didn't know their risk that much at all we did an initial inventory and we actually found that two agents were tied to over 300 of the risks within their environment. They had admin credentials tied to SQL databases that were trading stocks on the Bloomberg terminal. They have no idea about this. And then from that, it basically was a cascading effect. So what we were able to do, probably within like a 30, 40 minute call, was identify the risk and remove it very quickly. So really just getting the discovery up front. I'm not sure if Mike had any other inputs or similar things. No, I agree with that. I mean, you know, I know I just said start with runtime. where a lot of our clients do but inventory is so critical that discovery phase otherwise you're making assumptions about your ai security posture you're making security decisions in a vacuum without really understanding your risk so if you don't have that actual understanding today and i do think you need a an ai focused security solution to be able to do that inventory if you try and solve this you know through your own admin console of whatever platform you're using you're probably not getting the full understanding of what's out there so getting that observability that discovery of what your actual AI landscape is will help kind of make all the subsequent decisions actionable. To draw a parallel to data security, it's like, ideally, when you find risks with data, you don't just delete the data. That's not the thing where it's, like, let's just delete everything. You know, there's always the question of who has access to it? When was the last time it was used? Who was using it? So really marrying together, like the context of these AI systems with what they're doing, how they were built, then we can enforce guardrails without breaking the business and it's very important we're creating a dlp policy without knowing what data you actually have in your environment and who's using it you know you're that dlp of policy is going to be completely ineffective if you don't have that understanding of the data itself i guess to your point it's a reflection of where do you think the cso is today i guess it's also what we're trying to say because if my answer is i don't know the dlp i don' have enough visibility maybe that's a good place to start yeah instead of trying to hey browser extension api gateway but I think it's still worthwhile having a conversation about this. But this has been great. Thank you everyone for being such a great company, asking all those questions as well. Thank you Mike and KL for such an awesome job in sharing everything about Atlas and what the announcements were. Hopefully some more follow-up conversations for you guys about Atlas as well, but thanks everyone for tuning in. Yeah, thanks everyone, for tuning Thank you. Thank you