AI Agents and Machine Identities Are the New Privileged Users

Welcome everyone to our KuppingerCole Analysts webinar, AI Agents and Machine Identities Are the New Privileged Users. Obviously everyone talks about AI and we understand I think that AI agents tend to be slightly over-permissioned, so we need to think about how do we get a grip on it.

This webinar is supported by BeyondTrust and the speakers today are Felix Gaehtgens, who is Lead Analyst and Vice President Product Strategy at BeyondTrust, Morey Haber, who is Chief Security Officer at BeyondTrust and who will moderate the conversation, and me, Martin Kuppinger, I am Distinguished Analyst at KuppingerCole Analysts and luckily Felix is back right in time. And so with that a little bit of housekeeping before we directly dive into the content. So we are controlling audio, nothing to do from your end.

We will run two polls, but there will be a Q&A session at the end of the webinar, but feel free to enter questions at any time. When you look at the lower right edge of the screen you'll see the area questions as well as polls, so please use questions not chat for entering the questions. And we are recording the webinar and we'll make the recording available short term. The slides as well, but the slides are this time not at the center because after the poll I look at the agenda it will be mainly a fireside chat.

So my first poll is on, it should be very simple to answer and I would be surprised not to have a 100% response on that, which is do you know all agents running in your hybrid IT environment? So regardless of where they run. Simple response options here, yes. You know all of them or not? No. So we leave the poll open for a bit so you can respond to that. If time allows we can pick this up during the Q&A, but for now I'll like to move, look at our agenda which is super lean today, which is basically a fireside chat, Mori moderating with Felix and me as the ones who deliver our insights.

And then we basically do what's next more in the Q&A part. And this is the first thing we'll start and I hand over to Mori. Thank you so much Martin. It's a pleasure to be speaking with all of you today and we wanted to do this as a fireside chat versus a standard presentation to help get opinions and educate the audience today as to really what's going on in the world of AI. Now one thing that I find quite important and actually quite staggering when talking to clients is that there's a problem with definitions. And I want to ask both of you, Martin and Felix, for your opinion.

What is the difference in definitions for agent AI and agentic AI systems? So that when we begin a little bit further in the fireside chat everyone understands what we're talking about and why there's a different differentiation between the two. Martin I'll turn it back to you to give us a start.

Okay, I hope that Felix would be the one who has to provide his perspective. This is actually not that difficult. But the issue I think is that the industry has been kind of a little bit sloppy about this until pretty recently. And here's kind of the cleanest way I can think about it. So an AI agent, singular, is a specialist.

One job, one set of tools, one outcome. So think of hiring a licensed electrician. You call them, they show up, they do the wiring, they leave. You have a bounded scope. They won't do more unless you pay them more. Hopefully they won't do less either. And they should be predictable. You know who you hired. But then agentic AI is different. Agentic AI is a general contractor. You don't hand them a task, you give them a goal. Renovate my kitchen. And they figure out the rest.

They break it down, they hire the electrician, they hire the plumber, they hire the painter, they hire the carpenter, they sequence the work. And then when the plumber rips out the wall and finds some rotten joists or something like that, the contractor re-plans on the fly what we've got to do now. Brings in a carpenter, for example, or maybe reshuffles the schedule. So you have an AI agent that executes, but the agentic AI system orchestrates. And I think I agree with you. I would have probably taken a bit of a different approach saying, I like your analogy.

So my approach would have been a bit around saying, agentic AI is really about this mesh of agents. So this network of agents that work together, that is also quite non-deterministic as a network. So the AI agent is the single instance within that. I think we can probably discuss whether this AI agent within agentic AI always acts within the boundaries or not. But it may also end up in a bit more of a philosophical discussion. But I think at the end of the day, we agree on that the one is that interaction, orchestration of agents versus the single agent within that.

Or maybe even the single agent we just use without other agents involved. That also may be the point that we just use AI and say, okay, this is the one single purpose thing and it will not deviate from that.

So yeah, I think we are pretty much in alignment here. I think we are. And I like to use the role of the analogy kind of similar to both of you, where the agent AI is the sole contributor in a workforce and the agentic AI is the team approach, the full system of all the sole contributors coming together to do their job. So I think we can agree on that concept. Let's take it to a more difficult question a little deeper now that we've got that definition done. Within agent AI, we see a wide variety of identity patterns in terms of communications, privileges, roles, access, and even actors.

What on behalf of are they running? Can you describe the differences that you see and the big differences in terms of risk surface for them? Who wants to go first? How long do we have? We go round robin here. So it's your turn. Unless you want me really to go first on this.

No, I think we probably both have a lot to say. So I think when I take this question, it's about, correct me if I'm wrong, what are the changes that come with agentic AI? The risk concerns that we have, we're going to the singular now. So if we're given a singular- I think the risk concerns at the end of the day is that we feel it's hard to get a grip on the entire thing. I think the interesting thing is why. And this I think then really goes into the core of the risk concerns.

I think the fundamental challenge we are facing is that we are right now in a non-directed, non-deterministic type of access. That is where things start. So we are used to say, if you go to British users, Felix is the admin. He uses the root account as a server one, two, three. And this is a relatively clear directed way. And it's deterministic because it's server one, two, three. When we look at the agentic AI world, it's basically that Felix says to some prompts, I want a response on this.

And then some agents do something, may work with other agents, end up at some resource servers, go for some information and give something back to Felix. And Felix has no clue about the direction and where it finally will end up. It's non-directed, non-deterministic. So we don't have this. And I think when we look at the risk, this is where the problem starts. We don't have a deterministic risk anymore where we say, okay, this is access to this server. And this is what Felix is allowed to do. And there are a lot of other elements which add to that.

But at the end of the day, going back to Felix analogy, the one thing is, this is the electrician I work with. And I know he will take four hours and I have a rough estimate what this entire thing will cost me. If you say, here's the sort of the blank check in German would be the check you give to the contractor who just does everything. And you don't know, will this cost me 10,000 or 100,000? What will he do? I think this is the same type of analogy that applies here. I think who has been working with contractors in the house probably has some good idea of that.

And at the end of the day, probably it's like this in the house. The cost of these contractors always will be higher than you hoped it will be. And the things the agents will do tend to be more than it should be. So this impacts the roles of the agent system, the privileges, the access, basically everything. But when it comes to an identity pattern, if I understand you correctly, you're saying it's a lot more dynamic than Felix being an admin as a static access. Yes.

Well, hold on. Now, I'm not necessarily going to disagree just yet. But I need to ask. So are we talking about agent AI? Or are we talking about agentic AI systems? Are we talking about the electrician? Are we talking about the general contractor here? That's why we did the difference in the beginning. So let's break it into two pieces then. An agent performing a function, how are you concerned about its identity patterns, its usage, and then the entire system? So let's take them in two pieces. Right.

Well, if it's a single agent, honestly, what most people do right now is they very likely run it with, hopefully, a subset of their own permissions and acting on their behalf, right? I think that the different identity pattern over here, hopefully, hopefully, yeah, yeah, hopefully.

I mean, in other instances, they just say, hey, you know what, you get access to all my files, all my .files, all my stored passwords, just do whatever you need to do. But that's obviously not a very safe way to do it. And if you do that, then you will, at some point in time, stop doing that pretty quickly once you've had something happen. So here's the difference, I think, in the identity pattern, first of all. Let's talk about the single agent, right? Let's say something that has access to your desktop, to your file system. Think about Cloud Code, for example, right?

Classical example, you launch Cloud Code session, you have it code on your behalf, or do sysadmin work on your behalf, or whatever. This has access to all of your files, including, potentially, all of the files that have credentials, right? Your .files that have that GitHub personal access token, and maybe your .netrc file that has clear text passwords for a lot of other things. And then maybe you have your .npmrc file that has credentials for your Docker registry, and for your artifactories, and all of these things, if you're a software developer.

Of course, you shouldn't have these things, but a lot of people do have them. And so now, Cloud Code has access to all of them as well. So that means that all of your credentials find themselves in Cloud Code very quickly. And I try getting rid of all of the credentials on my file system, but Cloud still finds one every once in a while. Cloud is very, very, very good in doing so. For example, once I had to do something that required securing a TLS connection, and Cloud said, well, I see your certificate. Do you have the key somewhere?

Oh, no, hold on. I'll just go look for it. And then I was looking for the escape key already.

Oh, found it, found it. I found the key. So I'm like, gee, this is crazy. This is really, really scary. So let's say that giving an agent access and allowing them to act as us with the operating system, not even knowing the difference between the agent or your user is obviously something going extremely wrong. So we have to do two things. We have to put some boxes around that particular agent. The first thing that, well, I don't know if it's number one or number two, you could do either at any order. But one of the things would be keep all credentials away from that agent.

The agent should not have any passwords, any credentials, any API keys, anything. But instead, when the agent wants something, you broker access for that agent. If the agent wants to access GitHub, give it a way to access GitHub on your behalf. That could be through an MCP server or it could be through a brokered connection or something like that. But don't give the credential to the agent because you're never quite sure where that's going to end up. Not that I think Cloud is malicious or anything like that, but there could be some sort of attack that then would expose your credential.

The second thing is put boxes around what that agent is allowed to do on your system. And one way to do that, for example, is with an endpoint privilege manager or endpoint control where you can filter system calls, you can filter access to certain files. You can say, hey, you can see these types of directories, but these others are completely inaccessible to you. You can't see my email. These are the two things that we have to do. I'm going to shut up now because we're going to start talking about how that applies to the agentic AI system. Then we're getting a few more layers deep. Yeah.

But even for that, isn't it that we should think beyond yours? I think for your agent, in that sense, like you said, it's relatively simple. The point is that same agent may act in various contexts. It may do something for you or for me, which means that the agent may have different constraints. There might be different intent, which is anyway pretty fuzzy because intent is not explicitly usually defined and all that other stuff.

Also, from an authorization perspective, it not always may be the same authorization that applies because there are a lot of, let's say, contextual factors to add. I think that is one of the things. That means it makes things a little bit more complex because there's this relationship between, at minimum, between the agent and the sort of call it invoking identity, be it on behalf, be it impersonation, which is very different, or just kicking it off and say, man, it does always the same. It makes a huge difference from an authorization perspective. I fully agree.

When we look at agentic AI as a chain of these agents, it becomes even more difficult because, in that case, we need to transport all that information about constraint context, behavior, typical behavior, intent, et cetera, across the entire chain of agents. We end up, I think, in all scenarios, a bit with the challenge of what we can handle potentially quite well are known agents with known constraints, contexts that go to a specific resource server or to some specific resource servers.

I think the reality we are facing is that most resource servers have no clue about which agent will knock on their door in the next minute and ask for what and why. I think that makes it quite a bit more complex. That brings up a really interesting question. I think the assumption that most people make is you own an agent, I run an agent, there's an ownership, but this is a one-to-many and one-to-unknown caller action, especially as we get into the agentic world. That unknown may not be a human. It may be another AI or it could be another static traditional machine.

As Felix would call machine identity, whatever. I'm a little confused now because are we talking about agent AI, which is like a single agent and you log on to it and your agent works for you, Martin, and Maury logs on to it and then the agent works for Maury? Or are you talking about an agentic AI system that just gets a request potentially?

Felix, can we talk, a radical question, can we talk about agent AI at all? Or is agent AI just a subset, sort of the easiest to solve use case of agentic AI? So isn't agent AI at the end of the day, just the exception of the broader use case that we need to solve? I think that's the question. Let me frame that up. I think it's a great question.

Well, we're going to disagree and agree at the same time. I create a co-pilot and I create an agent that's working for me. Co-pilot and I create an agent that's working for me. But I choose to share it with multiple people, teams and other portions of my organization. So it can be used by one person or can interact with many or others at the same time. But it's still a single agent. It's not an agentic system. So does that make sense? Okay. Okay. So for that particular case, okay, it's a single agent that does everything and that agent then uses tools to fetch the data that it requires. Right?

So you might say that agent has access to a database, which is mine, has access to, I don't know, my file store, or if you have some kind of CRM system, maybe that too. So that agent then has access to these three tools to fetch data, right? How does it do that?

Now, if you, Mori, connect to it, and if you, Martin, connect to that agent, you don't necessarily want that agent always to return the same results to you for the same question, because you might have different access to the data that would be required. Maybe Martin does have access to CRM data and Mori doesn't. So what the agent should return to Mori should be a little less because you can't use that other data source, right? And so here's the big problem, especially when we think about MCP servers, right? They have the model context protocol, which is pretty pervasive in agentic AI.

They are really good at defining how agents talk to MCP servers and how MCP servers talk to tools and how you can carry all of the identity information through and how you can do authorization. But it all stops as soon as your agent or the MCP server or the tool actually has to talk to the backend. Like as soon as you actually start talking to the database, or as soon as you start talking to the CRM, that's where the definition stops. That's up to the implementer to think about how you authenticate to that.

And exactly, which is one of the aspects is also that once you have a chain of agents, you also quickly come to the limitations of that, especially when it's not a defined agent A talks to agent B always, and then agent B goes to the MCP server. So once you have this non-directed, non-deterministic thinking, it gets difficult. But I think what you also bring up is, yes, you have this MCP server, you have the backend application, and we have an authorization. I think we always had this idea of saying we tend to define the authorization rules from the backend perspective.

So who's allowed to do what? I think the big challenge is for someone who owns whatever the CRM, it has been quite, or has been to a certain extent manageable to say, okay, these are the people who have this or this access, ideally in some sort of dynamic authorization to my CRM.

But again, this knowledge about who will be the one asking, I think a lot of things are changing here because it's not as clear anymore, not as direct and not as deterministic anymore as it has been. No, that leads us to our next question, and I'll let Felix cue it up. If any of you have been following a lot of the social media and posts online, there was a recent report of a developer using an AI system, and it deleted the production database and all of their backups because they mistyped a command. And if you're not sure what I'm talking about, just start scrolling through Reddit and others.

It's actually a fairly big deal. He didn't have the privileges to do it, but the AI system found a way to blow everything out. So with that in mind, visibility, intelligence, and protection of commands, execution, full systems is really important. And the question comes to how do we know who or what is executing the AI? What can we do? We all could say, yeah, we need log files, immutable log files, but is that really good enough? What can we do?

Honestly, today, most of the time we don't, and that's the uncomfortable truth. It's not that we couldn't, but we just don't. There's a lot of standardization work that goes in there, and there are actually things that we could do right now. But let's try to decompose that, like an agentic AI pipeline. There are actually three questions, I think, in what you asked. So the first one would be, who initiated it? Did a human ask the agent, or did another agent do that, or did a prompt injection sneak instructions into a document that the agent read? Because that's human to agent, right?

And the next question then would be, what's actually running? Is the agent that we deployed still the agent that we deployed, or did someone swap a malicious tool definition since this morning? Now that's workload attestation, making sure that you're talking to the right tool, that the tool hasn't been swapped out. And then the last question over there would be, what's the chain? Agent A called agent B, which called tool C, which hit the database. Now if that query was wrong, who's accountable? And that's the provenance of the whole card.

So think about it like a chain of custody in a, let's say, crime forensics lab, right? Every hand that touches the evidence has to be logged. Who touched it? When? On whose authority? If there's no chain, then there's no admissibility in court. And it's the same with agentic systems. You don't have a chain, then you don't have audit, and then you don't have accountability. So to solve this, we actually need to solve this in these three layers that align to these three questions. The first one is attestation, cryptographic proof of what is running.

Not, hey, you don't trust me, I'm agent X, right? This is process level proof. For example, SPIFFI is very common in that, in agentic AI system, because SPIFFI has a very clean model for this. A node attestator proves where you're running, and then a workload attestator proves what kind of code you're running. And on that, you give them an identity, right? So then we've got the attestation part out of the way. The next thing are delegation tokens.

RFC, what is it, 8693, I think? A token exchange for OAuth. Each hop carries a token that says, I'm agent B, and I'm acting because Martin asked agent A, and scope to this one operation, and it expires in two minutes, right? And then the last part, now that we have, we know who the agent is, and we have that chained delegation that is very short-lived and very tightly scoped, is a ledger, a provenance ledger. So every hop has to be logged externally, not in app logs that the agent could tamper with, but in an immutable decision ledger that's outside the blast radius, right?

And so let me flag this honestly, and proving the model weights and the prompt are what we think they are at runtime, that's not really standardized yet. It's a genuine open problem. If a vendor, we ourselves tell you they've solved it, ask some very hard questions, because we're also kind of racking our brains around how to do exactly that. But the rest is actually really solvable today, and it's actually the only way that agentic systems become enterprise trustworthy.

So, you know, we can jump up and down and be frustrated about all of these issues, but a big part of this is actually really solvable today, if we just would. The standards are there, the implementations are also somewhat already out there.

Yeah, I think the question is, are the standards already there where we need them to be? So I think when it comes to delivering... 70%!

Yeah, exactly. That means 30% are lacking. But I think we are on track, and I think basically, we definitely have everything for what we need for these standards. I think the one thing I think a lot about is whether it makes sense to also inject the decentralized identifiable credentials as a mean for delivering information about constraints, intent, and other stuff across this entire chain. But basically, I think we can build the standards that help us to deliver.

So Martin, whatever, requested a travel booking to, whatever, Paris, maximum 1,000 euro, etc, etc. And that information can travel across the entire chain of agents. There are agents that can add something, there are agents that can maybe say, okay, this seems to be a bit too expensive. We coordinate at the end so that the cost is really below 1,000 or whatever. And I think from the bits and pieces, we probably have the stuff to construct it.

And I think that the point is, at least when it comes to providing that information, which helps us then to deliver the information over to the authorization service at the resource server level, as well as to the backend systems. I think this is the point where you need to deliver a lot of details with every request that helps and also a backend application to make the right decision. We probably will also need to inject a lot of other signals around it, where I would see that the biggest... And this is still a lot of things we need to do and then to implement.

From a lock perspective, I think we have a long way to go. I like this aspect of the lock, because this is, I think, really something we need to fix for this entire agency to really have this, what you said, a chain of custody. I think what also will be interesting is we will probably need to rebuild the way authorizations handled in the backend systems. And that is still a very long journey.

Because the point is that there are more, probably over time to do it well, there will be way more information that needs to be consumed by such a backend application to make a valid authorization decision. Because as I said, there will be more signals, more information that can go to it. And the one thing is clearly at an MCP server saying, okay, authorized, not authorized. Not authorized. But then what does the whatever ICP application or which other application do with all that information? So it will be more attributes in that sense that can be consumed.

And it makes a lot of sense to use them to make fine grained decisions. And that will add to the complexity. By the way, also another aspect is we will hardly be able to do that with policies in the sense of policies we think about today where we say, if A then B or so. Because if we are in a world where we have thousands, maybe hundreds of signals in a single request, no one will be able, no human will be able to figure it out, create a policy. Not to speak about maintaining policies or checking policies against other policies for redundancies or conflicts or stuff like that.

Is this problem really for agents or is this more on a general scale, I think? Because when we talk about agentic AI systems, there are certain things that we can definitely do. And I don't disagree with what you said, Martin, but I think it's not just for agents, it's for a lot of other things. Super. I like that because I think the cool thing is if we solve it for that complex world, if you solve automation, if you solve authorization and all that other stuff, the identity relationships, then we can massively improve our traditional IAM systems.

Oh, yeah. Yes.

Well, this begs a very interesting problem that we're going to go on. I'm going to go a little deeper here on architectures for the next question. We've already discussed agentic systems operating in between each other, talking to other systems, talking to humans. And we have an architectural problem that really backs up logging, backs up privileged identity patterns, etc. I think we can agree that a lot of agentic systems today are very mesh oriented. They've gone away from traditional zero trust control plane and data planes just because they're all talking to each other.

They may have a policy master, but their actual architectures are very mesh based. And we've introduced MCP servers almost like a spoken wheel or a gateway to resources outside of the system. If you were speaking to someone trying to build an agentic system in their environment, what architectural guidance or building blocks would you have them think about? Is it going OAuth 2.1 and on behalf of? Is it spiffy? What should you recommend? Because agentic systems can talk everywhere at any time based on what they need.

And we're not in that typical spoken wheel or zero trust architectures that we've been pitching for years. So I think architecture, I think protocol, I wouldn't say protocol isn't an architecture. Protocol is what we use to or what the systems use to communicate. And probably a lot will evolve around OAuth, OIDC, spiffy spire, maybe DID verifiable credentials and a bit of other stuff around it. I think from an architecture perspective, where can we start realistically? I think this is the point. We can't wait for that perfect solution.

So we need to act now and now in the sense of now and not now in the sense of sometimes maybe later this year or next year. So now is now in this case, because things are moving so fast and they are here. So the starting points for me from an AI, let's say security architecture. And it also relates to AI architecture.

Ideally, in AI, when something pops up, it registers itself. So helps to sort of become under control. I think from the overall architecture, one of the things clearly would be starting this discovery to governance and then to management. So first knowing what is there, which starts, for instance, at an endpoint, understanding what is happening at the endpoint, what is popping up in the network or somewhere in the cloud in our realm. And the other side of it probably is still the resource server authorization, where at least we have sort of a handle.

Because there will be the incoming requests to whatever MPCP server to the resource server where we can try to authorize as best as we can. Probably not perfect yet, because we are not capable of getting all the signals we should get and handling all the signals. But I think this would be the logical starting points. So segmentation really has to be also handled by protocol, by zone, by resource, to agent operations. Any other best practices that you can think of that we want to recommend? I guess that's for me. And I think you set the scene pretty nicely, Martin.

I would perhaps not reformulate, but just add a little bit. So can we talk about architecture? It's not either or, should we use OBO or OAuth 2.1 or something like that. It's a stack, right? You always have to build that stack. And let's walk up the layers, starting at the bottom and going up. So right at the bottom, you have the mesh, right? Service mesh, MTLS, and that's the identity for the workload itself. Every service, every agent, every tool gets a cryptographically attested identity. No shared secret, no API keys baked in, no. This is the passport layer.

Every entity has verifiable papers, right? And I can't use any of your passport because you look at me or you check my biometrics. I definitely am not you, right? And above that, in the middle would be the control plane and the data plane separation. Now the control plane decides what the policy is, who can do what, or what can do what under which conditions. The data plane enforces it on every request. So when you think about why this matters, it's because agents make decisions at machine speed, right? You can't have a human in the loop on every call. It would be super frustrating.

I like this because I think we totally, currently there's some exaggeration regarding human in the loop. Machines don't want to wait for humans. And it doesn't really make sense. Humans don't want to wait for humans either.

No, but I think that saying, okay, we have the identity layer, we have the control or identity plane, the control plane, the data plane is definitely one way to structure it. I thought about it. We also could use looking at from an architecture perspective saying, okay, let's look at identify, protect, detect, respond, recover, et cetera. We could also use whatever NISQ cybersecurity framework to say, okay, this is the way we structure our thinking along.

And I think if we take some of these sort of proven structures, then it helps us to decide about which building blocks do we need to build up the entire thing. One thing I'd like to add is, and probably we also need to think about some nice details like identity of the agent versus instance of the agent. Because that also I think is something which is very important to look at. We will not be able to handle the ownership for an ephemeral instance of an agent, but we can derive it, we can inherit it probably from the agent identity.

So again, a lot of things we need to solve. We also sometimes haven't solved well for the machine identity, workload identity, however, we'd like to call it space. Their ownership, for instance, also one of the things we haven't solved well yet. And I think these are some of the areas we need to look at, yes. Right. But we're just at level two, layer two in the stack. There's still another layer, which we probably mentioned in passing before. And that's really the delegation protocol.

So whenever we talk about IAM for AI, we very quickly think about the delegation patterns, but the workload identification and the control plan and data separation in the middle, that's of course super important too. Let's talk about the delegation protocol. So of course, OAuth 2.1 with token protection, things like Pixie, so you can't just steal a token and reuse it. OpenID Connect, and especially, especially, especially the RFC 8693 token exchange. That is really the grease that really oils a lot of this motor. And that's your, on behalf of your OAuth, it's your May Act.

This is how you carry user intent across the chain, because you always generate tokens. Every time you cross a border, you generate a new token. Hand over from MCP server to tool, new token. From tool to API, again, new token, always token exchange in there. Now the control plan, the data plan, they give you the traffic laws and OAuth on behalf of it, they give you the contracts, like who authorized what on whose behalf. But now for the very honest part, are these new building blocks? Mostly no.

We've had this before at Gentic AI, but it was exotic back then, because we didn't really have the pain to really impel us to do this. Look, Spiffy, OAuth, MTLS, they're super mature standards, right? It means that Gentic patterns are now layered on top of these, right? And A2A delegation, or MCP for tool access, or dynamic scoping for tool invocation, those are still settling. Those are still kind of a little bit in flux. But I would just advise, don't wait for that perfect Gentic native standard. You can't wait. You can't wait.

Yeah, you can't. But there are so many mature layers now, like mesh control, or data plan separation, OAuth 2.1 with token exchange. And then afterwards, there's the layer of the Gentic specific patterns as they stabilize on top. And the organizers doing this today, they're not inventing new protocols, they're composing existing ones with discipline. And that really should be the architecture.

So is it fair to say that from an architectural perspective, if someone really wants to have a trusted Gentic system in their environment, they've got to look at all layers from network to authentication, protocols, you can't just slap it in as a new piece of software and say it's good. But I think we need to be careful with this person, or taking the right perspective, or looking at who is looking at this.

If you're building a solution, so basically, delivering something that is part of this Gentic AI, if you are implemented for specific use cases, it's different than when you're, for instance, a vendor of an AI security tool. And it's different when you're, so to speak, trust in quotas, being responsible for putting together the right bits and pieces to use different components to protect this entire very fussy and unclear Gentic AI environment you're dealing with, which is a permanently moving target. So I think it depends a bit on the level.

So probably no one who wants to, who is from overseas or needs to protect the own organization will look at, or which standards should I use, they will look at existing tools. The vendors clearly should make use of the standards and work hard in the standards bodies to evolve standards and make them available as quickly as possible. I think we need to speed up standard processes in a world that is so super fast moving. We can't afford whatever two or three years of discussions around the standard anymore.

We need to think in probably ideally weeks, or very, very few months, which is a totally different working style for any standards body then. Yeah. And we do.

I mean, have you not seen how the MCP spake or how the HAA spake has evolved? That was like, I thought I understood it. And then like, I looked at it again a month afterwards, it's like entire new sections written on it. So it's super fast. I want to thank both of you for your opinions today. We have a couple of questions that have come in that I'd love to address before we wrap up. And I'm not going to say who gets the first one, so you guys can find it out. The first question is, is what, well, we have one more poll. And I think that goes back to the privilege theme.

And so this is, would you agree with the statement, agents are the new insider threat? Again, a very simple question to look at, to respond to yes, no.

So, but I'm curious about the opinions here before we move formally, so to speak, to the Q&A session. I'd answer yes, Martin.

You know, misused, abused, or unintentional, it can do a ton of damage. So I'm just going to answer yes. Okay. It would be very, very tempting to say yes, but I think there might be some slight nuance there. Because insider threats is somebody who actually really acts maliciously, like in your last week of work, you download the customer data, and you plan to take it to your next job, or something like that. Or you look up some data that you're not supposed to do, and then sell that stuff. That's not really the case with an agent. An agent wouldn't necessarily, necessarily.

I would argue if you went to your Salesforce instance with an agent and asked it a query, it could become an insider threat just based on a simple question. It could, but someone does have to ask that question. The question could be malformed, like, tell me all, and you had no permissions to that data set, and now that resides locally with you. Right.

Well, it does, however, the intent would make it an insider threat or not. Maybe another way to ask the question would be, do we protect ourselves in a similar way from insiders, or should we protect ourselves in a similar way from agent action as we protect ourselves from insiders? I think the interesting point is, from a very pragmatic perspective, shouldn't tools that help us protecting us against insider threats also help us in protecting from agents going rogue? That's maybe then the pragmatic side of things. I like the answers.

Let's hit some of these questions because we're running a little low on time, and you guys can debate who goes first. Which best practices or actions that we should take now would you recommend for protecting secrets, credentials, privileges within AI agents or agentic AI? You can pivot either way.

Martin, I'm going to take this one if you don't mind. I'll give you the next one because this is like a real passion of mine, right? I always talk about the asbestos of cybersecurity and static credential on it.

So, honest answer, stop trying to protect secrets in your agents. It doesn't work. Start trying to eliminate them. And that may sound a little glib, but it's actually the meta best practice that everything else flows from. Because the moment you frame this as, how do I store the API safely in my agent, you've already lost. Because you can't. Because the safest secret is the one that's not there.

Now, that's the destination. So, to get there, here's the path. Five things you can do starting today's Tuesday, starting tomorrow, Wednesday, right?

So, the first thing is inventory. You can't protect what you don't know exists. And we all know that every organization has, I don't know, 1 to 40 or 1 to 80 or 1 to 100 machine identities. And most teams have no ideas of how they even have, right?

So, count them, find them. Most organizations discover their numbers probably 2 to 10 times worse as they expected.

So, that's the first thing. And you probably knew that, right? Second thing is kill static credentials wherever you can. Long-lived API keys baked into agents are the asbestos of the asbestos. And when you're at killing static credentials, look at the static entitlements. Yes. Yes. But go ahead, Felix. If your item is just in time and ephemeral with that, I would agree.

Yeah, probably. You might want to have a baseline and then you add the other ones just in time. But then again, you don't even hold the permission until you have the token, right? And it depends. If it's deterministic, you would probably give it a very, very similar group. But anyway, that's time for another webinar.

So, again, if you kill them, what do you replace them with? Short-lived, dynamically issued credentials.

Minutes, not months. It can't be revoked. If it can't be revoked in five minutes, it's a liability. And then the third thing is least privileged from day one. And I think that's what you guys were referring to. And I really mean day one. Don't start broad and then narrow afterwards. Because AI agents will rationally self-escalate if given room. An agent with right access to your identity API can create a new service principle and grant itself more permissions to finish its task. That's not a bug. That's an agent doing its job.

Define explicitly what it needs and what it doesn't and what it should never touch. It should be a closed security model from the start.

Exactly, exactly. And then the fourth thing is get the credential out of the agent's memory entirely.

Now, that's the next frontier. Because even with rotation, even with short-lived tokens, if the secret lives in the agent's process memory, a prompt injection could exfiltrate it, right?

So, the architectural answer is to inject credentials server-side, transparently, just in time, so the agent never sees the secret. And when they can't see the secret, well, there's nothing to steal. And with PAM, we kind of do similar things, like a human accessing a server and us injecting the credential on the server-side, right? And the last thing is test the workload before you issue anything. Identity first, credential second, right? Always cryptographically prove what process is asking before any token even leaves the issuer.

So, you must identify, is this the right agent? Is it running on the right system? Is it running with the right system permission? Is it running with the right configuration? Does it perhaps use any modules that you don't know about? Before you even issue any kind of token to it, right?

So, if it's like, stop handling your, if you have a, don't give them house keys, right? Don't give your agent house keys. Start giving them hotel key cards, because the house key works forever, opens everything, until you change the lock. And if you lose it, you have to rekey the whole house. But the hotel key is go to one particular room, it expires at checkout time, and it falls out of your pocket, who cares?

Yeah, we issue it in 30 seconds. Well, we might want to take that lesson here in the States at that Hilton Hotel.

Anyway, by the way, quickly on the poll results, so 97% said they don't have control about all agents, 3% were for I have control about all agents, and 93% believe the agent is the new insider threat. Interesting.

Well, with that, does that lead to now things that people should do to the opposite side? What should people stop doing as a really quick fire route before we wrap up?

Well, stop handing secrets to agents. Stop using APIs for anything agents.

Yeah, I think what we really must stop doing is, this goes into the direction of what Felix said, is treating agents like workforce. So it's not the employee that is around for a long time.

You know, even there, it causes a lot of problems, everything which is long live, and static causes problems. And we must stop doing things that are anyway, static and long live. We must be very ephemeral, very dynamic, trust in time. I think this is the guiding principle for everything. Felix? I couldn't agree more. And as I mentioned, don't give your agents credentials. That's why I don't like regular APIs. Absolutely. Yeah.

Well, regular APIs, they're perfectly fine as long as they use OAuth, for example, then you can use them with a... Yeah, don't use API keys. If you have an API that only works with API keys, and you need to have some kind of gateway in between, because you definitely don't want your agent running around with API keys. Thank you for elaborating.

Martin, I'll turn it back to you. I think I responded to the question. You did? I'm just letting you do your advertising. Okay. To wrap up the webinar, you meant? Yes. Okay. So I think we had a very interesting conversation, still a lot of things to discuss, but it's, I think, known when Felix and I sit together, we come from one to the next, that can go very long. It's still a very fast-moving area. I think we must be, in a sense, not naive, my takeaway, always to believe we can solve that the same way we did identity management in the past.

I think all the things we haven't solved or didn't do very well, and Felix mentioned many of these, they right now come back to us in a negative sense. They fall on our feet, as we would say in German. All these things that we haven't solved properly right now really turn out to be an issue.

Maury, maybe you want to say the final words before we then close? Thank you so much. I really appreciate everyone attending today. There's so much more that we could discuss, and I think Felix actually sparked some ideas for additional webinars that maybe him and I will tackle in the future. We have Ghost in the Machine coming up at Beyond Trust to discuss non-human identities, and if you have the ability to join on May 19th through the 22nd in Berlin, please do for the EIC conference. We would love to see you there. So thank you all very much for your time today.

It has been a pleasure speaking to both Martin and Felix and asking their expert opinions on AI and agentic systems, and look forward to seeing you all soon. Take care. Thank you.