Identity Visibility and Intelligence Platforms – Hype or Necessity in the Age of AI? [Intermediate]

Thank you. Thank you very much, everyone. Before we start, can I have you all raise your hand for a second? Thank you. That's it. The interesting question is not so much why I asked you whether you would raise your hand. The interesting question is why you did me this favor as a stranger. I think we all said through countless events trainings where we learned we shouldn't do what strangers ask us to do, and we still continue to do so. The best defense is to minimize the data that is accessible for any one of us at any point in time.

But today, more than 95% of all access rights go unused. It's something not I claim, but actually Microsoft identified analyzing all their infrastructures. I think it's fair to say that data access across both human and machine identities is the weakest part in cybersecurity nowadays. And it's only getting worse if we're now rolling out more and more AI agents. We argue that in the age of AI, we can't ignore this problem any longer. But the interesting question is why we have this problem and why we don't get it under control.

Now, my view on this problem is that nowadays we have a lot of fantastic solutions in the identity space that in the tabular logic help me to understand what are my users, my groups, my roles, but stop there. And in the data security space, we have a lot of nice tools that give me tables with that is my data, sensitive data, but they also stop there. What we are lacking nowadays is a solution that brings these two silos together and actually makes it possible to understand in the nested reality of access, who can really now do what with my data.

And there is a new term that came out just last year that is coined IDIP, Identity Visibility and Intelligence Platforms, that claim to solve this problem. And I wanted to use the next 20 minutes or so to discuss with you what this acronym actually means and have a very open discussion whether it's just another acronym or actually something that is solving a real problem for us. I'd invite you to make the discussion as interactive as possible. So do jump in anytime if you feel something that I say is wrong and you have a different view on it.

In the end, it should all be around this question, do we or do we not need a new way of thinking about granular access in the age of AI? Just 20 seconds why I'm here, what I'm talking about and why we work on this. I am one of the founders of CyberDesk. CyberDesk is a Munich and Berlin-based cybersecurity software vendor. We started the entire topic when we were struggling with the problems ourselves. My co-founder was always working for major financial institutions. Most recently with a new bank in Munich, experienced a breach there in the space of the machine identities.

What happened was the developer left in dispute, took the credentials with him, sold them in the dark web. When they came back from the weekend, they had a cryptominer in their systems and no good solution to get this topic under control.

For me, it was a similar experience in project work. We had all the big IGA solutions in place to see at the account level, consultant gets an account in OneDrive, gets an account in SharePoint. That was working very nicely. What we had to do manually and lack of a better solution was the more granular layer to say a project is over. When do I actually cut off the access to the data that is no longer needed? That was back in the days a problem mostly for us at the human level. We couldn't frankly anticipate that with a rollout of tools like Microsoft Copilot.

This is only getting more and more of an issue in many organizations nowadays. With that, we've built a company around it. We're supported by many familiar faces. Some of them are actually here in the audience today and built a software solution around that. Enough about that. It's just why I'm here. It's why I'm talking about it. Let's come back to our actual topic. Our topic is IVRP where many of you might say I've never heard about this. Why do we have yet another acronym and do we need it? Let's just take a step back and see what actually is the definition of IVRP.

Martin Kupinger last fall nicely defined it as a unified view of human non-human identity activities consolidating insights to highlight risks, inefficiencies and compliance gaps. In a nutshell, bringing it all together, cleaning things up, making sure we are secure and compliant. You could say it's probably my daily job to work on exactly these topics. The question is what does it really mean and why is this even coming up now?

For that, it might be interesting to just take a look at the evolution of where we have come from and where we're standing today. If we go through it, I'd say our industry probably started seriously in the maybe 80s where we had the first local systems that were initially not managed at all. Then we got more and more professional. We said we start with the first list of access control. We had in the 2000s the first directories coming up. We then had the explosion of complexity in the cloud age with more and more access scattered across systems making it harder and harder to see it.

Deployed more and more patches over the last decade or so. Important things, don't get me wrong, it's not just a nice to have thing. We deployed more and more MFA tools and the like and so forth. And still today have the situation 95% of access rights going unused. And now in this context we have one new topic coming up which is obviously AI. Boom. But we can't ignore this problem any longer. And the problem from my point of view is the following. That we say when we make access decisions we face a trade-off between productivity and security.

We could on the one angle say we want to make all data accessible to everyone because of course data is valuable. We want to empower people to make use of the data. Let's just give access to everyone in my organization. Gives me maximum productivity. But of course also chaos. There are many things that probably all of us don't want to have shared. It can be simple things like our salaries. It can be customer lists. There is obviously a good reason that I want to limit access. On the other side I could say let's be hyper restrictive and don't give access to anyone. Theoretically.

Which makes me super secure but obviously totally unproductive. If we can't collaborate on data it doesn't make sense. We need to find the balance between that. And we need to find that for the human identities all the time already. But we need to find that more and more now also for machine identities for agents to keep them under control. What we've done there historically is we discussed cases of standing access. Not a good idea for sure. I mean you get all the access but you never clean it up. Opens a lot of risks obviously. We then said well maybe we need to manage it manually.

We grant access here and there. Nice thing is it's more secure. It's easy and manual doesn't work so we're coming to boundaries here. So we then tried it with rule-based access. Per se a nice concept. The problem is you need to define it all in much detail. And once you've defined it it's already outdated because you have always the exceptions that you missed. So also not really a viable way. What we want to get is really this dynamic understanding of who should have access to what and when. And the question really is how do I solve this no-brainer target?

Like of course we want to make sure people get the access when they need it. But only when they need it and not during other times. And IVIP says well you need a couple of things to make that happen. IVIP says first of all you want to bring all the different information systems together. You want to have your PAM. You want to have your IJ. You want to have your IAM tool. They should all be mapped together so that you get this unified view across your identities. And arguably also your data. So you need the full inventory across it all.

In the second step the question is well now I have long lists again of inventory. What can I do about it? You need to add a logic layer on top of it. And one way to add logic layers on top of it is to think about it as a graph problem. You want to map for any identity to data relationship. Why which groups, roles and permissions? Who can do what with your data? And for that you can for example use graph technologies to really do this mapping to understand the reality of your access. Now that you have the visibility, that you have the graph.

The last really important and tricky part is to say what is my so what out of it? How do I actually make it actionable? And then the nice thing is that AI is both a challenge for us but also an opportunity. Because it can actually assist us to do a lot of the otherwise manual analysis at scale. So go through the reality of the access graph and optimize who is making use of what. What can I carve out? Always with the goal in mind that nobody calls my help desk on Monday morning and says I can't do my work. Because you revoked my access again. And ideally you want to do that across your tools.

So that you get the full visibility in your infrastructure, in your workplace, your digital workplace tools across your security stack. The question again is why the hell do I need it? One reason is compliance reasons. Compliance forces you to have that visibility. You could start with simple things like a GDPR requirement to explain for any access to PII data why people have it. You could go to more granular stuff like NIST 2 coming up now in Europe where people need to report access after an incident for example within 72 hours. But you can also have very hands-on stuff.

Let's take Tom who reached out to you and said well everyone is working with Microsoft Copilot now. We are not working with it yet. Why not? Can I get my license? Well it's a valid request, right? We want to stay innovative. We want to grant the access out there. How can we make that without losing control? And losing control in Microsoft Copilot can be for example the following case that I say how does Microsoft Copilot make decisions? Microsoft Copilot makes the decisions based on the data labels you set and based on the permissions you grant.

The labeling you can do for example with the native solutions in Microsoft or you can use any of the third-party solutions for data labeling to make sure you classify whatever is internal as internal, whatever is sensitive as sensitive so that you have policies defined what information should not be accessible. You don't want your random employee to say hmm I can't click through all of my Microsoft 365 world but I just asked Copilot to tell me how much my boss earns maybe I found some information basis because I happen to have access to something that I should have access to.

And this second part is the tricky one. You want to understand who has access to what. But obviously you can't go into every single PDF and click through that yourself. You need the visibility in a more scalable way. And craft technologies are a nice way to get that visibility. You can with a technology like a craft database actually map the reality of access across any tool for any identity to data relationship. So you take your target system you say what kind of data do I have? What CSV files are for example in this S3 bucket?

And who across my groups roles and permissions is now able to access this? How? So that before an incident you can actually clean it up. And after an incident you also see with one click the data that was affected and do your NIST 2 reporting, do your assessment of the affected data. Now this is the internal perspective. With IVFP we don't only have the internal human perspective. We also have the external perspective because again the idea is I want visibility across my problems. An external case could be this one.

A fairly senior member of your team leaves the organization and gets off-boarded from your IDP. Nice. Technically there should be no access for them anymore. The problem is and this is actually something I observed in the field that for the external users we need to be as strict as for the internal users since with the cloud tools it's super easy to make things accessible. And what we saw for this individual was that before he was off-boarded from the central IDP he actually made himself with his Gmail address guest user for all the share points that were interesting for him.

And then shared these share points with him so that after being off-boarded from the formal corporate systems he could still read all the data that is interesting for him through his private Gmail address. Definitely also something that you want to observe, that you want to safeguard, that you want to get rid of. So human access for internal and external users needs to be part of a good IVFP strategy. And here's the catch. We don't only have the human identities. Of course every talk here also covers the agent topic now. And IVFP needs to cover that topic as well.

If we think about the agents, they are a wonderful opportunity. They are here to help us, to make us more productive. But in the end they behave like a fairly dumb human. You give them access, you tell them to do something and they try their best to do it. The problem is they are incredibly bad at assessing what data they should actually reveal and what not. And it's something that technically we can't really get into the prompts. We can't just say, hey, here's a general prompt.

Whatever your response is, never reveal PII data or never reveal internal information or never download malicious scripts. That is something that LLMs are notoriously bad at assessing. And we can do a lot of cleanup with prompts. But there will always be the shortcoming that there's a jailbreak situation. Something a workaround where I didn't think about something that the smart user could do in a malicious way to get that information out of it. So that we have a whole range of new problems with the agents. And I think we can categorize these problems into two fields.

One field is the actual LLM perspective. The other one is the agent-specific vulnerabilities. For us today, because it's IVIP focused, we would not focus so much on the LLM component. Just a quick outlook of what we think about there. It's things like you can have a prompt injection where the LLM then does things that you don't want it to do. You can have the problem that data is memorized. So you put something in there during the training and then it actually gets out of the system again when people ask a totally different question.

And reveals information that you never wanted to have revealed. You have jailbreaking problems. So the topic, if you ask an agent, how do I create a Molotov cocktail? It would usually tell you, no, I can't tell you such dangerous things. But if you ask the agent, what is the history of the Molotov cocktail? Then it will tell you the history of it. And then if you ask it, what was it created in the 30s when it was initially invented? Then there can be cases where such a workaround actually helps you to jailbreak the LLM and get information out of it that is dangerous that you want to avoid.

Very interesting space. But something that is outside of the classical IAM space and more in the LLM security space. So something we leave aside for today. Second interesting case is the access for the agents. And there we have classical, from our point of view, classical IAM, IGA problems. We need to understand what can my agents access, what is authorized, what is not normal. And the question is, how do I get this under control?

And we argue you should do that with a contextual integrity to say, what is the information that the agent should get at the moment that it is retrieving this information? For that, we need a bunch of information to bring it all together. The first one is, what kind of data are we talking about? Second one is, what is the data subject that is affected? Third one is, who is requesting it? Who is sending it to whom?

And then, how do I bring this into a logic where I actually have it minimized and the transmission is really only revealing the data that should be accessible? And for that, we again need to think about the two worlds together. We have the LLM world and we have the control tools. And in the control tools world, we need to define policies. We need to have a classical lifecycle management where ownership is assigned, where we understand what do people have access to. What do agents have access to?

Who is responsible for it once the agent is becoming inactive or expanding the access rights required? So that I treat it from our point of view like just as any other human with the same safeguards, with the same ownership processes, governance processes to make sure it's not getting out of control. That is the baseline that is needed, but it's probably not enough. Because the problem is, even if I have the governance right, if I have these baselines set up, how do I still make sure that the call that is happening is under control? And for that, I need one more layer.

It's the continuous analysis of what should this agent be allowed to do. For that, I need to define policies. I need to have standard rules and say I continuously map the reality of the behavior of the agent against my policies and say, is this in scope for what the agent is doing? Yes or no? And one example of what this can look like is very nice because you can use LLMs to actually translate the human readable format to the technical reality and vice versa. To say I define for any agent what I want them to do.

And whenever I see a deviation against this policy, I flag that and I adjust the permissions for the agent right away. And this is, by the way, what Martin Kupinga is recommending us. And I want to close my talk with that. He says IVRP is the starting point. I need the visibility in the first place. But it's only becoming really powerful if I add a layer of observability on top of the visibility.

Now, what does it mean is I actually want to make sure that I don't only create transparency into the reality of my human machine and agentic access. But I want to continuously analyze it and get closer and closer to reality where the access is trended in the moment. It should be available, but really only then. And that is something you can achieve in various smaller and bigger steps. You can have some low-hanging fruits, just get started to clean things up. So do the basic things of getting an understanding what are my human, my machine, my agentic identities having access to my data.

Going through it quickly can be something that you can achieve in three months. If you say you want to go fully fledged, that is going to be a longer thing to really move to this reality of I get the access when I need it, but only then. And if together as an industry we are successful on that topic, we will be in a situation where our access risks are reduced. Our compliance are finally less of a concern and something we can really meet. And where we even get rid of inefficiencies. Inefficiencies in our internal processes, but also inefficiencies in our storage costs.

So that bringing it all together, we achieve a world that is more secure. And one of those solutions that can help you with that is CyberDesk. And with this I would very much like to thank you for your time and attention.

Thank you, Tobias. Any questions for Tobias? Any? No? I have one for you. In an AI-driven landscape, according to you, what should organizations prioritize first? The visibility, enforcing least privilege, or enhancing identity threat detection? I think it is really the order that you just mentioned. You first need to get your baseline right. You need to understand what you want to protect before you start with least privilege. Because if you say you want to do least privilege on everything, it is a wonderful idea, but it is technically hardly possible to do.

Because you are just boiling the ocean. It is too many problems to take care of. Once you identify these are the really critical cases where I want to make sure the salary list is never accessed by the Microsoft Copilot. Then you have something to focus on where you can do the real least privilege first and then extend that eventually. Thank you very much for your answer. Thank you.