First of all, what are the clearest signs within an organization that there is too much integration? What would be the warning signs, the red flags that you would see within an organization that have orchestrations but not yet properly approached?

I think the warning signs, the problem is usually there aren't that many warning signs.

I think when organizations spot that they have an issue, it tends to be sometimes already too late.

When we end up with scenarios where there are code elements or other types of integrations that also can be low code, no code, that no one really knows about what they are, What exists? Who did it? Why? How? Et cetera.

When questions like these pop up, then the organization or the part of the organization is in trouble.

So unfortunately, that is frequently in a situation or happening in a situation when there's already a lot happening.

customization, orchestration, whatever done, and it's hard to get back on track.

But also quality assurance might be an aspect where new technologies, of course, I'm thinking of artificial intelligence or LLMs or supporting tools that can just support us in getting better unless or as long as we do not trust them too much, right?

First of all, what are the clearest signs within an organization that there is too much integration? What would be the warning signs, the red flags that you would see within an organization that have orchestrations but not yet properly approached?

I think the warning signs, the problem is usually there aren't that many warning signs.

I think when organizations spot that they have an issue, it tends to be sometimes already too late.

When we end up with scenarios where there are code elements or other types of integrations that also can be low code, no code, that no one really knows about what they are.

What exists? Who did it? Why? How? Etc.

When questions like these pop up, then the organization or the part of the organization is in trouble.

So unfortunately, that is frequently in a situation or happening in a situation when there's already a lot happening.

But also quality assurance might be an aspect where new technologies, of course, I'm thinking of artificial intelligence or LLMs or supporting tools that can just support us in getting better unless or as long as we do not trust them too much, right?

And that was some kind of criticism that you also raised in the, in, in your advisory note to say, okay, in the end, IVIP can do a lot of great things, but the question is, how do we get the data in there and how do we make them normalized and how make-- do we make them, yeah, comparable? Is this something where AI actually can help creating faster connectors, understanding data better when it comes to applying the IVIP capabilities to this data?

Absolutely, yes, and I think this is one of the playing fields for AI that, that when you look at some-- what some vendors did, they, they massively improved their ability to build connectors.

They massively reduced the, the time it needs to build a connector.

So understanding the APIs, the, or much rather the interfaces to data formats.

Also, um, to a certain extent, understanding the potentially customization of data in a target system.

So, um, in, in many cases, the fields aren't always used the same way.

So everyone who has dealt with application integration to IGA knows that there's a lot of custom use of, of different fields, et cetera, et cetera.

The question is, where will they be then? And do we actually care if it's ITDR, if it's IVIP, if it's IGA, when it's a whole fabric built together, um, consuming and using these, these capabilities? Is IVIP then something that really delivers additional value? Does it move up one level, or does it the same thing that ITDR was expected to do two years ago?

And the question that we have on the table for today's episode and catching up on what we did last time is, whether, and this, of course, is a bit provocative to say, could AI, the way we use it in IGA, for example, or in PAM, already make iVIP more or less obsolete faster than it ever becomes a mature category? Before we dig deeper, what's your gut reaction to that? Can AI already solve many of the questions that iVIP tried to answer?

AI, at least, is very... impactful on the way iWeb solutions are and should be delivered.

So the promise of iWeb only will become a sort of reality, only will hold when the potential of AI is used.

I think that is at the minimum my gut reaction.

Provocatively, we clearly could say we can't do so many things with AI that we don't need.

But that would mean we are doing a lot of own construction work.

We are talking about tools, about building instead of solutions.

The question is, where will they be then? And Do we actually care if it's ITDR, if it's IVIP, if it's IGA, when it's a whole fabric built together, consuming and using these capabilities? Is IVIP then something that really delivers additional value? Does it move up one level or does it the same thing that ITDR was expected to do two years ago? So

Does it have to be focused on identities alone, or should we actually think defense in depth like we've talked about for probably at least twenty years?

There's a couple of things on that.

First, the probability of Anthropic, OpenAI or someone else failing and keep the tiger contained, that is relatively low.

On the other hand, there are probably thousands, hundreds of thousands of people that are permanently releasing tigers to the street, all the attackers.

So, so we have a tiger problem in that sense.

If you, if you, if you want to, to, to stick to this analogy.

We need to be careful because at some time, these analogies, if you go too far, they, they become weird.

But Martin, you wanted to comment, comment on, on Alexey.

So while we might kind of talk a lot about how we should have prevented that, most of our listeners will probably be interested here in the other end of the story, right? How do they defend from those escaping tigers if something like that happens on their street? Does it have to be focused on identities alone, or should we actually think defense in depth, like we've talked about for probably at least 20 years?

There's a couple of things in that.

First, the probability of anthropic opening eye or someone else failing and keep the tiger contained, that is relatively low.

On the other hand, there are probably thousands, hundreds of thousands of people that are permanently releasing tigers to the street, all the attackers.

So we have a tiger problem in that sense.

If you want to stick to this analogy, you need to be careful because at some time, these analogies, if you go too far, they become weird.

I had this once with slicing the elephant, and then at some point, you better stop with the analogy, at least when you end up with the inner parts, describing the inner parts of the elephant or something like that.

But Martin, you wanted to comment on

we can see when we are working with our customers.

But I think it's important that this always goes from capabilities to services to tools.

And this is, I think, really like we discussed in the initial episode, central to the paradigm, the idea of the identity fabric, that we don't start with like it's frequently done with tools first.

Tools are the result.

And tools also follow the service and services follow the capability needs and capability needs are derived from, you call it a challenge, from the requirements.

And this is, I think, the really essential aspect that it helps making, at the end of the day, better decisions.

That it helps to take a structured approach and not a tool-driven approach.

And that also shows how many teams and how many tools are part of this end-to-end process or journey, especially when we are talking about the recent developments.

what we can see when we are working with our customers.

But I think it's important that this always goes from capabilities to services to tools.

And this is, I think, really like we discussed in the initial episode, central to the paradigm, the idea of the identity fabric, that we don't start with like it's frequently done with tools first.

Tools are the result.

And tools also follow the service and services follow the capability needs and the capability needs are derived from, you call it a challenge, from the requirements.

And this is, I think, the really essential aspect that it helps making, at the end of the day, better decisions.

that it helps to take a structured approach and not a tool-driven approach.

And that also shows how many teams and how many tools are part of this end-to-end process or journey, especially when we are talking about the recent developments.

So the dissolving of the traditional security perimeter also asked for something new, right?

That's true.

So then you ended up with an on-prem IGA solution and prem identity management.

And then the IDAS space appeared, so identity as a service, which at the beginning, I think, especially from vendor marketing, was pushed as something entirely new, which basically was just different deployment model.

And clearly sometimes with some interesting innovation, but at the end, it was mainly about a deployment model.

But again, sometimes you doubled, so to speak, the number of tools that way.

And again, too many tools don't help, especially if it's not exactly clear why specifically you need all these different tools.

This is the core of the series to apply this notion again, because it's valid.

When you look back at 2019, what was happening in IT and business around that time in 2019 when the fabric concept emerged, when you and I worked on that to make the old siloed approach to identity untenable?

Yeah.

So when you look back then, it was the time of still a lot of traditional workforce identity management.

So the traditional identity management we know.

But there was more and more consumer identity management emerging.

And there were some first vendors around B2B identity management solutions.

So looking at more the partners, the supply chain.

Yes, and I think that it's

And probably out of most IAM leaders' hands, maybe by explainability, just make sure that you don't forget that, make sure that your system's not making decisions that you can't explain to a judge.

yeah so so i think two two two huge and super fascinating areas so on the governance side i think banks clearly are a bit of a special kind of beast in the sense of they have the the biggest audit pressure they also have the most mature usually the most mature governance approaches and risk controls etc so I also hear it from European CSOs and leaders that they say, okay, we are relatively restrictive.

We run our own instances of certain models in a controlled manner, and you're only allowed to use these.

So being very restrictive, I think there's always a risk of still things going wrong and someone bypassing it.

I think this risk must not be underestimated, but I think that makes sense in such an environment.

On the other hand, we clearly have in many, many areas the situation of how can we move fast, how can the business evolve fast, how can we use it for whatever, improving our speed and development of solutions and whatever else, optimize business process, et cetera.

And still, I think it's important to understand, and this goes all the way back to discovery, what do we have, what may this be allowed to do, and how do we contain stuff how do we keep it under control i'm for instance wasn't and that goes into safety i'm not a big fr friend of the year a lot of people then saying oh we need this ancient kill switch the kill switch is always is the last result um because you don't know necessarily whether this is a super important agent for the function of the business.

And I'm wondering, do you think, how far into the future are we talking about humanoid robots and the impact of humanoid robots in identity? Have you any thoughts on this? I mean, is this something that, because you're like a futurist, I'm thinking this ought to be something you've thought about.