Why Agentic AI Breaks Legacy Identity — and What Infrastructure Leaders Must Do Next

Agentic AI is fundamentally changing how software operates, and in doing so, it breaks the identity and access models that many organizations still rely on.

Unlike traditional applications, agentic systems are non-deterministic, long-running, and capable of autonomous decision-making across infrastructure, data, and production services. These systems do not fit within legacy identity assumptions built for humans, static workloads, perimeter controls, or long-lived credentials.

As organizations rush to deploy agents, copilots, and MCP-based workflows, they are unintentionally introducing new classes of systemic risk: anonymous execution, credential sprawl, uncontrolled privilege, poor auditability, and fragile operational guardrails.

In this thought leadership webinar, Craig Matsumoto (Futuriōm) joins Teleport CEO Ev Kontsevoy to examine why agentic AI is not an LLM problem — but an infrastructure identity problem. Together, they will unpack how AI-driven autonomy changes threat models, why existing IAM, PAM, and network-based controls fail against non-deterministic behavior, and what “AI-ready infrastructure” actually requires.

Attendees will learn:

• Why agentic AI fundamentally breaks legacy identity and access control models
• How non-deterministic actors amplify blast radius, compliance risk, and operational fragility
• How leading organizations are reframing AI adoption around identity, control, and governance, not tools
• What an opinionated, production-ready identity framework for autonomous systems looks like in practice

This session is designed for engineering, infrastructure, security, and IT leaders who are responsible for production systems and are being asked to “move faster with AI” — without compromising reliability, security, or control.

AI adoption is accelerating. The identity foundation beneath it is not. This webinar explains why that gap matters — and how to close it.

Key topics on Why Agentic AI Breaks Legacy Identity — and What Infrastructure Leaders Must Do Next

• Agents are non-deterministic microservices: Unlike traditional automation (scripts, cron jobs), AI agents are LLM-driven and behave unpredictably, making them fundamentally different from prior infrastructure.
• Legacy identity systems weren’t built for this: Existing systems were designed for either humans (slow but unpredictable) or machines (fast but deterministic). AI agents are both fast and unpredictable — a combination no current identity system handles well.
• Reframe “security” as “resilience”: The better mental model is preventing accidents — including misconfigurations, not just malicious attacks. Security is just one class of accidents.
• Scale amplifies risk: Agents can operate at massive speeds and volumes, meaning low-probability failure scenarios become near-certain at scale.
• Infrastructure leaders must act now: A new identity foundation is needed — one designed explicitly for non-deterministic, high-speed, non-human actors.

Expanding your knowledge on Why Agentic AI Breaks Legacy Identity — and What Infrastructure Leaders Must Do Next

• Blog - AI Infrastructure Needs an Agentic Identity Framework — We’re Building It
• 2026 Research: The Top AI Infrastructure Risks and Identity Gaps
• Solutions - Securing Agentic AI
• Docs - Securing Agentic AI with Teleport Zero Trust Access

Transcript - Why Agentic AI Breaks Legacy Identity — and What Infrastructure Leaders Must Do Next

Introduction

Chris: Thanks for joining us today. We’re getting started right on time. I know some folks are still joining, but I’ll let them come in. Thanks to everybody who registered, who’s attending, I appreciate it. Thanks for joining us today. I’m Chris Weber. I’ll be hosting today’s session. Today, we’re going to be talking about why agentic AI breaks legacy identity and what infrastructure leaders have to do next in order to get ahead of that. But before we do that, as always, we’ve got a couple of quick housekeeping notes. The first one is, if anybody knows why it’s called a housekeeping note, I’m always curious. I’ve said it 600 times, and I should have looked into it before, but it also seems like it’s keeping things tidy. But please note the chat box over on the right side of your screen. You can use that to ask questions. You can use that to post comments, engage with us. I’ll keep an eye on it, but we’re really grateful and lucky to have Camden Cox here. She’s man in the ones and twos, keeping us on track. She’ll really be watching that. And adding the questions, there will be something she’ll be taken care of. We’ll try to get to those questions at the end. We’ll do our best to answer all of them. If we don’t get to them in time, we’ll email you with a follow-up afterwards for sure. Of course, everybody is going to get a recording of this webinar within the next 24 hours or so. So you don’t have to worry about typing and taking notes as we go along. You can have that in the future.

Chris: Today, we’re going to be discussing things like why agentic AI doesn’t fit legacy identity models, how to think about non-determinism, how to think about accidents, how to think about risk, and kind of what a resilient identity foundation needs to look like moving forward. But before we do that, I want to introduce a couple of people who are eminently qualified to do just that. We’ve got Craig Matsumoto. Craig has a long and storied history. From Futuriōm now, lead editor from in the past at SDX Central during the rise of cloud-native infrastructure, the rise of Kubernetes. Then, a senior analyst at 451 for a lot of years covering data center interconnection, multi-cloud networking, edge AI. It’s like couldn’t be more relevant throughout time, and now looking also at AI and data center infrastructure, cloud management technology, Kubernetes, of course, and then quantum computing as well. Craig, did I leave anything out besides jazz?

Craig: You left out the jazz part, but I guess you threw it in there. It all sounds familiar, so I think it’s accurate.

Chris: Perfect, perfect. If we have time at the end, I would love to just talk music. With Ev’s microphone, my background, and your skill, we could probably really do something, but I’m not sure.

Craig: That sounds great. All right, fine.

Chris: We also, of course, have Ev here, the co-founder and CEO here at Teleport. Ev’s an engineer by training all the way from way back, a serial entrepreneur who’s been deep in cloud since we called them colos just about, all the way since the beginning that was there. You’ve seen a lot of evolution. I know since those days. We’ve talked about it. And right now, we’re in the middle of a big one. And the beginning of any evolution is often when things are settling out, new teams or certain terms, ideas. They’re all coalescing. So for today, before we get too far, I think it might be worth talking about what we think about when we’re talking about agent as a word or agentic AI versus all the different concepts that people might have out there. You want to get us all on a baseline there?

Defining AI agents

Ev: Hey, good morning, everyone. Actually, it’s a good thing you’re pointing out that the industry right now is lacking a well-accepted definition of what an AI agent actually is. It’s something that we in technology see quite frequently when the language is lagging, the technology development, because obviously the rate of technological change that is happening right now due to AI is so great that we’re basically struggling to come up with to update our vocabulary. But I think for the purposes maybe of this podcast, for the next 30 minutes, when we talk about the AI agent, let’s just make an assumption that what we’re talking about is a microservice that is running in a data center, that is running in a cloud environment, and it’s behaving nondeterministically. So it’s driven by an LLM. So that, I think, would just provide additional clarity for this conversation, because there are other types of AI agents that we could potentially talk about, but let’s just focus on this one.

Craig: Yeah. And I would add, a lot of what are being called agents right now are pretty small. Like, you could have something that’s really a script that people call an agent. But I want the conversation to include some of the potential of what agents can do, because you have to start — eventually, we’re going to have to think about these as compound functions, agents launching other agents or contacting other agents. I mean, just some of the things I hear developers talk about, some of the ambitions, get pretty large, pretty broad. So agents are non-deterministic and not necessarily as simple as they are today. That’s the perspective I’d like to bring.

Chris: Makes sense to me, that nondeterminism being at the core. I think that’s also what is on a lot of people’s minds when this shift has been happening, right? I’m old enough to have been in IT back well before AI was even anything we saw outside of movies. But we did have a lot of cron jobs, automation, right? We had a lot of service accounts and things that we kept together. And the problem there was that I might mess it up. I might not be so good at writing my script to do exactly what I expect it to do, but that was just a bug, and it crashed out most of the time. And when you got it right, you got it right; you could count on it. But I think that concept still — it’s changed a little bit, I guess. But I guess for both of you — I’ll start with you, Ev — in this concept of getting nondeterminism under control, I think we were hearing more and more about resiliency as a topic. And it’s sort of always in the conversation with security, but how do we think about, or how should we think about, resiliency when it comes to this new non-deterministic AI?

What makes infrastructure resilient

Ev: Yeah, thank you for bringing this up because the one thing that bothers me when I try to — when I read and consume some of the information that’s being offered out there is that people frequently talk about how do we secure AI, secure AI, and it’s just not very helpful framework. I genuinely am not a big fan of the word security because it can mean so many different things. But at the end of the day, we just want to make sure that our infrastructure is operating and it’s doing what it’s supposed to do, that we’re not facing downtime, that we’re not losing data. So that kind of goes into this broader umbrella of resiliency. So your infrastructure is resilient if it is resilient against an accident. And then security just becomes — that’s just a class of accidents. That’s the framework that I prefer to apply, because there could be other accidents as well that are very much related to identity. And those accidents, frankly, have nothing to do with security. You could talk to almost any engineer, and they will be able to tell you a story from when they were younger or whatever. It’s like, oh, man, yeah, I accidentally deleted data in production because I accidentally used the wrong VPN endpoint or grabbed the wrong inventory file or the wrong profile file for — so basically accidentally connected to the wrong thing and nuked the data. So that is also an accident, but no one got hacked. And when we talk about AI agents and when we talk about identity, I want to offer an interesting — I think it’s obvious observation, is that we essentially — we’ve always dealt with two types of actors. One would be humans. So humans are incredibly unpredictable. So we can get curious. If we don’t get enough coffee in the morning and we didn’t get enough sleep, we could just do stupid things accidentally because we lost concentration. So humans can make mistakes. Humans could be bad actors because they can bribe someone in your organization to go do something. So essentially, it’s impossible to predict what a human might want to do. So that’s the non-deterministic behavior. Okay? But humans are also kind of slow. It takes us 250 milliseconds to kind of process information and react to it. So we’re slowly clicking buttons. So kind of the rate at which our accidents can cause damage is sort of limited. So you can imagine maybe a two-dimensional space where on the x-axis, you see how unpredictable an actor is. And on the y-axis, that’s basically how fast the speed, how quickly we can do something. So humans are obviously very high on non-deterministic dimension, but we’re very, very slow. Therefore, all the identity systems that we’ve built and we’ve been using for all these years that are designed for humans — that are designed with that assumption in mind that you are, as a human, non-deterministic, but you’re also slow. Then if you look at the world of the machines and you have all this automation and you see ICD pipelines and cron jobs and traditional microservices, so those things are extremely fast. They could do hundreds of thousands, maybe a million transactions or operations per second. So if they go wrong, they could cause incredible amount of damage very quickly. But they’re extremely predictable. So if you look at the source code, if you understand what this thing is doing, it will do this and nothing else forever and ever and ever. So therefore, all the systems that we build to manage non-human identity, they’re optimized for deterministic, so very low on the y-axis, but extremely fast. So that is essentially, in a nutshell, the problem that we’re going to discuss on this podcast — is what we’re going to do with this. So we have two classes of identity management systems, and they’re optimized for these two extremes. An AI agent, as we defined it earlier, obviously doesn’t fit into any category. It is non-deterministic, just like humans are. At least it has potential to be just as deterministic as a human. And at the same time, it can be as fast as a typical microservice because it is code at the end of the day. So now we need to scratch our head like, “What kind of identity system do we need to use to contain these non-deterministically behaving agents? How do we prevent accidents happening in our infrastructure?” So that’s the way I see it and how I propose we talk about this during this conversation.

The problem of scale and managing non-human identities

Craig: Yeah. I would actually add, it’s not really another axis, but another dimension of the problem, which I guess would be another axis, wouldn’t it? It would be scale. We already deal with activity at scale just in terms of automation. But with agents, scale is a problem because when you talk about accidents, if something has a million to one chance of happening, you’re more likely to hit on that if you’re doing 10 million or 100 million actions a day. Part of the unpredictability of agents is how many you’re going to have to deal with. If you look at, for example, Wikipedia and their pleas for help because of the number of LLMs that are hitting on their servers all the time, you can have those unpredictable bursts. I think that’s part of the fear — is that AI agents can descend on you at a scale that you’re not necessarily ready for and a scale that will discover all of the little cracks that will lead to accidents.

Ev: Yeah. Also, as I was listening to you, maybe we should acknowledge something that — I’m not sure if the audience is going to agree or disagree with me, but that’s definitely what I’m seeing when I’m interacting with industry practitioners. And the observation is that non-human identities are actually not managed very — frequently not managed at all. It’s because they’re deterministic and people just generally feel that we have enough problems with human identity already. So NHI, generally, as a field is somewhat underdeveloped. So it’s quite rare that I would come across an organization, like when they deploy a classic microservice into production, that thing has its own kind of durable identity that they’re fully managing. Some teams do. Sophisticated tech companies, obviously, kind of fall into that category. But generally, non-human identity has never been managed well in the enterprise. So that’s an observation that I think is worth making. And AI is forcing everyone to rethink that. And another comment I wanted to make, kind of speaking of scale, just an anecdote I wanted to share. So we’ve been interacting with a financial institution, a fairly sizable one, where they — so they recognized that in order for them to do the same amount of work as 2,000 humans can do on this kind of data parsing data entry side of the equation, so they are trying to build an AI system, essentially an AI agent, that will run — there are going to be many instances of it. And the ratio that we’re seeing is kind of AI agent identity to human is essentially two orders of magnitude difference. So instead of having 2,000 humans, they’re looking at 200,000 AI agents. So the comment, Craig, that you’re making — that the point you’re making about volume is very much real.

Chris: Yeah, that scale is easy to lose track of when you’re thinking what some people are thinking about. I’ve got an agent in my browser that does a thing, or it’s a little helpful chat agent. But when we think about just non-deterministic AI in general and how we’re going to use those and how they spawn up, I think it’s easy to see the numbers just like you’re talking about. So accidents as a class of, I guess, a superset that can happen, right, where security problems are maybe one of those accidents that can happen. But just something going off and doing something unpredictable is an accident. When we combine accident or the concept with nondeterminism as a concept, it’s easy to just start backing away and being like, “Well, how about we just narrow that down so much that we take a lot of that nondeterminism away?” And I know a lot of folks that I’ve spoken to are thinking about that or asking me about that, right? “How can we just put this thing on rails, make sure it only goes where we’re going to go?” But we’re having different conversations, right, with folks. I know both of you — we’ve talked about this. “How much do we want to step away from nondeterminism? How much do we want to lean into non-determinism?” Just in general. Either one of you, why don’t you— I know you have thoughts. We’ve talked about it a lot.

Non-deterministic behavior vs. security

Ev: I think it’s kind of interesting that it’s — so from infrastructure resiliency perspective, non-deterministic behavior is awful because it’s really hard to— the people instantly start asking all these questions like, “How do I contain it? How do I put it in a box? How do I put it on rails?” But if you make it perfectly predictable, then you essentially kill the value of AI, right? Because what’s the reason we’re so excited about this technology? Because it’s supposed to bring us new insights, because it’s supposed to help us discover new things sooner and faster. So non-determinism is actually great. So that’s the value of AI. You want this thing to be curious. You want this thing to suggest to you new ways of doing things. But again, it’s terrible from a security perspective. So it’s a trade-off that’s been with us for years, years and years, kind of productivity versus security. So non-determinism is the key to potential productivity gains that we can get from this technology. But if we try to secure it in a naive way, then we’re essentially going to kill the value.

Craig: Yeah. When I’m discussing AI and agents with people, I don’t know if this is good or bad, but I keep falling back on my instincts as a parent because we had kids, right? And what is a toddler but a highly non-deterministic agent? So you don’t want to — you don’t want to — you can’t lock down their behavior, but you don’t want to restrict them too much. You want to let them explore. You want to let them learn. But at the same time, you have to take precautions. So even now, my children are grown. They have left the house. They’re leading real adult lives out in the real world. But at home, I’ll still push glasses away from the edge of tables. We still keep all the sharp things in a higher drawer, further away from the ground. There are precautions you can take. So we do prize the non-determinism of AI.

Craig: And to answer, Ashaji had a question that’s in the Q&A box about, “Couldn’t you have a fully deterministic agent?” You could, but most of the security concerns come up from the non-deterministic ones, the unpredictable nature of agent behavior. And it’s the non-determinism that creates the magic effect of AI. So you don’t want to get rid of that. But you also don’t want to use it without taking some precautions, without putting those little safety corners on your coffee table, so to speak.

Chris: You really care about AI. You’re going to nurture it and raise it.

Craig: [crosstalk] use all my money to go to college and—

Chris: Yeah, to the scale of 200,000 students going right there in your house. No, it’s an interesting concept because what I think I’m hearing is — it’s a fun analogy, right? You don’t want to stifle. You don’t want to stop what is so good about being able to find new ways to solve problems. And at the same time, if there’s a drawer full of knives, then maybe there’s a reason to go into that drawer. And then unless there’s a reason to go in that drawer, it probably doesn’t make sense, right? There’s some safeguards on the drawer or other things that you might be able to take care of. We’ll have to see. But I don’t know. Is that kind of — am I understanding?

Securing your infrastructure landscape

Craig: Yeah. And this is kind of — this kind of touches on the whole concept of identity. This is where we can get into some of that, because if you look at your average enterprise organization, especially — well, average. If you look at a larger enterprise or an older enterprise, there are probably lots of ways to get into systems and into data, lots of ways into the infrastructure that nobody’s thought of or that were left open on purpose that nobody just considered it for a while. I’m thinking, for example, of admin privileges that somebody may have created for themselves five years ago, seven years ago for one time, or executive accounts that are just overprivileged. Somebody insisted they needed access to A, B, C, and D, and so I just gave it to them because it was easier than arguing. These are essentially doors that are left open. They might be all over your infrastructure landscape. And a lot of them have gone unnoticed or forgotten by this point. There’s a lot of potential holes. So if you get back to the scale of AI and the fact that it’s non-determinism multiplied by that scale means it’s going to find things that you didn’t know existed. It’s going to stumble onto these accidents that I’ve talked about. You can see how all these open doors could create problems, both accidentally and for malicious actors, right? You could have an AI bot to sneak around and try to find some of those open doors.

Chris: Interesting. Yeah. I mean, I think that makes a lot of sense. I think what I’m hearing is, of course, we all know — I mean, I remember working at a different place where we were trying to help folks understand those roles that sat around. And they said, why don’t we just send them to you? This is the company that’s been around 25 years. It took three days for them to just upload the roles into a file that they could share, right? It was millions, literally, of roles that were sitting around. And they certainly didn’t have millions of employees. I’m not sure that anyone does. But it is just hard to imagine. But also, I heard this concept of getting to things in a different way, maybe an access path, right, that people don’t think about because of those roles, because of those privileges, perhaps. I know, Ev, you often talk about duration of time when you’re thinking of complexity of infrastructure, right? The more complex your infrastructure gets, how much time does it take for something that you don’t expect to happen? I think that’s kind of part of what we’re talking about here, right? This fragmentation, especially because, coming back around your analogy, Craig, with the kids in your house, you know exactly who those kids are. You probably have a few of them. They have names. But with agents in your infrastructure, we might not know, right, Ev? I mean, it could be total anonymity going on here.

Anonymity, identity fragmentation, credential sprawl

Ev: Well, I see it’s actually connected to some questions I’m seeing in chat about what are the actual technical hurdles and what are the problems that are related to identity and deploying AI into production? I would say that there are three things that we’re hearing that enterprise is extremely concerned about. Thing number one is anonymity. Thing number two is identity fragmentation. And the third thing is credential sprawl. So maybe we could talk briefly about each one. So why is anonymity a problem? It’s because if you are an organization that existed for a while, so you have layers and layers and layers of technology deployed and running and making you money. And as I said earlier, non-human identity is mostly not implemented in most companies. So you have anonymous servers, you have anonymous databases, you have a bunch of accounts that you don’t remember what they’re all created for. So essentially, you have anonymity in your environments. And now you’re prepared to deploy an AI on top of it, and everyone is paranoid. People are paranoid because you cannot protect something that you don’t manage. You cannot protect what you don’t know. And we’ve been getting these questions like, “Hey, how do I build a firewall around my AI?” So how do I basically create, maybe, a completely different environment? So my AI is going to run over here, and all my legacy stuff is going to run over there, simply because almost every organization has some kind of database somewhere in the corner, and they forgot it even existed. So this anonymity, like the fact that you have a lot of actors in your infra already that don’t have identities today, and you need to protect those things against AI, so that is a challenge. Or maybe using a slightly different language, if you need to apply policy on something, so the policy needs to enumerate, why are you allowed or not allowed to touch? But if those things that you should be or should not be touching are anonymous, you cannot even name them in your policy.

Ev: So that’s the first thing. People are realizing that most of their infrastructure actually doesn’t have an identity. And this is why we’re popularizing. So the concept is like, “Hey, if you want to be a hyperscaler, if you want to — if you want to do it properly, you need to bring concept of identity into your infrastructure.” Your infrastructure needs to have a common identity layer that keeps track of every server, every database, every microservice, everything, really. Because that is a prerequisite to run AI in production. First, again, your infrastructure now needs to have its own identity. And it’s not Okta. It’s not Active Directory. It’s not Sailpoint. None of these things. It’s infrastructure identity that you need.

Ev: Second thing, identity fragmentation. So you mentioned the problem of access paths earlier. So let me make it very real for the audience. So imagine a database with a table that you have. Whether it’s Oracle, MySQL, it doesn’t really matter. Ask yourself: who can potentially get this data? And all of us, people who are responsible for infrastructure, responsible for security, we have this subconscious loop that’s running in our head where we enumerate all the possible ways how that data could be stolen, how that data could be accessed. So you can connect to database directly. It listens in the network socket. So you need to secure that or harden that access path. Strong authentication, encryption, turning on anonymous accounts, all of that. But then, if you’re using Kubernetes, I can go through Kubernetes API. I could get into a pod, to the attached volume. I could get to your data that way. You need to harden your Kubernetes access path.

Ev: Then I can SSH or RTP into that box. I will bypass your database security, so you need to make sure that is closed. But if you’re on AWS or Azure, I could use virtualization API. I could just get EBS volume dump, and I will get your data out that way. I can get into your Jenkins, or GitLab, or your CI/CD pipeline because those things have credentials for database as well. So you see this thing — or I could get into a microservice that you’re running, and that microservice has credentials to the database. So these access paths in an organization of any kind of reasonable scale, you have an infinite number of them. Not too many — or it’s basically infinite because attackers, they could combine different permutations and combinations of all these different hops and intermediary hops. This is why it usually takes several weeks to discover which access path an attacker used in a situation where there was a data exfiltration. What causes these access paths? Why do we have so many? Identity fragmentation. Your MySQL has no idea about your Okta identity. The identity your microservice use is completely different. Basically, all of these protocols that infrastructure is capable of speaking, those are not managed by identity platforms made for humans. And that is why most organizations also have more roles than they have employees because they have to generate all these different roles for different access paths. So identity fragmentation is a terrible thing. And sorry, I’ve been talking for a long time now. And the final thing I want to touch on briefly is the credential sprawl. So all of these access paths that we talked about that basically exist in hundreds, if not thousands, what are we using to govern whether a specific identity can log in into those access path? Well, credentials. And people have this kind of ideas that, oh, some credentials are better than others. So for example, a private public key pair for SSH is better than a password, for example. It’s like, how is it better? Your private key is a password. It’s just really, really long. API keys, that’s another form of credential. That’s also essentially a password. Browser cookie. That’s another form of secret that if I take a browser cookie, I can become you. So what do we do about — and by the way, credentials, at the end of the day— that is what connects security to accidents. So if I ask the audience, what’s the probability of your organization getting hacked during this podcast? The smart people will say it’s not zero. It is relatively small, so this is why I’m on a podcast instead of running around being scared and paranoid, but it’s not zero. And then if I ask you, “Okay, but would you agree that probability of you getting hacked is directly related to probability of one of your employees making a mistake?” Most people will agree, yes, because humans are the weakest link. And what happens when humans make a mistake?

Ev: The first step is usually that the credentials leak your organization. Over 80% of all hacks, they begin with leaked credential. So you have this connection between employee behavior, human mistake, leading to credential leakings, and you have more and more credentials accumulating over time as you scale. Because you’re going to hire more people next year, so the probability of credential leak is going to go up. You are going to get more hardware all over the world. Probability will go up because there are going to be more credentials. And then you’re going to deploy more and more stuff, more software into your infrastructure, so more and more credentials. And all of this is happening at the same time, compounding, which means that probability of credential leaking is growing faster than your org, is going faster than your revenue, which means that at some point, there’s going to be this complexity wall that you’re going to run into, where every hour, there’s going to be a credential leak. And AI, because of that volume point that Greg brought earlier, that is like we are exploding on complexity dimensions. So that moment is going to come sooner. So you have to solve this problem. And that’s basically what we’re preaching — that you have to have an identity layer because it gets rid of anonymity, and it removes identity fragmentation for your infrastructure. And you have to move away to a system that doesn’t use data as a credential. If there is no static credential, which is data that can leak, then your infrastructure becomes resilient to human behavior, so this is why we advocate for hardware Root of Trust. That is the only safe implementation of identity where your authentication happens based on the possession of a physical thing. That’s a TPM on a laptop, biometrics for humans, hardware security module, or HSM on servers.

Ev: So that is what needs to be used to implement credentials in this AI native world. Sorry, it was a long answer, yeah.

Why you can’t put a firewall around AI

Craig: But it was a good one. And I think everything you just said of getting back to one of your earlier points, everything you just said explains why you can’t just put a firewall around AI or why a list of firewall rules is not going to stop accidents or stop security breaches. It’s because the problem is infinite. It is compounding and always growing and always adding new possibilities. No laundry list of policies is going to keep you completely safe. But I think what I hear you saying, too, though, is that we need to rethink the way identity is applied. We need to think of identity more systematically and strategically as opposed to iteratively, just assigning credentials per person or per role. And you mentioned hardware Root of Trust, but the final answer is not just to simply implement hardware Root of Trust. That by itself is necessary, but not sufficient. Am I getting that backwards? It’s important, but it’s not everything.

Ev: It’s better than not doing it, right?

Craig: Yeah. You should do it, but —

Credentials are vulnerabilities

Ev: The key to realize is this — our CTO, for example, constantly, when we evaluate our own security posture, when we interact with our customers, instead of enumerating all these access paths, which is, as I said, pointless, what we’re enumerating is where is all of this secret information stored? How much of it do you have? If you have a credential, it’s a vulnerability. That’s our view. Encryption doesn’t work. Putting it into a vault doesn’t work. Rotation doesn’t work. If you have some kind of secret anywhere in your organization in any kind of shape or form, and if it finds its way into your human hands or AI hands, it’s game over because now you’re becoming exposed to this brutal math of probabilities. It means that you’re going to get more of it, and then eventually it’s going to leak. So you simply need to start practicing this periodic pruning of credentials that actually even exist in your infra because the end goal is to bring it down to zero. When you can safely say that there is not a single piece of information, basically a secret that someone can steal and then use that to log in back into my infrastructure, that’s the state you need to be in. It will not, as Greg says, it’s not going to guarantee that you’re completely unhackable, but you will get yourself off that hamster wheel that you need to constantly run and keep patching all of these different access paths. So we believe that is just prerequisite to deploying AI in production. And once you have that, so then AI basically gets exact same identity as everything else. So the one thing that we’ve been popularizing, and it’s now getting picked up, and it’s becoming a more and more popular point of view — is that there should be no difference between human identity, non-human identity, or hardware identity. It’s all the same thing. So your laptop, you, the server, the database runs, the database itself, the AI agents that run nearby, interact with you, and interact with the database. All of these have to be treated exactly the same way. You can think about the use case where you have CEO of a company asking AI agents like, “Hey, who’s the most paid employee at my organization?” Think about what kind of policy you have to employ here in order for that agent to actually be safe, because that agent can interact with another employee, with an intern. An intern may ask the exact same question, which means the permission for that agent to answer that question depends not just on the agentic identity, but it also depends on identity — I’m sorry, identity of a human who asks. See, right there, you have a policy that’s mixing different identity types. And so if you fragment identity, going back to that identity fragmentation problem, you will not be able to enforce this. So you have to have a single identity layer that manages identities of your workloads, that manages identities of AI agents, and also manages identities of humans.

Chris: I think this gets — so first off, I was looking at the — we hit some of the Q&A in line, which is great. So Gloria had a question about top themes folks were struggling with. So saw that response, nice work. And I saw Gene has a similar — at least I think it dovetails nicely in here, where it’s like, “How can we map AI to the tasks when there’s a specific thing that needs to happen?” And Ev, you just kind of talked about it, right? The same task for one side is very different on our question, right.

Assigning privileges to tasks rather using RBAC

Ev: Chris, that question, by the way, is amazing because it leads me to one of my favorite topics that I want to remind people about, hey, role-based access control actually doesn’t work. If you go back in history and read how RBAC was invented, it was invented because access lists were getting out of control. So organizations were just not keeping up with so many employees that needed access. So we created this idea of having groups or roles. But here’s the thing. Go talk to any organization right now, and they will tell you that they have more roles now than they have employees. So if you have, for example, 2,000 employees and 20,000 roles, then you don’t really know what you have. You cannot even reason about your security posture when you have roles measured by the thousands. And then if we apply two orders of magnitude, math, that applies to AI, which is another place where AI basically completely breaks everything. So now you’re going to have two order of magnitude more roles. So what do you do instead? So here’s what we believe is the best practice. The privileges should not be assigned to roles or to identities in general. Privileges must be assigned to tasks.

Ev: So imagine the situation. I know it’s going to be futuristic, but we try to get you all excited here. So imagine the situation that you have a massive infrastructure. Two million servers sprinkled all over the world, and they’re making you money. They’re processing transactions. Everything is fine. So that’s kind of steady-state operation, okay? You’re not doing any deployments. You’re not making any changes. Everything runs in a predictable way. So that’s your steady state. And in that steady state, your infrastructure spends 99% of the time, by the way. It doesn’t need humans. It doesn’t need you. So in such a state, wouldn’t it be great if you had no roles at all? Zero roles. Zero roles, zero user accounts, zero nothing. So no one can log in, no one can do anything, and that is actually fantastic because it’s a state that’s very easy to reason about.

Ev: But then you need to introduce change. You need to do something that only humans can do, or maybe only AI can do, non-deterministic stuff. Now you begin by creating a digital artifact of that task, a ticket. And by the way, most organizations, maybe even all organizations, do that already. So let’s say you create a deployment ticket. Then you assign me — every engineer needs to do deployment. So you assign my identity to that ticket. I need a laptop to do it. My laptop, remember, we don’t want to allow anonymity. So identity of my laptop needs to be assigned to that ticket as well. Then identity of an environment, which I will be deploying into, needs to be assigned to the ticket. I got to use Jenkins for my CI/CD. So identity of Jenkins goes in there. So now you have a ticket and you have all the identities that will be working on this task. And then you sprinkle privileges on top. And then you hand it off to your identity layer system, and it goes and provisions all these privileges. I go do the deployment, then I close the ticket, then guess what? You wipe everything back to clean state. That is a much simpler, much more scalable way to do privileges. You don’t need roles for this. I realize that it’s not easily implementable with all these kind of layers and layers of legacy that we’ve accumulated over the years. But that’s this kind of gradual transformation, the direction for gradual transformation that we are strongly suggesting simply because there is no other way of doing it. So that’s what I would recommend.

Chris: Yeah, totally makes sense.

The ephemeral nature of agents

Craig: It does make sense, especially with the ephemeral nature of agents, right? What we’re envisioning for agents in the future are these entities that spring into being, do their one task, and then vanish. You can’t be assigning permanent roles or permanent IDs associated with that kind of behavior. It just makes sense to assign privileges by task. You know what it — what you just described, it sounds like an evolution of the concepts of Zero Trust or whitelisting where you put even more restrictions on what people can do. I think of Zero Trust as like blinders. Somebody’s only allowed to access certain things. You’re talking about an even narrower view where somebody’s only allowed to do one task. And it makes sense, and it’s more scalable. It’s an elegant way to scale to the volume of activity that we expect to see from AI and agents.

Ev: Yeah. I think It’s a great analogy. So the only twist versus what people usually think about Zero Trust here is that instead of assigning privileges to identities, you’re assigning privileges to tasks, and the reason is, and I think it’s now probably obvious, is that there are fewer tasks that there are identities and groups. Identities — they tend to multiply and explode, particularly now with AI, but the actual tasks that we’re doing, they’re not exploding that quickly. So you are going to run exact same deployment task, for example. It doesn’t matter if you have 100 servers or 100,000 servers. So it’s not the number of tasks, the number of things we actually need to do, it grows maybe logarithmically while your infrastructure is growing linearly, but your identities that are growing exponentially. So that is why it makes sense to govern behavior as opposed to govern identities.

How privilege can be assigned to tasks

Chris: I think what we’re seeing too, and first off, what I’ve heard, just a little quick summary, right? It’s like there is no — I like the very end, sprinkle privilege on top after you’ve figured out, right, based on the task, what needs to be done, the systems that are in place, what happens there? We set that up and then we tear it down afterward. So it’s not sitting around, right? Unlike the roles of the past that we’ve talked about a few times, and in all seriousness, they just keep getting longer and longer and forgotten about. But I see, in some of the chat, a couple of things coming in where I think people are feeling like that’s a manual effort. I have to go over to Kubernetes RBAC. I have to set up this temporary situation so that CI/CD can run, F can do his thing. But those systems are all listening, right? They all can be told for some period of time what to do. This doesn’t have to be manual is I guess my intention, right?

Ev: Oh, yeah. Absolutely. Actually, the example that I was describing with deployment, truth be told, actually, humans normally are not involved in that. So what you see in production is that there is going to be some kind of event. So like you have your pull request and get merged, then you’ve got some testing done. So now you have this kind of deployment that needs to happen. But it’s the same logic. The privileges to do deployment, they need to be issued to your Jenkins only when there is something to deploy. When there is no deployment that’s pending, your Jenkins should not have privileges or credentials to touch anything. Because if it does, then your Jenkins becomes the point of attack. So back when I was at the Rackspace Cloud, at the time, we’re actually the second biggest cloud provider. So we saw that CI/CD pipelines and credential vaults, any kind of secret storage, instantly becomes the point of attack. So this is why you have to get rid of credentials, get rid of privileges, and issue those things only on demand when there’s something to do.

Closing thoughts

Chris: That makes sense. I think that gets to my last, and I know we’re up. I’m noticing the time. Thanks for everybody sticking around. I think we’ll move over to some of the questions that we have here, but I know we don’t want to run the full hour because people have things they’ve got to do. But I see there’s a couple I can tell there’s a few real practitioners on the line. I’m sure everybody is, but some of them are jumping in because I like when there’s like a burning question. I always feel like if I have to be in stand-up tomorrow, like I need the answer now. So I like these things coming in. Please keep them. We want to have these talks. But some of the things that I think get to the practicality, which is the last piece I want to talk about, maybe that’s the thing I’ll set up for everybody — is we can talk about what to do, where to go next, right? It doesn’t have to be the biggest intimidating thing in all the world if we sort of chunk it out a little bit. But really quickly, I guess we see a lot of questions about authentication, about authorization. We see about — does a human need to approve? Like, “Okay, this is the task at hand. That’s the set of privileges that’s going to be made. Can I get a human in there and say, this is the right thing to do or the wrong thing to do?” I mean, I know that the easy answer is, sure. Depending on what the task is, that’s absolutely the right thing. But anything you want to add there, as I know I’m broadly talking about three or four different questions coming in about authorization, about task-based systems, about different permissions, and whether a human needs to be involved. But any synopsis there?

Ev: So first of all, I don’t want this webinar to be just like a Teleport commercial. I see there are very specific Teleport questions there. We could probably take them offline and answer later.

Chris: Fair enough.

Ev: But generally, I do want to go back to this topic. Not topic. The point I made earlier is that it’s absolutely critical. Absolutely critical in the age of AI for all identities to be treated the same. So there needs to be this full kind of orthogonal design. What I mean by that is that you might have an agent requesting access and human approving it. Or you could have a human requesting access and agent approving it. Or you could have an agent requesting access and another agent approving it. So all of these, they need to be possible because you need that flexibility because there are many different use cases where all of these capabilities will become useful. For example, if you make humans approve actions manually all the time, what you’re going to do, you’re going to develop an approval fatigue on your team. And they will just start hitting approve without paying any attention. Well, congratulations. Congratulations. Now you created a security theater where the approvals actually don’t mean anything, which means that you need to automate most mundane access requests, which basically means, yeah, use automation for that. Have a very simple agent approve access requests for non-privileged tasks. But then every organization has just a handful of crown jewels. The information, like it’s going to be game over. If that information is leaked, you’re going to be out of business. So for this kind of crown jewels, you need to employ completely different access protocols where you could have — like this is in finance, they call it a 4i policy, where when one identity is performing a privileged operation, you might have another one watching or two others watching. They could be selected based on the org chart or randomly. But the point is that even if one of them accidentally disconnects, maybe loses internet access, the operation is aborted right there. So the key there is that there is not a single — you need to make sure that there are some highly privileged operations that a single identity can never do. It would require multiple of them to be present in the same session. Again, these are just kind of anecdotes and stories from the field, but what they illustrate is the need for, A, treating all identities exactly the same way, and B, flexibility. You need to be able to dial in whatever the workflow you need for your particular use case.

Chris: Makes sense. Yeah, the meaningful use cases I saw come in, there’s different ways to think about it. But yeah, those crown jewels, not having automation or the fatigue of just like, “That’s my job.” I’ve been in help desks where it feels like that’s the case even. But this is great. And I hear you loud and clear on we’ll hit some of these questions afterwards based on time, if nothing else. One thing I do want to just reiterate is, yes, the recording will be released after, but we’re not done yet. Let’s think about just wrapping this up with some practical advice. What’s a first step? Where can people who are recognizing they do have that situation where they have a zillion roles, where they want to lean into agentic use cases, they want to figure out the better way to do things, but letting them be non-deterministic without just opening up all those access paths and risks, from each of you, sort of a practical ending for shining a little light?

Recommended next steps

Craig: I would say start by taking inventory, taking stock of just what you have in terms of identity and access and roles. Just make sure that — make sure that you know about the existence of those super admin accounts and open doors and over-privileged accounts from executives who have left the company maybe years ago. Just make sure that you don’t have any of that baggage. Make sure you’re not already carrying all that baggage. It’s a small first step, but I think it’s important — what we’ve been talking about and some of the things I’ve been talking about probably sound to some people like a massive sea change. And there is a pretty deep change in philosophy or change in thinking that has to go along with this. You’re not going to be able to sell that massive change to your organization. You need to start with smaller steps. So just first taking stock of what you have now and how big the problem might be, that’s where I would start.

Chris: Yeah, I agree with you.

Ev: Yeah. I see there are some questions about kind of reading more about it. So Google published a bunch of their Zero Trust papers back in kind of mid-2000s. They talk about this a lot. And another resource that I like recommending to folks because it’s a thought-provoking — is take a look at Apple Private Compute, Apple PCC. It’s a public documentation that they put out there. This is how Apple secures AI in their data centers. I see that there’s a Gene there that says, “Remove all developer change access then.” That’s exactly what Apple recommends. Right there on the front page that says, “No runtime access to production for anyone.” Absolutely, yes. All of this makes sense.

Chris: Gene has been like one step half ahead of our predictions as we’re talking the whole time. That’s one of those like, “All right. Nice.” Well, I’m looking at time. I’m seeing where we’re at. I like just starting. It’s near and dear to my heart as an old IT person, right? It’s like you have to know the lay of the land before you actually start doing anything. It can be intimidating, I know. But there’s always a place once you see where that is, Craig, you mentioned, right? What are the most privileged roles that are still hanging out there? Who are the people that created those roles that don’t work at a company anymore or have your executives actually used that or your architects actually used a thing? I know we can start in different places. And I know we’re here to help with those more detailed questions. But at this point, I think I just want to let people continue adding questions if you have them. But we’re going to wrap this up right now. We will address those questions directly with you. We’ll be emailing. That’s why we’ve got Camden. We’ve got me. We’re looking at all this. We want to make sure that everybody has their questions answered. We will be providing, as I said, this recording within the next 24 hours. And I want to thank everybody. Craig, Ev, Cam, thank you so much for all of this. I think the big takeaway is that agentic AI isn’t just another non-human identity, right? And that non-determinism is actually what we’re looking for, not just a big risk, not the terrifying part, but actually the part we’re trying to encourage, yeah?

Craig: Trying to encourage, but it can be terrifying. Yeah. But yes, trying to encourage it, yes.

Chris: Two things can be true. Yeah, fair enough. Well, thank you both for your time. I really appreciate it. And thank you all for your participation.

Craig: All right.

Chris: See ya.