The New PAM: It's Not Your Admin Anymore

Welcome to our KuppingerCole Analysts webinar, The New PAM, Privileged Access Management. It's not, I would say in practice, just your admin anymore. The speakers today are Morey J.

Haber, who is Chief Security Advisor at BeyondTrust, and me, Martin Kuppinger. I am Founder and Distinguished Analyst at KuppingerCole Analysts, and thank you to BeyondTrust for supporting this webinar. Before we start, a quick housekeeping. We are controlling audio. We will run two polls during the webinar. There's a Q&A session by the end, but you can ask questions at any time.

At the right-hand side of your screen, there's a chat bubble, so the very right-hand side, and below that, there is a question mark, and that question mark leads you to the Q&A section where you can enter your questions. It's a little bit hidden, so if it could say Q&A, it would be probably a bit more obvious, so you could think it's the help area, but it's Q&A, the question mark. And then there's the recording we are doing, and we will share the slide deck, which is a joint slide deck today, soon after the webinar.

This webinar will be more a fireside chat webinar, and so we will do a lot of conversations. We have a couple of background slides to do, as I've set up a few polls, and this is already the first poll, which you find right below the question mark, and so we are curious whether you feel that you know every privileged identity in your environment or not, and where you feel you're maybe better and worse.

The poll will stay open for a bit, so you can take your time to respond to that, even though I believe the response in disguise is relatively simple, but let's see what the result is, and if time allows, we'll pick the poll results later in the Q&A.

As I've said, it's a fireside chat, so it's Mori and me, and we will discuss a couple of things, starting with the different types of privileged identities we should look at, and then going into blind spots and other aspects, and yeah, as I said, basically sharing our perspectives here, and the first section we'd like to look at is beyond the admin, and that is something which I dare to say is not entirely new, so we had this technical constant scope of PAM for long, but they are very close to the admin, but I remember doing concepts where we looked at business-privileged users even more than a decade ago, so I would say it's not fundamentally new, but it has fundamentally changed, and I think this is a bit our starting point of all of them, and maybe Mori, to you, so you're in the privileged access management space also for a very long time.

When did you have the impression we sort of passed a certain tipping point from, okay, it's basically what we did for long, to, oh, we need to rethink how we do PAM?

Well, that concept has been around for over a decade, and when we think about it, PAM originally just started with administrators and then root for non-Windows devices, but when we started worrying about power users and services and backup processes, we kind of came to the realization that there were privileged users, the second box there, that needed some form of privileged access management because those accounts could ultimately be abused as well, and then as we started automating more workloads, again, the service accounts, hard-coded credentials and files, we started going into the workload identities, and these concepts have been around for well over a decade, and businesses have solved for them, but the box on the right mark, and that's the one that's been… I would argue even several decades and even before root, I remember PAM solutions on a VMS, so DAC systems, so it's not entirely new, yes, but I'm with you.

This was around for long, and back to you, yes, it changed. It did, and I think when I say a decade, I think the industry started embracing it within the last decade, 15 years.

The concepts have been around way, even mainframe, but the box on the right is the new one, and that's why we wanted to do this presentation because the new PAM is not just your admin anymore, it's anybody using AI agents, and we've seen a wide variety of problems in guardrails and airlines now blocking agent technology and banks blocking them, so what's really going on within the business that's changing this, and that acceleration is faster than anything we've adopted on the left-hand side over the last decade plus.

I would say the entire half on the right is what has changed, so not that long ago, some three, four years maybe, this notion of, I think this term already disappeared again, team cloud infrastructure entitlement management, where we started looking at service accounts having massive access to resources on cloud services, and these service accounts being built or coming from, stemming from applications, being created as part of DevOps processes, being out of control of the standard identity management process. I think this is where the change really started.

Up to that, until now, still it was that this was a bit, okay, we started looking at workload identities or some may call them non-unit identities. I'm not a big believer in the term non-unit identities because except the business privilege using the administrators, but some of the accounts used by the administrators, like technical service accounts, et cetera, again, are already not human, and the entire right half of this is non-unit, and by the way, your cat also has a non-unit identity or your dog.

So I think the difference between workload identities and AI resources is much better also because, and I think this is what the slide also says, they are different. They are very different because we bring in the autonomy right now with the AI. I feel this is where we, in a sense, are closing a circle. So we had the admins always with a bit of fear that the admin may go rogue. Autonomously. And then we have right now the AI agents where we probably not only have the fear but the assumption that they will go rogue. Yeah.

That brings up an interesting point because in that five, 10 years' time span we're speaking about, the word entitlement didn't really exist before then, but in the cloud is where it was introduced. You are entitled to start a virtual machine, and you have the rights, permissions, and privileges to go do so. And now we're taking the concept of an entitlement much further because it's the high-level concept of what someone can do, but the underlying technology to actually get there can be much more complex in terms of rights, privileges, and permissions.

And it started with workloads in the cloud, what we call KIEM today, C-I-E-M, but agents now are expanding that even further. You and I had a conversation a few weeks ago while we were in Germany on non-human identities and that definition, and we actually went back and forth on that. If you have a few moments, I'd love to expand on that because it's a great debate. We don't necessarily agree on it, but we don't agree on that definition.

You know, I think the problem is that we never had good definitions of everything in identity. I remember years ago we had discussions about personas versus identities versus accounts. When we look at some of the things in the workload identity space, it might not even have an identity. It might be just a secret. And so I think it are a bit blurry terms. Where I struggle with the term non-human identity is that it's mixing up workload identities and AI agents. And I think there's a reason for having this split on this slide because they are different. Their risk is different.

Their behavior is different. The controls we need to apply are different, and basically also the level of autonomy is very different. And that is the reason why I struggle with this NHI term. I also didn't like the machine identity term for workload identities.

For me, a machine tends to move and make a bit noise and exhaust and so on. But I think at the end of the day, we never were super precise in the terminology. What I believe is important is at the end of the term, by the understanding there are different needs to get control or gain control about the different types of identities. And AI agents are of massive complexity.

Also, there again, we need to differentiate. So there are the managed sort of single-purpose agents on the one hand versus what someone triggers where something builds new agents, et cetera, where we have a mesh of agents interacting out of control in the organization. I always say I think that when we look at whatever statistics, there's one simple number we can bring up, and that is 100% for the share of organizations that have shadow AI. So we always have unmanaged agents. We have AI that is not fully under control.

Well, that's an interesting piece because even though we will bounce back and forth on the definition and someone posted a formal definition in the group, we have to consider all the possibilities of non-human. We could talk about animals. We could talk about agents. We could talk about machines. It's that bucket that's all the things that are non-human, non-corporeal. But what makes this even interesting, and I think a better focus of our discussion, is that the management techniques for all of these different scenarios are different, and that's where the new PAM really starts.

And I think that's exactly the point. And on the other hand, there are things that are in common in a sense, which is it all starts with discovery. So in an ideal world, it would start with a proper process that ensures that every identity is managed from the very beginning. We do that quite well for employees as humans and for maybe some other types of humans. We are not very good when it comes to technically and functional accounts. So managing ownership of all of these accounts already is where most organizations struggle.

For business and privileged users, we usually lack clarity of where do we start with perceiving someone as business privileged. For workload identities, we heavily lean on discovery and trying to find it out after the fact. For AI agents, it depends a bit. So we have some elements of managed, but we also have this shadow AI and a lot of not properly managed. But at the end, it still starts with discovery because governance and management require that we know what is out there. Only when we know that, we can apply proper governance and management.

And if they're ephemeral agents or something that's built and destroyed fast, standard IGA practices all the way extended back to the human element just don't work. That discovery or that attestation that that agent was created to go do something and it was destroyed afterwards brings us into a whole different set of problems, discovery problems. The standard IGA process is built for workforce. So for a pretty small subset at the end of the day, okay, some organizations have a couple of hundred thousand, but at the end, it's still relatively small.

They anyway don't work because they're not built for speed, for scale, for automation. So this is a different play here. It's about automation. It's about way higher speed and very higher scale. I think one concept I feel in this, what you said, ephemeral identities, the ones that pop up and disappear again. I think we, again, a matter of precision in terminology and in the concepts we use. In several cases, we probably have an entity that is not ephemeral and instances that are ephemeral. And so that also means we need to think in relationships, in multi-tiered concepts, also for ownership.

So who is the owner of a workload identity? Is it the developer?

And same, actually, for the agents. Or is it the owner of the technical owner, the system owner of the application? Is it the business owner of the application? Probably all of these ownerships are needed. And there are relationships, again, between them. I think we need to understand how these things are linked together and be sufficiently precise without going over the top. So I had this conversation also with some others, like Felix Gatkins from your team back in him, when he was at Gartner.

And we had this conversation about we also must be clear about we can't come up with a finite list of all identity types. First, there's permanent change. Second is where do we then say this is that identity type and this is different, so we create a new class of it. I think the four groups here for the purpose of PAM are very good. I think they're a really good starting point because they are all different from each other and require a different approach, like you said.

Well, it brings up the interesting point and the nuances that we'll probably get into in the next couple of slides, that identity should not be reused, especially if they're dynamic or ephemeral. That would just create a whole hot mess of just like having two John Does in the company and one leaves and comes back and you just recreate as a count the same entitlements. There's a lot of best practices I don't think we'll get into, but nuances that really need to be addressed when you consider all of those different buckets of ephemeral or not.

And they translate into blind spots that threat actors are really trying to exploit today, and this brings us to the next part of the conversation as to where the new PAM is going to help or has provided good relief or mitigation strategies to these new points. Martin, you want to kick us off?

Yeah, sure. I think there is quite a number of blind spots. I'd like to basically start with number five, because I already brought it up. The IDP and PAM integration also leans into IGA and PAM integration. So we don't have proper integration with the key elements of our infrastructure. So between IGA and PAM, I mentioned the lack of ownership for technical and functional accounts. We frequently are not really good in ensuring that if someone changes the job of a person, that all the technical and functional accounts that a person owned are treated properly if it's required.

Ownership changes, and the same happens with the IDP and PAM integration. So we need to share context. We need to share signals. I'm a big believer in shared signals. We have this shared signal framework out now. We have the ability to share information in a standardized manner between various entities, and that means also between all the information that come from the context of authentication from an IDP to PAM. And I think, yes, it's a blind spot, but it's unfortunately not a new one. I think number one is one of these that has caused me a lot of concern.

I've been with BeyondTrust for 22 years. I started as an SE. I've been vice president of product. I was the CTO and CISO for almost eight years. And when we talk about nonhumans and mainly AI, we'll build an agent to do something, and then we start connecting it, and we add other agents, and we now have eugenics systems and everything bound together. That sprawl that we're using in terms of connections, connections to MCP servers or even its authentication, however that's occurring, is something I don't think we're documenting well or even controlling well.

We're almost flying the airplane and building it at the same time because we know we want to get to a destination, and we may have to make a stop here or there or have mid-air refueling, as crazy as it sounds, but we're not designing and architecting our AI solutions, for the most part, in many organizations. We're giving it to people and saying, show me what you can do.

And the last time I saw this happen, as crazy as it sounds, was the beginning of the PC era, when we were starting to drop gateway and Dell boxes and clones on people's desktops with Windows 3.1.1 for networks and going, see what you can do with this. Can this really help the business? Can you really move forward?

And AI has that type of feel, and I don't mean to date myself, but in many cases, we're just throwing it out there and going, use it, and you're going to be measured on you using it, and the token count and everything else, and now we have this massive sprawl out there that we're creating a huge blind spot, and it's just a matter of time before it becomes that huge liability or risk that we all do believe it's coming. Yeah, and it's not that we were really good on the basic stuff like service accounts.

So when you look at the average active directory, there tend to be tons of service accounts from software that is not in use anymore. So there it starts. We haven't solved probably the basic things, and right now we have DevOps where things are created where, honestly, the identity management team is not yet in a position. That means also from an organizational perspective, from an understanding, and from what they do to deliver a service.

So I always say if a developer sets up a HashiCorp vault, then usually not because the developer loves to set up HashiCorp vaults, but because there's no service from the identity team where it's just there or where it can be just ordered and is there basically in a minute or an hour or something like that. And so we need to get better at this, and I think the number is a huge challenge. I think also the way to review it is a huge challenge. So how do we do the review when we have? So recertification for humans in IHA is something which doesn't work well.

But no, so we're basically, I think we're in agreement here that with all the additions of workloads and AI in terms of, okay, non-human machine, we'll get over the definition for a moment. If you have incomplete systems and now you're building on top of it, you're going to have even more of a mess. And that's true for governance, cloud sprawl, connecting it to SharePoint, which may be dirty in the first place. We're compounding the problem essentially. But I think that the first thing is we need the discovery.

And the second thing is we need them to understand how can we better deliver better services that help us bringing things under control from the very beginning. And I think this, as I said, requires a fundamental mind shift in identity. We need to really rethink the way we do identity management. And so that would be the starting point because only then we will be able to reduce the uncoordinated sprawl. There always will be more. So the scales thing that's here, it scales, it grows. That is all here. And then we'll let go away.

But what we can fix is the share, the ratio of what is happening out in the wild to what we do in a more controlled manner. And I think this is where we need to work on. It's not happening by saying you are not allowed to do that or that or that. It's only by delivering good service. I agree. And I like thinking of it in terms of a VIP strategy. You're the most important person, a VIP. It starts with the visibility we both agree on. It's going to take intelligence to understand what we see and formulate a strategy, and then ultimately protection.

And as you've just indicated, block listing is not necessarily the only and best way to go. We've seen how messy block listing can be when holding down an environment. So protection has got to be behavioral. It's got to be allow listing. It's got to be some form of better methodology that privilege access management is using to handle all these new style of potential admins or entitlements and privileges that most organizations see. Okay. So then we have human identity failures. That's how it is. I think nothing new. Cloud and shadow. We can talk about that one for the rest of the call.

We all know that there's rogue systems out there. We know it. We know it, yes. And then there's the cloud and shadow access and the shadow AI, I would even say. So this is, I think, one of the big challenges, which we also see. So I think all of that is not new, not surprising. I think it all goes into the same challenge here. I think what I really like to focus a bit more is no owner, no review, and no alert when it's abused. Ownership is something which still, I believe, is heavily underestimated its relevance for everything we do in security.

Ownership leans on responsibility and on accountability. So we need proper ownership, and we obviously need automation for ownership assignments. And then we need to think about how can we do reviews, because no one wants to go through a list of thousands of technical elements. So I think it's much more about outliers, about behavior, et cetera. By the way, while you right now respond, I quickly hang off the painting behind me, because it looks like I have a bit of a weird hello all the time from the painting behind me. So you continue with your perspectives. I think you hit on something.

Well, there's an identity crisis in itself. I think you hit on something that's interesting, and you used the word accountability. If you look at the core values for most companies, they'll have their five, six, four statements. And some form of ownership accountability is going to be in one of their statements. And we may take it as I'm accountable for my actions, for my quota, for my performance. We also have to take that into our electronic age and say, yes, we've instantiated all of this technology. Who's accountable ultimately for the pieces and parts in terms of its runtime? Yeah.

And, you know, I spent quite a couple of time in projects working with auditors, and there you learn accountability versus responsibility and ownership and stuff like that. It's important. And I think we can do it. For the review, I personally believe we need to focus on the outliers, on the anomalies. And that also is a bit of what I tend to say. We need to, again, terminology. We need to probably distinguish between human in the loop and human on the loop. And a kill switch in both scenarios.

Oh, no, come on. No kill switch. Okay. I'm going to disagree on that one. Let me start with why human inverse is on the loop. Okay. Looking at the outliers, it's the human oversight element. While human in the loop is basically asking the human for everything and all the details, which doesn't work at scale and speed. So human on the loop, I think, is the better concept. Kill switch, yes, is the last resort. But it's the last resort. Before the kill switch is blocked, there's containment and a lot of other things, isolation, et cetera.

So envision your privileged user does something in the operation technology environment for your production line. And you just have this on-off kill switch thing. It will not work. You don't want to be the one who stopped the production line and caused a million-dollar loss. And there would have been a much smarter solution. I disagree. I think that any large agentic system that has the power to make decisions needs a formal kill switch. We've seen chatbots that are integrated deeply into sales and organizations that have sold cars for a dollar.

I would want, as a part of that chatbot's design and implementation, a kill switch so that if that happens, I can disconnect it from my system. Yes, which you can do basically at a console level anyway. Just kill the process. A formal part. I'm going to go build and negotiate the rate for a car. I wish you that we need the kill switch as a last resort, but we need stages ahead of that.

Okay, I could sign up for that. It should be the last resort, but if you're not engineering it in somewhere or at least know how to do it, like kill a process, that pain point, if it happens, could be a very long and very painful point.

Okay, so let's look a little further. Where are all these attackers going for? What are the attack vectors? I think whether it's 75% or 70% or 80%, I don't care, but identity is part of attacks. And I even believe it's getting worse because with the sophistication of attacks based on AI, attackers, especially when it's about targeted attacks, will become more sophisticated using smaller vulnerabilities, combining them in a smart manner to gain privilege, to add further privileges, to elevate, et cetera, et cetera. And so probably it's even more over time than less.

I think that these categories are really basic, and there are some here that can almost have expanded definitions. Let's just take DeVault's credentials because it's the top one. In California, legally, you cannot buy an IoT device or OT device that has the same password as any others. They all have to be unique. That was a law, and the vendors for many years now have had new ways of doing that, whether that is a QR code, whether there's a sticker printed, et cetera.

But that default credential really doesn't matter anymore because what ends up happening is you'll configure your cameras, your OT, whatever it may be, and every new device that you bring online, you put the same password. So it's almost like you've created a new set of defaults, and you're not changing it, rotating it, et cetera, and you have all of this operational technology in your environment that same password, never rotated, not properly managed, goes back to our visibility problem. And we've seen bots. We've seen the Myriad botnet, God, 10-plus years ago with this exact example.

And, you know, just recently, Frasers. Hey, I'm rotating the password. But you know what? You're rotating it to something quite guessable. That's a default credential no matter any way you look at it. And I think we have the same in OT and IoT with preset certificates where there's no proper rotation scheme and stuff like that. So I think it's quite common. And I think the second thing, by the way, is also super common, embedded secrets, you know.

Some people start saying, hey, we have right now this problem of whatever API keys being shared on Slack channels and stuff like that, or somewhere else, embedded somewhere else. You know, you're in PAM for 22 years. I'm also an identity for a very long time. And even at the very beginning, we talked about passwords in script and command files. Nothing different here. I think the point is I think there are two elements in that. The one is human behavior, which can be lack of knowledge, which can be sloppiness or whatever leads to it.

And the second, and I think this is the more important thing again, is no proper services. So as long as it's complicated to solve a challenge in a different manner and it's not known, then it's difficult. If it's as easy to whatever call for a credential, then it is to just write the password into the batch file. Then it's much easier to convince people to do it securely. But obviously, if it's super complex to solve it, there's no simple way.

So if you don't deliver the service for that, so access it at runtime, a simple call that goes out of the script or so, then we will stick to these scenarios. So I think to quite some extent that we don't deliver good enough services to consume the information instead of hard-coded somewhere.

Well, you know, it's an interesting point. And maybe this history is needed. Twenty-five plus years ago, we would do vulnerability management scans. And you had two types. You had null session and you had credentials. And you'd actually enter a username and password, and it would log into every system to do a detailed inspection. That's awful by today's standard because that's a shared credential that would allow lateral movement that has admin access. And then we evolved that.

And this is how I really started getting involved with PAM because then we started vaulting that credential for groups and individual systems. So when I would go to a target, I would find out the credential I needed to do that management. And we saw that evolution as well. Now we have all sorts of additional types of problems with what other tools outside of a vulnerability management solution would have to touch every system. But you've got everything from tools that do inventory to even certificate rotation.

Look, you could be using one of the largest certificate vendors out there to get to your 47-day rotation. But do you actually want to put a password in that system and have it store it where it's actually going to go rotate that certificate as well? Of course not. You want that privilege or those secrets to log in and rotate their certificate and store it somewhere else. A PAM solution.

And this kind of expands those privileged attack vectors because if you give that system too much access and the ability to do multiple functions simultaneously, you've got all sorts of forms of privilege escalation that you may not even be aware of. So you need that separation. You need to make sure that credential cannot be used for lateral movement. You need to make sure that the system that's managing your keys can securely say, it's time for me to get a key. How do I log in? Go rotate the key. I'm done with the task.

And then destroy or rotate that secret so that it doesn't become the attack path. And those types of scenarios on common privilege attack vectors are the things that are going to protect us in the future, not what we did 25 years ago where we put one username and password and it can touch everything. And we've seen multiple supply chain breaches over the years that unfortunately fell victim to just that old school approach.

Yeah, and it will continue to happen. Unfortunately, yes. Not everyone codes well, not everyone designs well, and definitely not everyone architects well. That's true.

Yes, and privilege escalation still, you know, I've been writing before my days at Coupang Code, it's quite a while ago. I was writing a regular newsletter on Windows servers and I always looked at the new patches of Microsoft. A lot of them had to do with privilege escalation. And so it's a problem we had 25 years ago. It's a problem we still have.

And as I said, I fear that this will become worse because AI may help attackers to figure out different routes through the organization of their victim by using, let's say, smaller and many of these escalations, trying out various ones, being more flexible, so to speak, in the path they take. So this may get back to us quite a bit.

Obviously, there's always this idea of zero standing privileges. There's this idea of dynamic authorization. So there are concepts that are around for a while, especially dynamic authorization. I always say, you know, IBM released in 1976, five decades ago, they released Reg F. So there's no excuse not to do it. We know it for five decades how to do it. And I think this is something we need to be aware of, especially in the age of AI. Everything we failed to do probably bites back right now. In the 1990s, we had databases with blank passwords, if you remember. Right?

SA without naming the vendor. We didn't learn. We're still trying to help educate people and learn somehow.

Yeah, and I think also the other, I think we can probably skip past that. We can get pretty deep into that.

Yeah, let's head up to the next slide. I think it's still, and we have to solve accounts. So even with humans, we are not really good in getting rid of them. I talked about service accounts in Active Directory that are around from whatever, a really old exchange server or so, 2003 or whatever, and still exist and stuff like that. And it's getting worse. Now at scale, at speed. I think so. And the statistic comes from a BeyondTrust survey that it takes typically longer for clients for an environment to remove an account, whether they've been fired or they're on leave or anything else.

And then that gap leads to all sorts of issues. And we've seen that before. We've seen the disgruntled employee go in and destroy databases and do things. But there's a nuance here that I think we forget. Let's just say it takes that 24 hours, right? You've got all the places that the person could be, and you have to have that visibility and to know every individual account, that ownership of them. But what about the supply chain? What about all of the locations that they had access to, to download a license, to get software, to place an order?

I use a story, and some of you may have heard it, in my former life, it took over 10 years for that account to be removed from the supply chain. Now, that's years ago.

I mean, that's years and years ago. But it's still possible today, and it's still pretty relevant. Whether that is a VAR, whether that is an ability to access a credit card, think of all of the scope that that person has. Are you really doing everything in the 24 hours or just the things you own? And that's kind of scary. You just need to look at consumer identity management. For consumer identity management, we are pretty good at onboarding consumers. But consumers are rarely off-board. So back to your supply chain case, which is the B2B variant of that, in a sense, yes, that happens.

And there might be this Amazon account used in business. And then we are back to consumer stuff. So that will not disappear quickly. Let's rephrase it. If you can order office supplies and you're using Amazon on behalf of the company, who's going in there and managing it? Modern PAM can provide gateways to that new PAM so that you can centralize it. But if you're still doing it distributed, that's exactly the scenario you're referring to. So before I comment to the audience, there's the question mark, right-hand side of the screen, the option for you to post questions.

At the bottom there is post question. So if you have any questions for Mori and me, so just ask us anything. Just enter your questions, and we will try to pick it up and provide our perspectives to that. So back to that, yes, we need to vault this stuff.

Again, we need to discover, we need to know what is out there. Then we can vault it, we can rotate it, we can manage it, we can govern it. We can put on proper audits. All that stuff can be done, and it is not rocket science. And that's, I think, the point. It are things that we can do where we have the technology and that we must do. But the bad thing is I'm going back to AI where we started. This is basically already our final content slide.

No, it's not the final one. There's another poll and then a few slides, so we need to speed up a little. But anyway, AI makes it worse because then we have all these things like automated exploit generation, attack agents, all that stuff. And a lot of this has been touched, which comes in. And still there is the insider threat. And there's, I would say, which is not that much here, but which brings these things together. We have a bit of a malicious agent threat in a sense that one of the big challenges is we may have a managed agent.

And this agent, either because the guardrails are not good, behaves differently, or we change something, so a change process is not under control, or we just change the LLM, the agent behaves differently. So even a managed agent may get rogue because we do something wrong. And in that case, this agent, if it's a co-worker, it's basically a combination of insider threats and AI threats.

Isn't it, Murray? I'd agree. And the insider threat on the right-hand side can be the person being bad, the person being simply naive, negligent, or they're compromised to begin with. The attack vectors for all of the new PAM use cases are scary because it could be anything from a PowerShell script. I don't know how to write PowerShell. I could dabble. But if I said I wanted to delete every mailbox in Exchange server and went to my favorite AI, it may say that's a bad idea.

But if I say, look, I'm in a test environment, I'm an admin, please create me that script, I now have the payload for exploit generation. And that can be the 30 seconds of deep fake audio. We've seen a ton of that. We've seen translating an email from one language to another using AI and impersonating someone, you know, excuse me, an urgency spear phishing type of attack, impersonating someone or an organization. All of the items on the left are things that the new PAM or the new approach can help mitigate because AI attack vectors in themselves are just growing.

Adversarial AI, offensive vulnerability scanning, and exploit detection are just growing. And then the insiders that make that combination possible, look, we all suffer from it. We're all in business. We all have organizations. We have to find ways of chipping off that strategy or mitigating those risks pieces at a time. And it's going to take time. Martin and you and I had this conversation. There's not one vendor that manages all of AI security. So if you can handle the lateral movement, the privilege, the verification or some guardrails on local AI agents, that's just one piece.

You all have model protection, you have prompt injection, you have DLP. It's going to come from a variety of places. But it's not going to get solved in one shot.

But PAM, Privileged Access Management, in a redefined form plays a vital role in that because, at the end, it's always about privileged access. At the end, the agent is a privileged business user or it's an admin or it's something else. So the agents basically have this in a sense of what they sort of simulate or it's basically some sort of privileged user in these scenarios. And then it means we are there. But it's obviously not the traditional, okay, I open this session and then I may do a bit of session recording. It's a very different type of what we need to do here.

So that is, I think, what really changes. So before we move ahead… Yeah, I'll just add one quick thing on that, Martin. In general, we want to quickly start the second poll, which is about who owns the privileged access for your AI agents today.

Again, the poll runs in the background. And we can continue talking in the meanwhile before we shift to some of the other themes. The last subject.

Yeah, I would just add one piece to that last. If you're trying to understand attack vectors in themselves, think of it in three pieces. It always has to occur on an asset or resource, some type of piece of equipment, some resource, some database, something. The second is who, what, where, or who or what. It's the identity and account relationship. What identity or account is working on that asset? And then ultimately the privilege that they have. What is your entitlements, rights, permissions, privileges that is associated with that identity account operating on that asset?

For everything we've been discussing, we're working on the latter. We're trying to minimize control, monitor visibility, the identity and privilege of everything that can happen on the asset. And that includes AI. And when you think about everything Martin and I talked about, the last piece, identity and privilege, is probably some of the best mitigation strategy out there to fix these problems. Yeah. So how to fix it? I think this is the final piece. We have two questions here, by the way. I want to quickly then come on the later on the poll results. So what are the practical steps?

I think it fortunately starts with the one I always pointed on, which is discovery. What you don't know, you can't handle well. So I would say my perspective is there's not much surprising in the list, is there?

No, I don't think it is. And it's the visibility that is discovered. It's the crawl, walk, run strategy, whatever model you want to do. If you don't know about it, you can't see it. You can't manage it. You can't do anything about it. You remain ignorant to what the potential problem is. Exactly. And I think we just need to do proper work. And at the end, a lot of the things we did, but right now it's scale and speed. Apply here as well. Understand what it is. Classify it as well. Risk classes, risk perception. Don't treat everything the same. Reduce privileges. Move to just-in-time access.

Zero standing privileges. All these things. And go back to the things you should have done 10, 15, or 20 years in the past. Close the gaps. Implement proper governance. And focus on where are anomalies, because you will not be able to look at everything. And I do think that in many cases, governance and detect could be zero. Have the policies and procedures that the business is willing to accept in terms of risk while you're doing the discovery.

Because if you try to build the model afterwards based on what already exists, it can get a little tricky as to what you're going to rip out or what you're going to accept. So number five is one that's a little mushy. You may want to make sure that your AI policies, your identity policies, or any regulatory compliance that you may have is already documented and being adhered to for all four steps. Yeah. And in the summary, it is PAM is important. We need to do it. And so that is where we really need to work on. So I think we can shift to the Q&A session.

We're getting a couple of questions in there. Maybe to the audience, when you go to this question mark, you also can upload questions. So I think a good question here is the first one, how to practically do the inventory in one discovery, any tools you can recommend. So practically, so basically it means how do you do discovery? Is there a single tool? Not exactly sure. I believe we have more than one.

Maury, what's your perspective? I think we do have more than one, but I think there are some that are better than others. There's a category called IDIP, Identity Visibility Intelligence Protection. These are tools that are designed to stand up rapidly and fill the gaps in IAM. So in other words, it talks to your SSO. It talks to your IDP. It talks to your MFA. It talks to your PAM. And it basically can build the model of where these identities exist, including talking to all of your AI providers, whether that's Bedrock, whether that's ChatGPT, wherever it may be.

That'll give you the visibility into human, non-human, and AI using the definitions loosely that we've discussed. There will still be gaps. It's not going to find what's hard-coded in a configuration file. It may not find all of the local accounts. That's why you do need, and I agree with Martin, some specialized tools. But if you're trying to get the broad picture fast, I'd recommend an IVIP solution. Biontras does have one. And there are other vendors. But that's a great way to get started, and they generally stand up in less than a day or so.

Yeah, and I think that is one element. I think there are some tools very specialized for the workload identity world. If you go into AI actions, it becomes a bit more ugly because we also need to look at what happens in the browser, at the endpoint, et cetera, because it's even more sprawling than elsewhere. So I think it's interesting to have a quick comment. I don't think we need to display them. But when we look at the results of the polls, the one was, do you know every privileged identity in your environment, including the AI agents?

And it's interesting, 43% believe that they know most of them. 11% are very advanced and super mature because they say they know all of them. Maybe they are also only just optimistic. I don't know. 21% are for only the human admins. And 25% bluntly say, so one quarter bluntly says, no, we don't know it. Probably one of the most realistic responses to that, there might be the gap between we know it and we believe we know it, which might be two different things. What are you willing to put in writing, in other words?

Yeah, and the other poll was then around, who owns the privileged access of your AI agents today, where there's a slight, so almost half, lean to the application business owner, closely followed by the security or identity management team. 11% say we don't use AI agents. I think the correct answer might have been we don't know that we use it or that someone uses AI agents in our organization. And 5% say nobody yet. No ownership for that. Okay.

Anyway, I think it's not super surprising here. So maybe go to another question. I think this is an interesting one also. How do you recommend assigning non-human identity ownership or ownership for workload and for identities and for agentic identities? You want to start with that or you want me to start?

Well, I can start on that. So how do we do that? What would I recommend for that? So the first thing is don't try to do it in the way you handle ownership of slow-moving identities. At the end of the day, it goes back a bit to discovery and classify and then basically automate. So discover and then classify. And once you have classified it, have an automation rule to do that. That would be basically my starting point on that. I look to actually several solutions as a mental note. If I'm an idle compliant shop with a CMDB, I can get the standing privileges in a nice clean place.

I can do that with IGA as well. It's the dynamic and ephemeral ones that there's a little bit of trick there. Then it becomes the process or the workflow ownership that becomes delegated down. And there's not necessarily great tools outside of, let's say, a ticketing system that can say, if there's a problem with this automated workflow, who should the ticket be routed to?

Today, there's not a good central place for all of it, but if you think through the problem a little bit more logically, you can get yourself answers. In other words, that last example I gave, if there was an outage, who do you call? If the help desk can't decide who should the ticket be routing to, you can't determine ownership, it might be a good place to start, especially for change management.

Okay, I think we can pick one more question, then we are at the end of the time for today. And that is around the kill switches, where someone asks whether this is a chicken-and-egg situation in a sense, because there's the efficiency aspect, so we need to be able to pull this kill switch fast.

And then there's maybe how do we make it fast and we end up with something which basically is automated, which, again, needs then a translator to question or change a bit, where we then basically have something which we may need to kill as well, because the efficiency of the kill switch, or we detect it, we pull the switch, requires automation, and then we end up going in circles here. Isn't it a bit that way?

Well, I'm going to use a little bit of an analogy here. My first job at Durham University was building plastic parts, plastic injection molding. And none of the machines that were doing hot plastic injection molding had emergency switches. We actually had to mount them all over from the auger to the hopper, all over the place, so in case someone got hurt. And we then had to test it in various scenarios.

For each switch, if your hand got caught, if you got burned, and the system had to shut down, release, drop all the material, and not damage itself, that's the proper definition of a kill switch. It's not going in circles or a chicken-and-egg scenario. You may engineer one to stop something, but you're going to have to test it at some point to make sure that it can disengage from the business and any manual processes that are needed, just like it was before AI worked. So I don't think of it as circular or chicken-and-egg.

It is literally an electronic adaptation of an elevator and escalator methodology. Okay, great. So I think we're at the end of the time. We've answered your questions. If you have any further questions, just mail to me. I look forward to Maury to answer and then respond. I think that's a fair share of work, then, and delegation. So thank you very much for listening to this webinar.

Thank you, Maury, for all the engaged conversations. Thank you to BeyondTrust for supporting this webinar, and hope to have you soon back at one of our webinars. Thank you.

Martin, pleasure, as always, to speak with you. And for anybody listening, have a very happy holidays. Thank you.