Agentic Runtime Security Explained: Securing Non‑Human Identities

[0:00]Hey everybody. We're here to talk today about probably the most white hot topic in IT today, and that is Agentic AI, in particular, how you actually deploy Agentic AI with Agentic Runtime Security. This topic begins and ends, really, with identity and access management. And the reason that's causing a lot of problems right now is because when you talk to CISOs and IT teams about identity, the first thing they think about are human identities. However, Agentic AI is a form of non-human identity. What's so ironic is that today it's said that roughly 80% of all cyberattacks actually happen around identities, around compromised identities, and that's just on the human side. But it gets worse really fast, because it's said there's what? 45 to 90 non-human identities for every one human identity, with a dramatic form of it being Agentic AI, and that's where you're going to see so many of these problems are being introduced. So there's a lot of forms of non-human identities. Yeah, non-human identities come in many forms. Traditionally, it would be a workload or a microservice or a container. But when we think about AI, they're really just those kind of workloads. They're TypeScript, they're Python, they're running on a container, on a Lambda, on a virtual machine, and we provide them identities, which is the non-human identity part. Exactly. So what we're going to show you are what are the truly gaping holes that organizations introduce into their end-to-end identity access management processes when they deploy Agentic AI, and that means almost everybody. So let's take a look at that. So we start with a user who is invoking some kind of application, which is then invoking some kind of agent. Some kind of AI agent, and typically you'll have embedded ones in multiple of these, and eventually you get an agent that then calls out into some sensitive data, in a database on a mainframe, whatever it happens to be. The way traditional human-centered static identity and access management works is it protects you to this point, that first agent. But where the problems come in is once we get into the embedded agents going to the back end resources, which literally introduces four crucial holes. Yeah, and the first one is about accountability. What does that mean? When we provide accountability to these AI agents, we need to assign them some sort of identifier, ID, so they are unique. We know exactly each instance of each agent, and we can trace back, what is it doing? The next is going to be over privilege. And we see this all the time. We talk about least privilege and zero trust, but AI agents, think about maybe an HR agent, is authorized to go onboard or off-board an employee. But we don't want that privilege to be existent at all times that the agent's running. We want to lock it down for the request and the action when it needs it in that session. And because what happens is you'll have a developer that's not really sure exactly what the breadth of privileges needed are, let alone all the different risk factors that are at work. So all of a sudden, these agents are pulling in these privileges and before long they're over privileged and nobody's looking. Nobody's auditing. Nobody's auditing, nobody's throwing it back. The next one is delegation. So often times we want to delegate one of these AI agents to act on our behalf. If Tyler is in HR, I delegate to this HR agent to operate something. That is an important problem. How do we delegate successfully with intent and with audit logging? Exactly. And there's an extension of that of impersonation, where you might have an agent that is lazy, if we can use that term, that says, well, I'm not going to get a unique identifier, non-human identity for me. I'm just going to inherit the identity of the user that invoked me. And as soon as that happens, it may go through, but you've lost your accountability at that point, because you don't know what that agent did, because it's impersonating the user. And this happens all the time with the new development of co-work agents. Co-work agents running your desktop, they act as you, they operate browsers as you, and they are impersonating you. And no one from a security perspective is the wiser. Was that an agent operating, or was that the user? The last is the last mile. From an agent to a database. What does that look like? Is it standing privilege? Are they all sharing the same database credential? Well, if that's true, and we've run into a risk model, how do we revoke last mile access as these agents are doing things, often times, at machine speed, how do we analyze, how do we revoke that? That last mile problem is a hard one. And this is the one that stops everybody in their tracks, because it's not only, you know, at hyper speed these are happening. But, just think of the logic here. You have these probably over privileged agents, maybe impersonating agents that are accessing a piece of sensitive data, and you don't know where in the whole process, how long after the actual access is taking place. So technically, what should happen, right, intuitively, is when that agent calls that sensitive data, someone should check, is that access still accurate for the context and risk factors that we have? And guess who's checking? Nobody. That's the last mile problem. We're not making the most basic check of all. So this brings together what we would consider the five imperatives of bringing AI agents to market. I like to think of these as definition of done for any AI project. So the first is, register your agents. You must have a registration. That looks like, I bring this agent in, I know what it is. I provided some sort of identifier, ID. And I've probably even gone through the process of quantifying risk of this agent if it's making external connections, and they're all making external connections. Then we strip privileges. All privileges get stripped away, we use dynamic privileges just in time at the session level, so it doesn't have the ability to always onboard or offboard employees. Now you see how different that is than what the human identity management side is. You say, I've got a user in this role, here's what access they should have, and that isn't going to change for the next two years sometimes, right? It's very slow and static. This is all real-time being done. Then we talk about tying all actions to intent. When Tyler is working as an HR professional and asking this HR agent to operate on my behalf, and it's going to go onboard or offboard an employee in that workflow. How do we tie that together? How do we know that Tyler has asked agent X to take this action? That is really a crux of an audit problem, because we have agents that are doing more than HR now. They're doing banking transactions, they're doing banking transfers, they're provisioning real infrastructure in clouds and on-premises, and we need to have this tie in. Yeah, you notice it keeps coming back to accountability. Well, speaking of accountability, the last is forcing point of use. And this is our last mile problem, making sure we have enforcement at that point of use. We like to think about this as applying either risk or policy analyzing to understand this agent's making external connection to a database or main frame. At this exact time, is it authorized to do it? Not what it was authorized to do when I stood it up a month ago or two months ago, but for this action at this session, is it authorized to do it? Some some people even call this past the last mile, they call it the last 100 feet or 100 meters based on where you live. Yeah, it's called the last hop. If people can kind of recognize with that, the last hop of an agent making connection to something, we must analyze each one of those external connections in your real time. Yeah. And make sure it's doing what it's supposed to do. And then we have proof of control. And for those customers of ours that are working in highly regulated industries, healthcare, life sciences, financial services, this is fundamentally an imperative for everything you bring to market. And while it does tie into number three, tying actions, enforcing less points, we need to have this auditability through this whole chain. And no longer is it, okay, just to only audit from a human to an app, we must audit the whole continuum of human identity to non-human identity to actions and response. So what are the types of technologies that you need to do to be able to implement this stuff? So when you look at it, there are three dominant technologies that need to work together across both human and non-human identities. And so let's take a look at what those things are. First is orchestration. You need to have an orchestration engine that is managing all that stuff that Tyler just took you through between the human identity world and the non-human identity world. Right? That is huge. That's the who's directing the traffic and making sure that all the auditability and accountability is being baked in. Second is governance. Clearly the policies that need to be in place, everything from access here to the last mile, last gap, whatever you want to call it. Right, has to have governance applied at each step, so you can prove who did what. And then the final one is to me the most interesting one, because if you look at this picture, um, the issue that we've brought up a couple of times, that keeps coming up in every conversation because it's the thing that stops organizations from being able to move forward on this, is the organizational side of this, is that you have the CISO office, you have IT and you have Dev. Okay? I mean, the organizations need to be working together on this because all are involved, and yet most of the clients that we walk into, we'll ask the CISO, for example, what are you doing with the development team? And they'll say, oh, we have a monthly call and talk about initiatives that we should work on together. And then we say, what do you do the next month? And they literally say, we have a monthly meeting that talk about the initiatives we should work on together, and they kind of smile as they're saying it, right? Because development is trying to get this stuff out there to move the business forward, IT's trying to manage it, CISO is worried about risk. And there's just a lack of observability across this whole problem that these three groups can use to collaborate. So the third one and very dramatic one is observability. And observability around Agentic runtime security has two pieces to it. There's posture management and threat management. Posture management is it probably is a bit of a problem if my development teams have 13 different secrets managers or instances, like community editions of secrets managers, and uh cloud specific key managers and certificate managers. You can't manage risk that way. So maybe we should consolidate what we're doing around secrets management. That's an obvious thing, but until you see the problem, it's easy to ignore it. So observability from a posture point of view allows you to see how many non-human identity management engines do you have and how do we improve that situation? The second side of it is the threat management side. We just talked about how you need to make sure every agent has a unique identifier, and you're checking the access, you know, all the way to the last mile, et cetera. Can you tell in real time if there is a user, if there's an agent that pops up that never goes to the secrets manager, never gets a unique identifier? Instead of waiting for an audit to discover, oops, wouldn't it be nice to be able to see that in real time? So that's the threat management side of this. So the technologies of having engines that can do orchestration, governance and observability, both posture and threat management, across this picture is literally how you address that.