So, my name is Michael Doujak. I'm one of the product managers working for Ergon Informatik.
So, just a little bit of explanation, I'm being transparent here. Ergon Informatik is the company, Airlock is the product.
Okay, we seem to have a little bit of a problem with the sound quality, at least on my side. For you, it's okay?
Okay, good. As I said, Ergon is the company, Airlock is the product. I'm product manager for Airlock Identity and Access Management System and I'm going to make a promise to you. This is not going to devolve into a product presentation or something like that. I'm going to talk about a problem that we're facing today. You have seen this slide. This is what we do, where we are. You can read that for yourself.
So, let's delve into the subject at hand. We find in our work as a provider of an identity and access management system that we have an identity explosion. We started out with humans about 20, 30 years ago. We did IAM at that time. Then there were machine identities. We were exposing REST APIs and business-to-business communication started. And in the last one, two years, there's more and more agents joining the whole thing and they want to access things as well.
Yesterday, I heard a presentation. The keynote speaker said that there is a company, 40,000 people out there. They already have 25,000 agents deployed, active. They're doing things. And they're expecting that within 12 months, they will reach parity.
So, they'll have the same amount of people as they have agents. And the way he phrased it, he was actually expecting those agents to act on their own, not to be under any supervision. They have their own credentials or their own identity. Even worse, they don't have an identity.
He said, hey, it's a compliance nightmare because when you look at the logs, you don't see what actually those agents are doing because you don't know who those agents are. So, that's kind of the identity explosion. And when I look at our customers, what they actually start doing is to manage that, they start delegating trust. They're giving away trust. They're saying, here on the left-hand side, let's see. Here on the left-hand side, these are the companies, the partners that we have.
They just believe that this supplier there, he has his IAM under control, his employees, they can access our systems directly, systems are here on the right-hand side, without any further ado. So, basically, what they're doing is they're losing control.
Now, let's look a little bit into more detail. Here on the left-hand side, we just have a couple of sources of identities. Here on the right-hand side is a depiction of our infrastructure, the company that we're representing.
Now, who of you is actually using Teams or Outlook or Word or PowerPoint or Excel? Please raise your hand. All of you that raised your hand must have at least two identities here on the right-hand side because there's no way without an intra-ID how you're going to use the M365 products from Microsoft.
So, you probably have your own IAM system and another one. So, what it really boils down to is that every back-end application here is seeing all those different identities and somehow they need to deal with that.
And that's a nightmare because when you're looking at this web application up here, and we're just delving a little bit into the details, what you actually would expect there to happen if you want to be secure is you have your business logic of the web application, you have some sort of policy enforcement point that protects that web application, and it is able to deal with all those different identities.
That's a trick you have to teach that thing here, and it may have inside a policy decision point helping it to decide on whether an identity that's coming in is actually acceptable, and that should be ruled by a policy that helps you control that. Now, scale that up. This type of architecture is for one single web service that you're exposing. If you have a certain size, then you probably have 100, maybe a couple hundred, maybe even more than 1,000 of these web services, and you're going to do that policy enforcement, policy decision, and policies distributed all over your network?
I don't think so. This is a nightmare, and you really have to ask yourself the question, how can we retain control when we want to delegate trust because we don't want to do everything ourselves?
Now, just one little secret. It was a talk I held about one year ago. I talked to some guy there, and he said, well, we'll still have our IAM control internally actually for each supplier, and this was in the car manufacturing industry. He said every supplier, their identities, we control them in our IAM system.
I don't know how many people they have working on that IAM system, but if we're talking car manufacturing in Germany, then there is hundreds or thousands of suppliers that such a car manufacturer has, and the size of the team just to manage all those identities, not only to onboard them, but to offboard them at the right point in time must be a nightmare. So what you want to do to get control back is you actually want to centralize decision and distribute enforcement. So let me animate that a little bit for you on what that could look like.
So we have this policeman, policy enforcement, in front of every service that we're exposing, and we have a policy decision point, probably very closely related to an identity and access management system, and the identities that are coming in are still the same that we had before. Now, we don't stop there. There is just a tiny little RFC out there. It's in the OR standards 8693, and it's called token exchange, and that's really something that I recommend that you look up because it is an interesting read.
Token exchange can solve quite a few problems that we're having in this area, not only for agentic AI moving through your networks, but also for human problems that we already have since a couple of years. So if we're looking at the token exchange and what it does help us with, then we'll find it's really a technology enabler. It allows us to decouple identity from trust decisions. What do I mean with that?
Well, what does token exchange actually do? You come with your Microsoft Entra ID token. You pass it through token exchange and say, hey, turn it into something that I can use internally. So you're going from the colorful token to something that is green, and it's your token. You just map all the claims and fields and everything. If an agentic AI comes in, you can do the same thing. If it's a supplier that comes in with their identity, you do the same thing. So you're decoupling identity provisioning.
You leave that distributed where it is right now, but the trust decisions, you take them internally. The next thing you gain with that is you normalize those tokens. So instead of having your policy enforcement point able to deal with Entra IDs with agents and so forth, they always have to only deal with one type of token. Maybe two or three depends on the complexity of your environment. But it boils down to very few types of tokens, and you have a very consistent internal model because the policies you apply in the policy enforcement, that's where you have to scale out.
Policy enforcement happens with every service. It will be very easy to achieve. What you also can do, and that's where it really gets interesting, is you can do delegation and impersonation with token exchange. What do I mean by that? Delegation, let's assume we're talking about an agent.
An agent, in my opinion, should never be able to do anything without itself having an identity. An identity authorized by an identity provider. For example, you do a client credentials grant, the agent gets itself an identity, and then it can try to access something.
Now, agents normally don't do the work all by themselves. They always do it on behalf of some user. If it's the head of accounting or some simple accountant, there's probably different rules applying to those within the accounting system. And I think agents that work for the head of accounting should have more rights than agents working for a simple accountant. That's exactly what token exchange will allow us to implement. You can take this agent and force it to go through an authorization code flow, getting an access token for the human he's going to represent.
And then using token exchange, you merge those two tokens. So the subject of the token will actually be the human. The accounting system will see the human person. It will be able to decide it's the head of accounting. Bills up to 100 million euros is okay, no problem. He's the head of accounting, he can pay those. Or it's a simple accountant, bills above 10,000 euros, forget it. You are not authorized to approve those. And that's exactly what you can do by merging it. And the agent will still be in the token, but it will be an actor. It will not be the subject.
The bookkeeping system may even ignore that. The only thing you have to do at some point is you actually have to have logging where both identities are written to the logs, so you have an audit rate. And you can say, oh, at this point in time, there was an agent, actor, acting on behalf of a subject, your accountant, and that is the type of information you want there. That's delegation in an example with an agentic AI. The same example could be made for a service desk.
You have a service desk, and once customers need a little bit more complicated products, they're allowed to call you and say, hey, I need this and this. Please do it for me. So that service desk employee can actually go in and say, hey, I'm going to impersonate this customer of ours. With the impersonation token, you get the same thing. Token exchange, the service desk person goes in, he says, I need a token to represent this customer.
The customer is the subject, the service desk agent is the actor, and whatever the backend system is, it's going to actually approve it and say, yes, this is a token that is valid, and I know that it's a service desk employee acting on behalf of my customer. The service desk employee can handle the difficult transaction. Going one step further, and it's another thing that token exchange can do for you, is you can take advantage of a segregation of security zones.
It's my recommendation that when you're thinking about security zones, maybe you have a frontend service zone and a backend service zone, you use different identities in those two zones, and the transfer from one zone into the other is only possible if you first go through the token exchange, and actually the frontend service exchanges the token to get to the backend service. Why is that an advantage? Think about stealing a token from the frontend zone. There's no way how this is going to be valid in the backend zone.
If the frontend zone is kind of sales, where you have your web services acting to the outside world, the backend service is where the real money is, credit card transaction, things like that, this segregation helps you protect your business services from attack. Because the only way how the exchange of tokens will work is to go to the token exchange server, you have to authenticate there, the service that does it has to authenticate, and the attacker has difficulty actually attacking this type of situation.
So this is what token exchange can do for you, and I strongly recommend you think about it, because you reap a plethora of benefits. Onboarding. I told you about the token exchange server where the policies reside, policy enforcement is distributed. For onboarding, the only thing you need to change is the token exchange service itself. You have a new source of identity, you configure it into that system, and you're done. You can do that in days, trust me.
Getting the contracts into place for the new supplier and things like that, agreeing all these details, that's probably still going to take months, but the implementation on the technical side is going to be easy. You have consistent security, because the policy enforcement points don't need to be that intelligent, they don't need to be able to deal with different type of tokens or different type of identity sources. You have everything consistent, and you have one central point where you make your decisions.
This also allows you to lower the complexity overall, because at scale it isn't really that complicated. The centralized service will take it, and there is much less cost involved. And at the end of the day, you have full visibility and control over everything, because you have a centralized position where you manage your identities, and you can control and audit everything there, because every change of tokens, every change of identities is going through that system. Moving forward, I recommend the following action plan.
You have to adopt this central trust model, otherwise my recommendation won't work. You have to implement token exchange and decentralized policy decisions. There's a team you probably have to build if you don't have it already in-house.
Of course, most of the products that are capable of supporting OAuth and OpenID Connect already have a token exchange server. Maybe you just need to enable it, maybe you need to license it. You should talk to your IAM vendor. The second step is that you start with a high-impact use case, just one. There's no need to do a big bang change to implement this all at once. You start with one use case. If it works, then you move on to the next, and to the next, and to the next.
The nice thing about this proposal is that you really can scale out to your end services and just do first the one where you have the most impact, where you have the most cost savings, or where you have the most pressing security problems. As I said, I promise this is not going to be a product demonstration or a product sales. If you still want to talk to me or to my colleagues, please come to our booth. We're in the ground floor. That's it from my side.
I hope I was able to introduce you to something that you may or may not have known yet, but token exchange is really something out there that can help you. Thank you very much. Thank you very much, Michael. It was indeed a very interesting, almost technical deep dive into how you can actually achieve the things we were discussing on the highest strategic level for quite a few years already. We actually surprisingly have time for one or two questions.
So, if anybody... Okay.
Hey, I'm wondering how the token exchange worked together with ITDR. Because for ITDR, wouldn't that look like a totally different behavior on the same token all of a sudden? And should it involve measures to counteract? That's an interesting question.
To me, tokens are scoped for certain zones. So, if you're starting to exchange those tokens, then they should actually be recognized by the ITDR system because within their context, they are valid tokens. And I would expect ITDR to actually pick up or learn that this exchanging of tokens is something normal in your network. Wouldn't you? I'm not too deep into ITDR, to be honest, but I would expect this to be the logical conclusion for an ITDR system to work correctly. Okay.
Well, thank you. Anybody else? And I have to remind our online viewers as well that you can still submit questions. Probably not for this session, but be prepared for the next one.
Well, thank you very much, Michael. Much appreciated.
