Name: Product Showcase: Identity Security for AI
Uploaded: 2026-05-12T16:13:09.367Z
Duration: 46 min 8 s
Description: Product Showcase: Identity Security for AI

Transcript for "Product Showcase: Identity Security for AI": Thank you, Sachin. Welcome, everybody. Really, really excited to be here. AI agents and nonhuman identities are everywhere. However, these new class of identities are not running in isolation in your ecosystem. What that means is that these identities are touching your security systems, your transactional, your financial, your supply chain systems as well. And as they're touching reading data, they are changing outcomes. They are making decisions on your behalf. And to do all such actions, they require identity. And without identity security, these entities are running unbounded. And that, my friends, is not innovation. It's institutional risk. So what are we at Sabian doing about it? Let's take a look. Let's let me show you what we are doing about it. Now by the time you see this slide, these numbers would have already changed. The sheer volume and velocity with which nonhuman identities and AI agents are expanding, it's just staggering. The execution velocity, we keep hearing about machine scale and the average number of compromised time, it keeps on getting less and less. But the important part for every organization to understand is that AI and NHIs are changing the speed. They are changing the scale for which traditional identity models were never built for. And as organizations are adopting the new class of identities, there are three critical questions every organization needs to answer for. Number one, when you have such sheer volume and velocity of these identities, can you find them? Can you find them on time, and can you find them at scale? The second one, you think about your existing workforce employees or human identities. You have a blueprint. You have a structure on how they get onboarded into an organization. You have a process of how they get created in the HR systems. So right from an employee gets onboarded all the way to day getting off boarded, you have a structure. Do you have a similar governance structure for these new class of identities? And the last and the hardest problem, what you have to understand and really have an answer for is, are these identities accessing the systems, the data, what they're supposed to? How do you enforce that at real time? How do you enforce at run time when they're performing these transactions? The one question which keeps coming a lot in my conversations with customers, prospects, even even partners is why should we look at agents having their own identity? That's a fundamental question which every organization should be thinking about answering for. Let's take a look. If you think about all the different type of identities which you have dealt with so far, whether it is your human identities, nonhuman identities, even your privileged users, all of these are deterministic in nature. What does that really mean? It means you define the scope, you define the boundary, you define the permissions of these identities, and they do exactly what they're supposed to. They honor the scope, the boundary. On the other hand, when you look at agentic systems or AI agents, they are contextual. They're autonomous in nature. What does that really mean? It simply means that large language models, when they're instructing these agents, these models are incentivized to give you an answer at no cost or whatever they have to do for it, which means as these agents learn, adapt, reason, react, they can do something different as compared to what has been designed and what has been the boundary which has been allotted to them at design time. This is a fundamental shift with which agentic systems become unique, and that is why the traditional identity models which have been built for your users and applications do not fit, do not apply. More importantly, what you also run into is that traditional identity platforms are not enough for securing these new class of identities. Let's take an example. If you as a human is talking to an agent and if the agent learns, adapts, deviates from what it was supposed to do, who becomes accountable? One of the other pattern what we have seen is that human capabilities are assigned or extended to AI agents. Humans generally have a broad set of permissions, which amplifies the set of permissions or capabilities an agents can have. The third one, which is the hardest one in this is when you have multi agent systems talking to each other, if one of the agents go rogue, how do you attribute? How do you prove that which agent went rogue? And how did that affect the overall outcome of your workflows? Last but not the least, as identity practitioners, we all understand how hard it is to audit such autonomous systems and make it ready for your compliance needs as well. So at this point of time, what we are also seeing some of the design patterns with many organizations we are talking to is the extension of human identity trap. What that means is that organizations are dealing with two different types of agents. One is an interactive agent where you have a human talking to an agent, and the human capabilities are just extended without giving a unique identity to an agent. That creates a problem of privilege amplify amplification because humans usually have more access than what they really need, as well as it creates gaps in accountability as I explained. But when you look at a multi agent autonomous system, the pitfalls become even more. Especially if one of the agent goes wrong rogue when they're talking to a multi agent system, the trust chain can completely collapse. There is a dearth of blast radius controls, especially in this case, because one compromised agent can interact and lead to really bad activities in the overall ecosystem and thereby compromising the overall control. So what we are creating an awareness and what you need to understand is that every agent should be treated as first class citizens. Every agents have to have their own identity. The incorrect pattern is agents are just applications, and you should be using just a service account for them to interact. And as I explained, with service accounts, you run into all the pitfalls of them being static, overprivileged by default, and there is obviously no scoped control which you can put on top of the agents. The right pattern, the right way to think about this is every agent gets a verified scoped and a life cycle identity. What that means is the way you have defined the structure, the process of how human counterparts or human identities get introduced into your ecosystem, they have a life cycle. That's how you should be thinking about it, as well as you start assigning your own controls and own processes so that they have the right access at every point of time with full accountability and full traceability. So at Saviynt, our thought process and how we are helping our customers is to look at three different pillars. One, when you have these new class of identities getting created in your ecosystem, how do we help you to effectively find them across the board at scale? Second, we help you to define the life cycle of these new class of identities right from the moment when they are born into your ecosystem all the way to them getting off boarded. And the last and the most important one is to ensure that they are accessing exactly the same set of systems with the controls and processes for which they are supposed to. So I'm very happy to announce that Savion today offers the industry's most comprehensive solution to secure any enterprise, any customers, AI agents, and nonhuman identities by offering you a control plane, which offers posture management capabilities, identity management capabilities, and access gateway capabilities. And with that being said, I want to introduce my partner in crime, mister Sujit, who's going to explain how we have architected this the state of the art architecture behind the scenes, and how do we ensure that this will work at scale and handle the volume and velocity with which it has been meant for. Sujit? Thanks, Vibhuti. Hi. My name is Sujit Rajkumar. At Saviynt, I have the privilege of leading engineering for our identity security for AI product. Identity security for AI is our newest flagship product built ground up using AI native and cloud first design principles in mind. Our customer journey for this product starts with a comprehensive visibility and posture management of AI agents across various form factors. This allows us to identify AI agents, map what they can access, and surface access risks to eliminate blind spots. This is followed by our identity management module, where you can register, govern, and track AI agents across their entire life cycle. Complementing all of the above is our access gateway capability. This module can continuously authenticate and authorize agents to enforce zero trust access at all times. This is an inline module engineered to rapidly scale and secure our customers' agentic workflow as they roll out enterprise wide deployments of AI agents. Our engineering efforts for all of the modules mentioned above starts with an AI native spec driven development effort, rapid but iterative process, customer validation, and then we rinse and repeat this. We use two of the world's most popular agentic coding frameworks to drive innovation at scale. Along the way, we have instilled guardrails into our framework to ensure we are using AI rightly. There are multiple goal oriented agents built by our engineers that work within the modules to perform r and d activities at scale. All of our modules follow cloud first design constructs. At the data plane, we use a combination of relational and non relational persistence technologies, which are engineered with resiliency and availability principles. For our control plane, we use a distributed microservices based architecture with event driven principles. We leverage best of breed technologies from hyperscalers along with various frameworks built within Saviynt. This entire experience is built on top of Saviynt's converged identity platform for workforce, NHI, and AI, which allows us to leverage the power of the platform in detecting, understanding, access, and providing remediation workflows, built on the intelligence gathered from millions of workforce and NHI identities. Lastly, we also have builder and developer facing API and framework capabilities, which allow enterprises to build with Sabian from day one, ensuring Sabian is governing your workflows from start to finish. Now it's time to see all this in action, passing it over to Vibhuti. Thank you, Sujit. Thank you very much for helping the audience understand the architecture, the thought process, the design, which has gone through in building this platform to handle the scale and volume of these new class of identities. From here on, let's go into our first pillar, which is posture management. Well, there's a saying, there's an adage in cybersecurity that you cannot protect what you cannot see. And that exactly was the principle, the tenet on which our posture management capabilities were built. Number one, we want you to ensure that you can discover all your agents, all your nonhuman identities at scale no matter what surface they're running on, whether it is compute, your integration service, your browser endpoints, or your back end architecture. Second, we also want to ensure that we are continuously understanding from your configurations or different risk signals, which are ingested by the Sabian platform to understand what and where your risk lie with these identities. The third one, a very important one, shadow AI. You will have agents running on a developer's laptop or it could be running on a Kubernetes infrastructure. It could be on a Windows or a Linux workstation. How do you detect all these different types of agents across the board at scale at the right time? And last but not the least, how can you also understand that there's a drift, whether it is an access, whether it is in configurations? How can you spot this drift in real time? And also understand the anomalies, which could be in terms of access anomalies or any kind of data, what these agents are trying to access, and if there is any possibility of data exfiltration use cases. So team, we are very bullish with very, very excited on what the engineering and product team have built on the posture management. And to show you this in action, I want to invite my partner in crime, Nam Yoon Ahn, to show you this in action and and explain you how this whole thing works and can be beneficial for you. Namion? Thank you, Vibhuti. Hi, everyone. It's a pleasure to be here to show you how Sabian Prostrate Management solves the visibility gap in the AI era. Most organizations today are flying blind. They have thousands of nonhuman identities, service accounts, and now AI agent, but no unified way to see them. So it starts with one thing, visibility. Because if you can't see your agent, you can't secure or govern them. Agents are already running across your environments like Amazon, Salesforce, Google, everywhere. So what's the first step? It's simple. Discover everything. Bring every agent into a centralized agent registry so you finally have a complete view of what exists. This helps you see a clear sprawl across agents, MCP servers, and tools. From there, we start with a simple risk finding, like who owns the agent. It sounds simple, but it's a major gap today. Most agentic systems don't address ownership. So we start there, establishing accountability and closing a key governance gap by identifying orphan agent and assigning clear human ownership. Then we move into the next generation of identity governance for agent workflows. It comes down to three questions. Who owns the agent? Checked. What access do they have? And what are they doing with that access? This isn't a periodic review. It has to be continuous. That's the shift, continuous governance. Continuous governance also requires continuous audit readiness. With Saviynt posture management, you get a clean, stitches timeline of every agent. With key events such as guardrail getting changed, owners being removed, or access being changed such as MCP servers being added, etcetera. What actions they're taking, how access is being used, and what's changing over time. You can take the view, hand it to your audit team, and you're covered. Then comes the hardest problem. What can the agent access, and who or what can access the agent? Whether it's Salesforce or other complex applications, we operate at a very granular level of access. We take the depth and map it directly to agent workflows so you can truly understand where your risks are. The final piece and a big one is access gateway. For the first time, we are introducing the agent access gateway. It sits in line with every transaction between agent and enterprise applications, not just defining policies, but enforcing them in real time. That's a major shift. We'll explore this in more details in the next demo. On top of that, we integrate with third party security partners such as CrowdStrike, Zscaler, and others to bring in risk signals into the unified view. This allows you to correlate risk across systems and get a much more complete picture. With posture management, it all comes down to this, continuous visibility and confidence, especially in environments where today, organizations have very little bit. To learn more beyond posture management, I will hand it back to Vibhuti. Thank you, Damian. Thank you very much. That was really, really exciting. I'm I'm, again, pumped. I'm excited to show you all what the team has been building here at Saviynt. This is just the start. And now let's go on to our next pillar, which is how do we help you to create a structure, a blueprint of managing these new types of identities right from the day they get born all the way to them getting off boarded. And it all starts with the process of registration, very, very important step. But the fundamentals, the right step towards effectively governing your identities is also to ensure that you are managing the owners of these agents. When you have an agent getting created, who is the human counterpart responsible and accountable for these agents? How do you continuously certify what access do they have? And most importantly, how do you prove? How do you create a traceability and a verifiability pattern in your in your ecosystem to ensure that you exactly know what these agents are doing? So let's take a look at what identity management player looks like. If you have to boil this down on why agent life cycle management is needed, it all comes down to these four key answers which you have to think about. Number one, if you are not thinking about registration, it simply means you're not giving your agent identities, and that is a fundamental anti pattern. Number two is if you are not thinking about ownerships or if there are any ownership gaps, you do not have full accountability in your in your ecosystem. We often talk about the onboarding process, but offboarding often gets missed. You have ephemeral agents. You have persistent agents. How do you think about ensuring that when the agents are getting decommissioned, there is no residual access? There is no persistent access to these agents. And last but not the least, thinking about audit and provenance is an absolute must for your these new identities getting created. Another thing, what we also look at is the problem of identity changing, especially in your multi agent systems when a human counterpart is orchestrating an agenting workflow and the agent is deciding to talk to multiple different sub agents, which eventually is calling an external application, one agent having rogue access can change that and let other agents also exfiltrate or can do suspicious activities or lead to data exfiltration. Like, I can give you some real examples. You can have an agent which can export your personal identifiable information, but the original agent which initiated or authorized that could always say that this was never authorized by me, and you cannot prove it if you do not have enough traceability in your system. Token or credential laundering is, again, a big example where a low trust agent can have elevated or root level access because it was called by an agent which already had that access. So these are some real world examples which tells you why life cycle management becomes extremely important. Why do you have to think about auditability? Why do you have to think about provenance at scale? Because all of these, what is what I'm showing you here will happen at a speed, at a velocity which was and has been unprecedented, and that is why doing governance and governance at scale becomes paramount. So let's take a look at how this works in Saviynt. It all starts with when you think about creating your agent, you can you can start creating these agents at any on any platforms. The first and the foremost step, what you do is you define the metadata which is associated with these agents, defining a rough goal or an objective. And that's where you start defining these are the different tools which the Savient platform exposes to your agent to consume, and you are basically defining the scope and boundary for this agent. Now one of the important aspects here is Saviynt, since it understands the fine grain security model of your applications, these tools can definitely create a lot of fine grain boundaries for your agents, removing the or eliminating high privileged access or more access what is needed. You can enable just in time access workflows. You can control which all different knowledge bases, external tools, external applications the agents can talk to. And most importantly, you can also define a scope wherein you can also look at what are the other agents this agent can talk to. So Sabiant, being a broker or a mediator for supporting agent to agent or protocols like MCP also gets supported in this. The important part here is that last but not the least, you can also define which of your identities and applications can consume or invoke this agent. So both inbound and outbound access gets controlled. And last but not the least, Sabient empowers organizations to be the identity source for your agents, pushing all these data to third party security systems like Zscaler, CrowdStrike, and control the network level policies as well. Now this is pattern number one, which allows your white coders, your business users to create an agent, but also control the scope, the boundary of that agent and what that agent can do at design time. Let's take a look at what will be the experience for your engineers or developers who are building agents on Claude, Cursor, or any other agent building platform. What you are seeing here is an agent getting built using Cursor's platform. And on the right on the right hand side, what you would find is that it becomes easy and a frictionless experience for a developer to easily register the agents as well as define what the scope of this agent could be if the agent is trying to access an application like Salesforce. It all becomes extremely important because what Savint is offering is a frictionless experience of embedding governance right where the agents are getting built without requiring the need for a developer to learn a new tool. That's what the whole, equation is, and this is our pattern number two. There are organizations who are also embedding all these different SDKs and registration processes as part of their CICD pipelines, which means anytime when an organization wants to take their agents from a dev build to a production instance, they can also embed the registration processes, the life cycle management processes as part of the CICD process as well. So that was about our second, design pattern. Now let's take a look at what happens about the ownership management. What I'm showing you here is all these different policies which an organization can create. You can look at the metadata about all these agents, and you can also think about creating a new policy depending on the different parameters of an agent getting registered. You can look at the large language model, what the agent supports. You can look at the different platforms on which the agent is getting built, and you can create these policies, which allows that anytime and every time when an agent gets registered. And if it matches any of these criteria, then the moment these agents are getting created in Saviynt, automatically, a business owner and a technical owner gets assigned into Saviynt. It's a very, very important step, especially from a governance standpoint. You can do more things about giving them ranks. You can also think about creating a transfer ownership, which means that anytime when a user leaves your organization, your agents never get orphaned. They always have an owner, which is ensuring the and takes the full accountability of what that agent can do. So, again, friends, it becomes extremely important that when you think about agents, you should always treat them as first class citizens. You should treat them and give and have the same level of rigor what you have with your human identities. And you can think about ensuring that anytime and every time when you are building these agents, you follow and adhere all these principles. You can also think about assigning criticality to your agents and run a lot of automation and workflows based on the criticality or the level of autonomy what these agents have. So, friends, this was all about agents, their life cycle, their registration process, how do you control their access, how do you manage their ownership, and which was all about the second pillar what I had. Now let's take a look at the third, and which I call it as the the hardest one, which is you have defined the scope, the boundary of what that agent can do. Now remember one thing, an agent is always going to deviate. An agent is always gonna do something of their own. And when they do that, how are you ensuring that you are enforcing your least privileged policies? How are you ensuring that they do not do something which they are not not supposed to do? And for that, again, I'm extremely, extremely proud to announce our access gateway offering, which is the enforcement layer where Sabient will be in line sitting between an agent and a third party application or an enterprise application to enforce runtime authorization to enforce real time policies and ensure that at any point of time, an organizational agent never violates your zero trust principles. So let me explain you how this all whole thing looks like. Let's say a business user asked an AI agent to go ahead and clean up stale CRM records. You you should you should definitely try that at home. Or you can simply say go ahead and clean up my Jira task. My so here, the thing is that the goal of the user is all about ensuring that the CRM records get optimized. The agent, on the other hand, when it plans, it can ensure that the word cleanup stale CRM records when a large language model understands that it can always instruct the agent to go ahead and do a bulk update or delete operation. Now if the user has read and write permissions on the CRM system, it can actually go ahead and delete all your CRM records. But is that what the original intent was? And that's where the Sabient access gateway comes in. It will interpret what the user's intent was. It will evaluate your risk in real time, and then it can take a call depending on your policy on what should the agent be allowed to do. A very important point, a very, very important area for you all to think, assess, and design accordingly. So how are we designing this intent aware runtime authorization access gateway? On the extreme left hand side, you would have all your agents, whether they are agents created by your HR systems, your finance, your IT operations, your analytics. These agents are created with one intent, and that is to talk to your target applications. These target applications could be SAP, ERP systems, your workflows, ITSM systems, infra, SaaS platforms. What the Savient Access Gateway does is it gives you two different interfaces. Interface number one exposes all the necessary operations, like tools, etcetera, for all these target applications to your agents. It also allows you to map each and every API call, which can happen to these applications through the different modules, like action interceptors, resource mappings, etcetera. And then it also offers you a policy engine which allows or does few very interesting things. Number one, it does an analysis, a deep analysis of the user's intent. What that simply means is when you wrote something like clean up my CRM records, what does that really meant? Did you really want the agent to go ahead and delete, or were you looking to optimize your CRM records? You can enforce policies like at any given point of time. No matter what, any rogue agent, any agent which does not have a business owner should never be performing a transaction, a sensitive transaction in my enterprise, and that is something you can definitely do. Of course, the final decision and auditing is done by the policy engine, and it allows you to define different outcomes in your agentic workflows. One, of course, is the agent allowed to perform a particular transaction? Second, is it going to be blocked depending on if it's a critical mass delete or or some kind of transaction which can lead to catastrophic results? Third, a very, very important one is if you want to ensure that a human in the loop gets embedded, you can define that as part of this. And last but not the least, auditability, verifiability, and traceability becomes the most important tenant or most important out outcome from this from this gateway. And all of this allows any customer to ensure that their policies are always enforced at run time, whether it is for access or any other infosec policies. You completely eliminate the chaining of identity risk, which is a number one issue, especially in your autonomous multi agent workflows. Of course, the the access, the least privileged recommendations are given to your AI agents so that they don't have more access on what they are really required for. And then last but not the least, identity context is shared up across all your agents so that they all can learn and train each other as well. Now we are very excited. We are very bullish on that. This is going to be the most important pillar when we think about securing autonomous and agent tech systems. But let's see this in action. And for this, I'm extremely proud to announce and bring my partner in crime, Suresh, who is the lead PM on this. And let Suresh show you how this whole thing really works. So as Vibhuti explained, you know, we basically have the segment access gateway. The gateway actually sits between an agent and a target application. Typically, your target applications tend to be either MCP servers, they are rest APIs, or, you know, could be GraphQL APIs as well. So what we are seeing here is actually the control plane. You're gonna see the demo in two parts. One part is the control plane, then I'll shift into something that's on the, the actual data plane as well. So if you look at the control plane, this is the landing page that you actually get to. You actually see a list of the gateways that are actually available. And this is a multi tenant solution. As you can imagine, they're gonna be, you know, different to each tenant is gonna be isolated on its own, and every tenant will have its own gateway. So in this page, you see multiple gateways. You also see the ability to kind of filter based on, you know, the different, you know, statuses of the gateway, and there's also the ability for you to search. So if you look at the in this particular page, you have actually see about 40 ish gateways. And let me actually, kind of look at the the different statuses. So gateway can be inactive or inactive, or it could you could do basically filter based on the authentication methods that actually support it. And, of course, there's a search. So the next part we'll look at is how do you actually create in different gateways, but there's also different states, inactive and active. If I basically switch between active and inactive, you'll actually notice that the gateway state also changes at the top. So the next, you know, when you wanna create a new gateway, we just click on the create gateway. And in this case, I'll just show you, you know, this all you need is basically a test, you know, some kind of a name and a description, and you have you can set the status of the gateway. The because it's a multi tenant solution, you can have any number of gateways that you have within your tenant. And this case, let me just create a, you know, gateway with, with a name. And what what essentially happened behind the scenes is you created a shell of a gateway. And each gateway can have you know, it's actually exposed as an MCP server as you can see. And this is ex actually the endpoint with which you can access the MCP server. And each of these instances have their own unique, you know, IDs. And the status that you with which you actually created is also available. There are different policies you can set, and this is where we kind of tie back into the the discovery and the life cycle management. So you can look at a particular gateway that has, you know, that may be coming in with a particular platform. You could look at, requests that may be coming in from different models that you actually have. In this case, we're looking at platforms. And, essentially, what you're looking at essentially is if you do not allow certain platform agents to be, you know, to to access your resources, you can block them similar with the different models as well behind the scenes. In addition to that, there are API keys. You know, in this case, the authentication mechanism. We do support API API key. We have other authentication mechanisms in in the works as well, including secrets and key management services. We don't consider usually an API key just as sufficient to be, an authentication mechanism. It's more verification. However, that is supported. Now outside of that, there are also other ways in which you can see which agents are permitted and agents can go through their own life cycle. And there's also developer ecosystems and, you know, who are permitted developers who can actually create and, have the agents in place. Now each agent can actually have one or more target, resources that they can hit. Each target resource, is can be configured within the gateway. In this case, you will actually see that, you know, attaching a target is pretty straightforward. So in your tenant, you could have multiple gateways, each gateway being, you know, essentially going in for attaching to multiple targets. So in this instance, what we will look at is actually how do you actually attach a target. So pretty straightforward. When you actually click on attach a target, you will see a short window that opens up. Then what we have done is to sim is simplify the search of the MCT server. So you could aid the search using, you know, a keyword search, and we'll actually show you some of the ones that are already preconfigured. In this case, if you look at Salesforce, you'll see that the MCP URL, the target URL, and, you know, callback URLs are all set preset for you. Now if it's a custom application, you will have to sit and fill all of all of these out. You need this data. There are different attributes for the MCP server that you would have to set up. For example, each MCP server could have a different authentication mechanism. We support OAuth client credential flow as well as authorization code flow. API keys are available because legacy applications may actually need API keys as well. Now when you're looking at any of the OAuth protocols, you will need a client ID and a secret. And in addition to that, there you know, we also support some of the exclusion parameters. For example, an MCP server may expose multiple tools. And if you wanna say filter out certain tools, for example, I want all agents that go through this gateway to only be read only. So I could actually exclude all the right permissions that you actually have as part of, you know, per that particular MCP server. And that way, the agents will only have access to the read permission or the read tools only. So in this case, what you'll actually see is this is essentially how you set up, you know, a set of MCP teleservice and targets. Now let's just look at one of the gateway instances that have where I've already preconfigured two different, you know, tools, MCP servers and tools. So in this instance, we'll look at one which has both Dropbox as well as Salesforce setup. So if you look at look at what we actually have here, I've attached two targets. The discovery of the different tools have actually happened for these, and each of these tools you'll notice are actually available as, you know, as, you know, as for any agent to call. The what we've done essentially is discovered as all the different tools bypassing the parameters that are there, and the same thing you will see for Salesforce as well. So that's essentially how you would set up the gateway. In in essence, what you've done is you've set up the connectivity between the gateway and the target resources. Now the gateway is ready for use, and all you need to do is look at the front end agents and how these agents can actually connect with this particular instance of the gateway, which is what we will roll out to. So so far, what we saw was, how we actually configure the gateway. So we basically looked at setting up a gateway and setting up two target applications. And in this instance, what we'll do is we'll kind of advance into the next stage, which is essentially making sure that the gateway is accessed it can be used by different agents. And what you're seeing here is two different agents. There's a read only agent and the read write agent. And as I showed you earlier, you can actually set some filters. What we look at is first the read write agent. In this case, it's both of the both of these agents have been configured in Copilot Studio to actually work with, you know, as the saving gateway and the back end application, the target resource is Salesforce. So when you when you look at the first one, which is essentially this is the read write. I have the ability to write. What what is happening behind the scenes here is we've already set you know, we've set up the gateway as part of the tool because it's exposed as an MTP server, and we've discovered all the tools that are available. As you can see, you can see the Salesforce read and write capabilities that are available to this particular agent. And I'm logged in as myself in this particular instance. And when I actually go in and start looking at, you know, a particular opportunity, it's looking at it's taking my information, which is my the authentication token that I've provided and pulling up the the opportunities. This case, I pull up a specific opportunity, and I get all the data here. And for this one, let me just go ahead and update the value of this particular opportunity. As you can see, you know, I have read and write permissions. The agent is allowed to do this on my behalf. And when I actually go in and try to update it, you will notice that the actual value gets updated. And, you know, essentially, it's hitting Salesforce as me with my user user token and returning the value and updating the the up the opportunity value. So this instance, when you know, I just go back, verify the opportunity has been, you know, updated as you can see here, And this is pretty much going through the read write. Now let's actually go and look at a read only agent. If you look at this particular agent, you'll notice that the same gateway has been you know, I've configured a different instance with the gateway and only read permissions are allowed for this particular, agent. So any request that goes in for a write is gonna be blocked by the gateway. And in this case, let me just go ahead and try to do something similar. I'll get my latest opportunities, and you'll basically see that it's retrieving these opportunities. I pick up a specific opportunity here. And for this opportunity, I'm gonna try and update the value. When I actually look at updating the value, remember this is a read only capability. So it comes back and basically says, I'm sorry. You cannot read. You cannot update. Or you basically are allowed to read only, and here are the permissions that are, you know, that are allowed here for this particular agent. As you can see, we set up the agent, the the gateway. The gateway has been set up for target resources. There are two different agents. One, basically, which has a read only permission. The other has a read and write. And we demonstrated how exactly the gateway would be able to intercept these requests and make sure that, you know, the permissions are appropriate. With this, I'll just hand it back to Vibhuti and so that he can continue with this conversation. Thank you, Suresh. Thank you very much. That was absolutely fascinating. I I will tell it to my audience that there is so much work what we are doing in the gateway space. You will see a lot more coming up. We are absolutely bullish. All the early results, what we are seeing in this is is unbelievable. Now with all the things what we have shown, I hope you all found it useful. At the end of the day, as I want to wrap up my product showcase, I would say AI identities and nonhuman identities are moving quickly, And you still have to answer. Every organization on this planet have to answer three three critical questions. Can you find all your agents effectively on time at scale? Number two, are you enforcing are you defining the same rigor of governing these new class of identities, how you have been doing the human identities as well? And last but not the least, are these agents are these identities, especially them being autonomous in nature, are they doing exactly what they're supposed to do? Are you enforcing your policies in real time? If you want to have answers for these three critical questions, please reach out to us. We at Saviynt are very bullish, very excited to present you our identity security offerings for AI and NHIs. And now that's a wrap from my side. We are going to go into my favorite section. You heard about what we are doing from a product standpoint. Now it's time to hear the real world and also understand how these offerings are being implemented by our customers. For this, I'm extremely proud to invite our head of product and customer marketing, Nupur Goel. Nupur, over to you.