Name: Recording: AI Security in Action: Saviynt Zuma Demo
Uploaded: 2026-09-23T16:56:43.317Z
Duration: 24 min 58 s
Description: Recording: AI Security in Action: Saviynt Zuma Demo

Transcript for "Recording: AI Security in Action: Saviynt Zuma Demo": Hello and welcome to today's webinar, AI Security in Action, a demo of Zuma, Saviynt's AI and NHI identity security solution. My name is Greg Liewer, Director of Product Marketing here at Saviynt. And today, we're joined by Warren Kendall, one of our outstanding Solution Engineers who works with customers on a daily basis to design and implement robust identity security programs around the world. If you have any questions during today's session, please feel free to put them in the chat box. We'll try and answer as many as we can during our time together. And while some of you may just be interested in learning more about AI, most of you are here as your organization is trying to address the explosive growth of AI agents and provide proper security around them throughout your organization. And you're not alone. While adoption of AI, whether knowingly or unknowingly, is ubiquitous as indicated on the slide, most organizations are rightfully struggling to secure to secure the AI in their environments. That's in part because the ratio of AI and nonhuman identities to human identities is expected to reach 144 to one by the end of this year with 1,300,000,000 agents projected to be deployed by December. Additionally, 88% of organizations have had a confirmed or suspected AI related security incident just in the last year. AI agents have exploded across the enterprise, rapidly expanding the attack surface, and previously developed security tools just weren't built with them in mind. That's creating some real headaches with some core challenges being identified by organizations. The first is that organizations are unable to see all of the AI in their environment. A lot of organizations simply don't know how many AI agents are running, and you can't manage risk that you can't see. AI agents also touch a lot and move fast. These agents are reaching into numerous sensitive systems and data stores, which makes oversharing and exposure a lot harder to keep in check, especially as they move exponentially faster than any human possibly can. Also, previous controls weren't built for the attempt autonomous behavior of AI agents. Agent capabilities are moving faster than most guardrails, so we end up with autonomous actions, including agents delegating work to other agents, which is also happening without oversight. And as indicated on the previous slide, they're overprivileged. 70% of respondents in one survey saying their agents have more access than they actually need. And this isn't a one off issue. It's it's broad and it's persistent. And for those of you just getting your first look at Zuma, Zuma delivers enterprise control over AI to help organizations adopt AI with confidence. Zuma gives organizations real control over their AI so you can accelerate adoption without losing a grip on security. Zuma is built for AI from the ground up. It isn't a human identity tool that's been retrofitted for agents. It's been designed from scratch for how agents actually behave, fast, dynamic, and at scale. It includes intent aware runtime controls. Before any agent takes an action, we can evaluate identity, intent, context, risk, and policy, and authorize it in real time, not after the fact. It provides a single control plane for AI security with discovery, real time protection, and life cycle management all live in a single identity security control plan. And already, on average, Saviynt customers are already identifying approximately 761 identities per connected environment or tool, with 81% representing severe posture risks, including excessive standing access and unrotated cloud secrets. So to set the stage for today's demo, we'll highlight a few of the capabilities capabilities within Zuma that remediate common challenges being faced by organizations. We'll take a look at some of the discovery and re remediation capabilities by assigning ownership protection and enforcing access through intent aware, runtime authorization, and policy management. And we'll show governance through instant off boarding or suspension of AI access. And to do that, I'll hand it over to my esteemed colleague, Warren Kendall Kendall. Warren, Kendall, take it away. Thank you, Greg. Liewer. Happy to be here with you on another webinar series. I'll share my screen here momentarily. I'm excited to walk through Zuma with you to help showcase not just the insights because, again, the the big point you were making earlier was you can't govern what you can't see, and that's just foundational identity security and cybersecurity in general. The Zuma insights page allows us to quickly showcase what's going on within your environments that are integrated with Zuma. Zuma has a lot of out of the box integrations, very easy to set up, very quick to set up, and we've got a few of them already put together from Copilot to Bedrock to Google and a bunch of others that we can start working with. Zuma is supposed to be your one stop shop for all things NHI. So think about service accounts, think about certificates, think about different types of nonhuman identities. But today, we will focus primarily on AI agents. And so from the insights page, we're able to look through some of the findings based on different AI agents here, the trending over time, if there's any kind of criticalities that's going on in my demo environment. A lot of things are, definitely top critical priority right now, but we can also look at the various riskiest identities that are happening from a specific identity perspective. We can also look at the severity charts here as well. Quick little dashboarding between the classification of risk within your integrations, within your repositories for these various identities. But let's look into the specifics of what's going on with these AI agents. And so getting back to the inventory part of Zuma, we're able to showcase quick dashboarding about what's going on from the ingress over time. We're seeing a little bit of extra agents that are being built and, flowing through to Zuma right now, the different tools that have been onboarding, the different LLM models that are being utilized, and any kind of, findings here. And actually on on a good part, a lot of the critical findings don't seem to be AI agent related to my demo environment, so that's a good thing. But if you wanted to get a quick breakdown, we can expand this out, look at some of the specific findings that Saviynt provides out of the box. And so a lot of these different policies, you'll be able to also customize based on what your organization needs, but we do provide a lot of these. So, you know, on day one, when you start connecting things to Zuma, you'll start having an understanding of the different things that could be going on, like AI agents missing a description, which could be a process that could be easily changed. Or more importantly, if we have things like, you know, inactive tool use and topics that are connected, you know, we wanna make sure we're addressing these things more specifically. But if we're looking at even the orphans, Greg was mentioning that one of the biggest remediation processes for, you know, identities in general is a lack of accountability. We don't think at Saviynt that any AI agent should be without an owner. And most of these platforms that we're connecting to, including Copilot Studio, they don't always address an owner specifically, although there is an implication of, them having some sense of ownership based on the creation. But it's not, you know, stated specifically. So we can come into this orphan agent dashboarding and start taking action. Quick clicking from the inventory. We're looking at now the agent management within governance to start saying, what's going on with these specific agents? I can click on here, this top one up here, built by somebody, doesn't have a specific display name, but we do have a description, which is great. We do have the platform from which it came from, and more importantly, the specific agent ID. Now if I wanted to start adding in a specific owner for this agent, I could click on the owners tab here. We'll notice at the moment, no owners assigned. Now that's because, again, we're in the findings for all the orphan agents, so this is expected in this capacity. So we're gonna start adding owners by just click quickly clicking this button right here, and we can start looking through the various individuals that we might want to add ownership towards. So I'll take Dave Brown here. I'll just add him in at this point in time, save him as an owner. Automatically, he's being added as the business owner. We can come in here and also edit this. If I decide that Dave is actually somebody who needs to be the technical owner, we could change Dave from being business to technical. And if I needed somebody else to be the business owner, I could also add in a new owner after the fact. Right? But now here's Dave. He's not a technical owner, and it's super simple to just add a new owner to somebody who's within the Zuma platform, ready to go, and now we have some accountability on this process for for this specific agent. If I wanted to start building more specific rules around how to automatically assign, ownership, we can come into the rules for agents here. This doesn't only have to pretend pretend to, automatically assigning owners, but this is one way that you can start saying, if we have, let's say, a new agent registered being ingested by Zuma from, let's say, Copilot Studio, you could say if the name has, let's say, a specific type of, schema, like for my agents -wk, w k, I can come in here and start looking at that more specifically, and I can't put the space in there. But if I add this condition and then start looking at who should be assigned as the next owner, it's gonna showcase, you know, if there's any existing matches. So it quickly computed from zero to one, and it's gonna showcase that I have that specific owner there. I'm gonna go ahead and, not do this for the moment, but highlighting that if we wanted to change the role, again, between business and technical, if we're having multiple owners, we can choose different ranks. And then again, if I wanted to select a specific owner, let's say, like Dave Brown, I could do that as well and then say, hey. Dave can now be the, the new individual for this specific rule and then save and activate that going forward. But programmatically helping us understand how to name these things so that way when we have, you know, auto assignment of ownership or Warren's agents, these things can be done automatically. So the rule is not created. Anytime an agent is registered, new agents are gonna be assigned that specific owner, and that's gonna be great. Now the ingestion for Copilot Studio isn't within the timeline of this demo, so I'm not gonna go ahead and showcase a new agent in that capacity. But what I do wanna highlight is how we have all the great governance coming through for our different agents as well. Because we can come through let me make this sticky here. Again, for any other agent that's coming through, if we have new owners, you're seeing some of these are starting to be, added, we can build new rules for all these different agents if they need automatic assignment. But the big thing, the the major point of control for any kind of AI agent is specifically the access gateway from Zuma. Being able to step up and start saying, hey. When these agents are gonna take specific actions, we wanna make sure that they're doing only what they're supposed to be doing, nothing more, nothing less. To control that, we stand up these gateways that allow us to then start saying what tools, what specific targets within those two or the tools within those targets should these agents have access towards. So I've onboarded for my gateway a specific couple targets. We have GitHub. We have Salesforce. I've done some auto discovery on these specific tools to help understand what these agents should have access towards. And the quick editing of this can be done at any point in time. I'm not gonna mess with that for the moment, but you get the quick look at all the different tools that any agent that's interacting with this agent or scenario with this access gateway will have access towards. So in the current, iteration, all these different things, you get a little bit of, you know, tool tipping on what the specifics of this tool looks like, the expectation of how this is being stood up. And if I even go to, let's say, some of my own agents within the inventory, we can showcase that some of the webinar agents that I've created, and some quick search here if I can spell correctly, highlight a couple things for us. So the webinar agent here does have a timeline view, was created recently, updated recently, all this great, summary data on these agents. This is all great. But what I wanna make sure I'm doing is then saying, what kind of access should it have based on what the expectation is for this agent? So I come to the governance page, come into these specific webinar agents, and I can start looking at the specific access. Here, you start leveraging part of the governance for request for specific types of access. So I've done this already to kinda stage part of this data for us, but I've said, hey. I'd like this specific agent to come through to my gateway, the access gateway dash w k, and I want to have access to Salesforce. I submitted this request. It was already approved. I approved it because I own that gateway, and I'm able to have this specific Salesforce opportunity here. But I do have a couple other agents, and I just wanna highlight the difference on these. And if I do it like this, here's my other Zuma assistant. I just wanna highlight that other agents can have other approvals of access within that same gateway. Because despite the fact that I've got all of the 45 tools within GitHub and 11 tools within Salesforce available at the gateway, this agent has full access through it. The other agent does not. I just wanna call that out as a bit of an understanding for what I'm about to show next for that specific control within the access gateway. So now when we come back to the gateway, we wanna see how this works in real time. So and let me collapse that. We'll showcase that. Again, attaching targets doesn't take very long at all. I think the total time for standing up a gateway and getting some of these things going based on, you know, if you're the endpoint admin for these different targets, if you have the corroboration from your different application owners. I think I had this access gateway stood up in maybe twenty minutes with these tools all attached. It happened very quickly, and it didn't take much time at all. So from here, I wanted to then say, what can these specific, agents utilize? At the moment, I am enforcing outbound access. So we have, you know, only agents that are allowed to invoke specific tools will be able to use those specific tools. I was calling out the differentiation between those two different agents based on one having access to GitHub, the other one only having access to Salesforce, but the other one having access to both, the totality of what this gateway is offering. So that is currently being enforced. If I come to my specific agent And, actually, it's not the right agent. I need to go to the other one. Here we go. Let's ensure that our tooling connection is working, and it's not. Let's make sure we redo that. I had refreshed all this just twenty minutes ago. So it's quick little authentication to the IDP to ensure that all this is expected and properly registered. Excellent. So getting a green is good here. The proper connection IDP, all things are expected at this point in time. We're scrolling down. This specific one has access to all the things within Salesforce and GitHub. You're seeing the full listing of that specific, part of the tooling to the gateway. Here we go. And you're seeing again the tools list based on that agent that I'm calling out right here. Webinar agent -wk, Kendall, that's the same agent over here. It was calling out to see what can it do through the gateway and provided all the same tools for even the listing within Copilot Studio on the left hand side. So at this point in time, we can go to the other agent v two. Just ensure that we can make sure that this is also connecting properly. There we go. And you notice that this one only has access to Salesforce, and that's because, again, through that gateway constriction, through the governance of that request for outbound access, this specific agent is now only allowed to talk to and work through the Salesforce thing. So I can ask this specific agent, you know, list out the top five deals within Salesforce. Quick easy demo questions. Just making sure that we can do specific things. I'll expand this so you guys can see us a little bit better. I do appreciate it showing me part of the outputs, part of how this is actually being operated. And here we go. Pretty quick response on what the top five Salesforce opportunities are. Now you might say that I don't actually want to let that agent perform those specific actions. And actually, we can actually before I go back, we can double check that it doesn't have access to do things within my GitHub account. Or is this the one? Yeah. This is the one that only has Salesforce access. So we can say, list out all private GitHub repos within my account just to confirm that it doesn't have access to do that. Scroll down. And you're noticing here quick little response. I don't have access to your GitHub account based on, again, the constriction from the access gateway. If we refreshed our access logs over here, we are seeing the successful tool call for Salesforce, but we're not seeing any specific action on what's available for GitHub. That's simply not available. Doesn't even know that the GitHub's even, you know, available for a target tool. So it doesn't understand what's going on, but it knows it doesn't have access. That's all great and as expected. Now part of what we can do here is we could start saying through this gateway, you know, we could start enforcing various policies. Now most of these agents, they don't have owners. You might say, you know, I wanna make sure from a process standpoint that anybody who's building an agent within my organization has specifically a stated owner for accountability, and we don't want anybody to have access unless they do. You can quickly toggle that on. Otherwise, you can start leveraging different labeling within Saviynt to start saying, hey. Are these suspended, retired? If you have different critical findings or high findings from the different, policies that are built out within Saviynt Zuma as well, You could start leveraging these labels to start saying, hey. Do not allow certain actions to occur or any agents to take certain specific actions if these different labels are true for those agents. What I wanna showcase at a broader level is how do you even block agents by platform. So at the moment, I've selected Copilot. Any integration for different repositories or different, registrations for the cloud enabled AI agents will be available here as a selectable just, you know, selection box here to then say, hey. Which which platforms that are integrated with your Zuma tenant do you wanna start, you know, enforcing for this policy? And I'm gonna say this specific one for Copilot. I'm simply just turning that on. I'm gonna refresh this session. Now this specific agent didn't have access to GitHub, but did have access to Salesforce. So we're just gonna ask it again. Can you list out the top five deals within Salesforce? And, again, we just had that quick little toggle on the access gateway here. I refresh my session here within, Copilot Studio, and here you're seeing some bits of failing, some bits of completed. It's trying to figure out what's going on. Actually, it couldn't find anything. Right? It's coming back with an error. These things are not allowed. If you come to the access logs within Zuma, quick little refresh here, it's showcasing that error right here. We have a deny on the governance. The biggest and best part about this is that all this is highly performant, but you get clear indication of what's going on within these different control planes. So blocked by governance, request based on the specific, you know, gateway, policy, and it's even saying down here the denial reason is actually it's blocked because of platform policy and the platform being Copilot Studio. All this happened pretty quickly, 74, quick latency breakdown because, again, this gateway needs to be performant to be able to showcase these different actions. But with these types of controls, we're able to do a lot of different things that even if you're not the owner of these agents or you're just looking at these as an abstraction from an identity, security lens, you're able to start really enforcing different policies that make sure that people and the agents that they're controlling and utilizing are within the bounds of your expectations. Now the biggest and best part about this is you can also leverage different insights about what's going on with all your different gateways. You can look at any specific gateway information here if you'd like. We can expand this just so you have a little better view. So I wanna look at, let's say, my specific gateway here, my w k one. I can go and refresh this. We're looking at a bunch of different requests in the last week, some success rates, some failure rates, some things that have been blocked, and you can track these things over time. We can showcase exactly what's going on from different request errors or things that are going on from different block requests. And I've only been showing this specific part of the demo, so we're only seeing it based on platform. But the other specific reasons and rationales for blocking can always be here. We also have top targets. I only have GitHub and Salesforce onboard at the top, at the at this moment. And then the top tools, the specific interaction with those APIs on those targets for what's going on with these agents. And so a great little bit of insight, that's all great. What is something that we can do maybe in the next demo is highlighting how, as Greg was alluding to early on, the different runtime policies where we can start breaking down the intent of different things within our, outbound access to make sure that we're scrutinizing everything specifically. You can attach many different boundaries to, these specific gateways, but even when you're trying to manage your own, outbound access through policy, you can start looking at things from whether or not we have deviation on intent, on anomalies in the behavior, drift in the agent behavior, and what sort of actions you wanna occur here. Do you wanna just monitor this for right now, or do you wanna start blocking it based on different thresholds? if If things go wrong with your agents, know that you can come into the governance page here. Come to your agents. I'm sorry. I come to the inventory. And if I want to and I did this earlier. If I look for my webinar agents, I did this yesterday to showcase it. It's been actually deleted from my specific, Copilot studio, although I did create a new one with the same name, webinar agent w k. But we deleted one yesterday in preparation for this demo. So this other agent, they'll I'll just take the same one, the duplicate name here. If I would like this to go away, simply come over here, I can delete this agent. I could block it, or I can simply say, I would like to delete it. What's the reason? Well, demo purposes. Did bad things should not be in use anymore, and we delete it. Now this does have to reconcile through the integration. So at some point in time, after this is processed within Zuma, it'll go reach out to, Copilot studio and remove this specific agent. And there we go. Delete it here. Coming to the timeline. No specific data there. But that's the kill switch. Do love everything we're doing with Zuma. I think this is pretty powerful for organizations who are looking to get greater control over what's going on with their agent programs right now, which is obviously a a nascent space where a lot of people are starting to need greater tools, but more importantly, better visibility. Excellent, Warren. Thank you very much for that, excellent demonstration. And, we're out of time right now. So thanks again for joining us today as we walk through a few of the capabilities of Saviynt Zuma. And if you'd like more information on how Zuma can help you accelerate the adoption of AI within your organization, please reach out to your Saviynt account executive or visit us at saviynt.com to register for a free 30 day trial or a customized demonstration. And with that, thanks again to Warren for helping us out, and thank you to everyone who has taken the time out of your busy schedule to join us.