Paul, thank you for the great introduction you've made. Yes, I'm Martin, one of the founders of KuppingerCole Analysts, and probably all of you have seen me in other sessions or other EICs. So I'd like to talk about what I call AIdentity. And AIdentity, that's basically that. It's AI plus identity. It's identity for AI and it's AI for identity. So both aspects. And I think we see a lot of talks around AI and how AI sort of impacts what we are doing in identity management, what it potentially can do for identity management.
But also we have sort of the other side of it, which is what do we need in identity for AI? And so my focus today will be a bit more on the identity for AI side. So it will be on AI identity, but more on that facet. The AI for identity is a theme where we also have another session tomorrow, I'd like to hint on, where my colleagues Alejandro and Nitish will talk about leveraging generative AI for modernizing IAM towards digital ID management across the stack. So they will really look at more the use cases that we have around utilizing AI to make IAM better in the broadest sense.
Tomorrow, 11.20, same room, so you can stay here. And it's in that sense, oh, there's still a lot of in, but it's probably more the known part of AI identity, the AI for identity. It's already used in various use cases for quite a while. We see also Chen AI driving a lot of innovation. We still have a huge potential for doing things better, for improving, but we are on the way. So we use it for identity analytics. We use it for adaptive access, so making or supporting authentication decisions, risk-based authentication is where it certainly comes in.
Predictive identity, maybe, which is going a bit further into what may someone want to do next. But I can envision a world where we, at some time, will receive our access entitlements, trust on time, because the AI has an idea of what will we do next. And they will also disappear when we do something different. No standing privileges, accounts with zero entitlements, empty accounts in that sense. So even if they got compromised, who cares? Identity verification, clearly a very huge area where we also have all this deepfake detection discussions around.
And there is an area where AI and identity come together. So some things around passwords. Entitlement management, role mining, which is, by the way, a totally boring use case, I feel. Because I also don't like role management, setting entitlements are ugly and bad, and so let's try to get rid of it. Peer recommendations, oh yeah, you need to like it or not. So I think AI could probably help to do it better than when we do it manually, in that sense of saying, okay, if that person has this entitlement, that person also needs it.
When we do it differentiated, and not just copy-paste, then it can make sense. Also, verification. Access re-certification, maybe simplified.
Again, if you get rid of access re-certification, it's even better. I'm still working on a blog post. I would have loved to have it done ahead of EIC, but I'll do it sometimes later, which will have a title around how to get from 100 to 0 in access re-certification in a day. So how to get just rid of it. So look at our blog. Hopefully in the next couple of weeks, I will be able to deliver it. Supporting, support helpdesk, onboarding. And onboarding is a really cool use case, because we're always far away from our targets when it comes to application onboarding. So simplifying that.
Clearly, it's good. Detection response, the entire ITDR, saying one of these other acronyms we have these days, really benefits from that. But it's something where we see still a lot of things. And so I called it the known part. And I have to be fair, it's definitely known, and we are not yet there. We're working on that. It's interesting, but I would say the thrilling part of it is the other side of it. The thrilling part is identity for AI. Because what does it mean? What is what we need to solve? And I'd like to start with a couple of questions here.
When you look at this world of AI-powered agents or AI agents, for the world of LLMs, large language models, the world of analytical AI, more traditional part, the world of RAC, retrieval augmented generation, if you haven't heard that term yet. So some of the things are structured a bit.
In fact, my colleague Matthias structured it, because he reviewed the slide deck and said, come on, bring in a little bit of structure. So Matthias is also guilty for the relatively small font size, because he added all the additional headlines, which led to a smaller font size. So how do we set controls for AI agents that act on our behalf? How do we ensure that they don't go rogue? This is something an agent acting on behalf of us in an identity. Interesting question. And it's an identity problem to a certain extent, not only an identity problem, but an identity problem.
How do we control access of AI, so the LLMs, for instance, especially, to data? How do we show that they do what they are supposed to do and not more? How do we protect the data that is used, which is the other side of it? And we all have heard these examples of LLMs being trained to provide responses that are inappropriate. So we need to have proper data, because this ego thing clearly applies to generative AI. So great input, great output, to phrase it positively. Or garbage in, garbage out. Same thing. How do we control the access to the LLMs? Who can change their behavior?
How can we make changes to adjust the LLMs, configure them? Policy and model control. I think this goes back to the access to data. I think one of the interesting things is AI thinks in data, not in functions. So a lot of what we do is function-based. So authorization objects in SAP are function-based in transaction codes. So a lot of access control we do is really function-based, but this is data-focused. Generative AI just wants to get access to the data to provide a proper response or what it believes is a proper response. Could also be hallucination, as we know.
Especially if there's not enough data, then it tends to hallucinate. Contextual identity. So what is it when we have an agent, and this agent runs on behalf of different people? And how do we ensure that this learnability, that AI agents can learn what is appropriate to learn from others, and don't learn what is not appropriate to learn? So there are things you probably want to do with AI sometimes, but you don't want to become common knowledge. I'll leave it to your imagination regarding the use cases, but I think there are tons of use cases that could come to your mind.
How do we ensure that it's visible and traceable? What has been done by AI on behalf of humans, and whether or how it was permitted? And another area, how do we identify an AI? How do we know that's an AI, not a human, or it's a human, not an AI? And there are some interesting questions. Is it just the ownership? Probably not sufficient. My colleague, Jonathan, called it the dog mark thing, where you say, okay, this is just marked by the person. Identifying markers, behavior, the human, or it's acting on behalf of by who it communicates with.
So I think there are different ways to identify, but we need to figure out ways. And I don't have answers for everything yet, but I think there are a lot of questions we need to find answers on. And there's an interesting thing, I think, when you've been long enough in the identity space at EIC, you at some point came across the topic of identity relationship management. And I think we are reaching a totally new level of identity relationships here. So we haven't really managed the traditional relationships thing between humans, and maybe humans and organizations, et cetera.
But here, we have humans or non-humans. So could also be something technical that is using an AI agent. So the AI agents are acting on behalf of humans or non-humans. They may communicate with other agents. They may even create other agents. And then they communicate back to humans or non-humans. And this is a very complex scheme of relationships. And we need to learn to deal with that. That's part of AI identity. How do we deal with that to ensure that this works as expected? And as I've said, it's also another point I'd like to raise is it's a new paradigm for access control.
And I've created this matrix, which I call the what-how-ouch matrix, which is basically what is happening, how are we doing it, and why doesn't it work? I think it's a very good approach for a matrix because you can apply it to virtually everything in IT. So we have something, we try to do it, and we still have challenges. So what-how-ouch. This matrix looks a bit at how do we do access. And the point is, when we look at, for instance, file servers, we do it to a certain extent, data-focused access to directory trees, directories, files, and a bit of coarse-grained function-based entitlements.
You can read, you can delete, stuff like that. Difficult to trace and audit. Still haven't solved it well, I would say, since the days of early network, where no one understood what a trustee, etc. is. Maybe some of you grew up with stuff like that. I'm old enough.
Databases, data-likes, etc. I had so many conversations in the past with organizations thinking about how can we ensure that people only see the data even when they combine the data that they are allowed to see. So this is a very much data-focused aspect that sometimes also has functional entitlements and really lacks a sophisticated approach. So I think we don't really manage this well. Collaboration tools, space-focused. So you can access this Teams room.
But I think for Teams, you can wonderfully see what happens when you combine very outdated concepts, or let's say called mature concepts, which evolved. So in Windows NT days or so, trickled to SharePoint, where they even already were inadequate. And then you put it into Teams. So you don't have a really good control about what is happening. So I think what Microsoft should have done is really reinvent access control for Teams when they do it. But clearly, if you put Teams all based on SharePoint, it doesn't get better.
And I always said, you know, for SharePoint, when you have dozens of vendors that try to help you managing SharePoint entitlements and access, then something is wrong. And so it didn't get better with Teams. No granular data-focused or function-based access controls. For business applications, they're mostly function-based. Sometimes there are some data-focused controls built in, added to it. Very complex, especially if you have multiple applications. Everyone comes with his own access control model. And some of these are complex, like Salesforce, like SAP.
Rights management try to add a function-based approach, but just per document, which is also pretty tricky to handle. System administration function-focused. Then we have AI. And we don't really know how to do it. So we have really huge gaps here. I believe that policy-based access control will be a very important element, because once we have multiple dimensions of access, we can't solve it with traditional single-dimension-focused access control models. It just does not work.
And yes, I put the one to rule them all because it has this negative connotation into growth. But basically, it is something we need to look at, because we can then, for instance, say access to a certain function of certain data under certain conditions, in a certain context, et cetera. We can do these things. And this is important.
Over time, I'm absolutely confident we will see, and probably the other side of AI identity in that sense, we will see AI helping in doing policy-based access control better. Because creating the policies, maintaining the policies, contextualizing decisions, this is the really smart point attribution to Johnson. He brought it up when he reviewed Masladek.
This is, in that sense, a benign element of that, because when we have a policy, it's usually still black and white. And this is the gray thing here.
It says, in this context, under these circumstances, you may be allowed to do that, because it's still OK. It's the road to take, also for AI, access controls for the next decade. And to be very clear, not moving to PBAC is just wrong. We need AI, or AI needs policy-based access controls now. We can't handle it with traditional methods. This would be the same like Microsoft did with Teams. And I like Teams. I use Teams a lot. But from a security perspective, there's a little room for improvement. The good news is AI identity challenges are IAM challenges.
If you solve AI identity, we will solve a couple of very old, unknown, and not so well-addressed gaps in identity management. Three areas to look at. Identity relationship management between humans, AI, things, etc. If you solve that, we also solve identity relationship management for humans to humans to organizations, etc. All these different things we discussed for years. Comprehensive access governance beyond functional static entitlements. So we had a peak of data access governance a couple of years ago.
But all the different facets of access governance across everything is something we will make great progress, including the data access management. And when we think beyond this, just a little bit of thought-provoking, we could then over time think also, how do decentralized identities come into that? So we can't do a presentation without mentioning decentralized identities. So I added something around that.
Now, I think it's an interesting thing. Because it's decentralized identity, we have to verify the credentials that contain information about, and that can be a lot. It's not just identification of a user. So more than this. And we could envision that there are the agreements between humans and AIs or between AIs are put into verifiable credentials, which in some sort are reflected in quotas, big quotas, a smart contract, maybe backed by a distributed ledger. And that we then have some proof and tracking of what is the AI supposed to do that it's also others can look at. Is this acceptable?
Or not? Is this the correct behavior? I think we need to bring together different elements of what we do in IT here. Distributed ledgers, I don't like the Trump blockchain, the smart contract stuff, verifiable credentials, etc. to really solve the problems we are facing. And we need an enterprise AI framework that starts with, why do we do it? Because we want to have new and better products, which is external facing, new and better services, external facing. We can get better. We can do new business value, business processes, business models, etc. But also to improve our own business process.
This is where the AI potential comes from. For that, we need the technology, the different types and incarnations of AI models and prompts. And hopefully in three, four, five years, we don't care about prompt engineering anymore, because it just happens. Like we don't care about writing HTTP pages with embedding HTML code like we did in the early days of the internet or the web. We have the data, where we need data quality and governance, data aggregation. And last but least, we need a control framework.
And that control framework needs to look at AI governance, explainability, security and safety, which are two different things. It would be a separate conversation probably. And we need AI identity to have this governance, risk and control in the framework. So let's start solving the AI identity challenge. Now the I should be in capital for AI identity before AI goes rogue or wild or whatever. Questions? I think we have 25 seconds left for questions.
Very much, Martin. As usual, I would highly recommend.
