So, good morning and warm welcome also from my side. Thanks for the introduction and also thanks to the KuppingerCole team for bringing together, I would say, without a question, one of the best and leading IAM conferences in Europe. My name is Sadrick. I'm part of the cidaas management team. And as you can read with the title, I will talk about AI. In particular, since over the last decades, we have talked a lot about humans logging in workload identity. And then recently, there has been a fundamental change, which is AI.
And we need to consider how that affects identity and access management and us as a vendor today. Normally, I have a presentation where I have one side with like 10 years ago, today, and 10 years in the future. Since innovation is speeding up so fast, I needed to change it to yesterday, today, tomorrow. And the topic is about from chat to autonomous agents and what changed there and how that affects the identity space and how identity surface is expanding in that area. So yesterday, we had this chain AI chats. We all know them.
We started probably all of us with ChatGPT, maybe Gemini and all that. It was quite simple. I opened the ChatGPT, summarized the PDF for me. So user ask a question, AI gives an answer. It was already good, helping us a lot, but no system access was needed. So basically, to break it down, no identity was needed.
Obviously, yes, I need to log into my agent or to my chain AI chat, but that's it. So nothing changed to how it was in the past. A user authenticating, a user logging in.
Today, we are already in the stage where AI interacts with tools. So we all know the MTP protocol, or most know that. So we give a task to the agent, for example, find all open invoices in my ERP and send reminder emails. In that aspect, I as a user give a task to the agent, and the agent calls APIs and tools on behalf of me. So basically, the agent needs tokens, API keys, whatever, to authenticate against the services, and the agent also needs the content, so my confirmation to proceed that.
That's quite important because that's part of the authorization now, and we have seen it in the past already with banks. We'll get deeper inside of that later. And finally, we have tomorrow, which is starting already today, the agent-to-agent networks. So we have an agent delegating a task to another agent, to another agent. For example, I have a central agent, give the task, please onboard Anna. Then the central agent delegates to an HR agent, the HR agent to a compensation agent, to add the payroll, maybe to an agent for service accounts, maybe to an agent for something else.
So we have a chain of different agents interacting, and that also leads to an identity chain across the systems. And then the question arises, who is accountable? To make it a concrete example, we are in Berlin, so book me the cheapest flight to Berlin next Thursday. I have the user authenticating, that's the part we have solved already today, so that's the human logging in. Then we have the human giving the task or the intent to the AI agent. That's already part of the authorization. Then we have the consent, and as outlined, it's granting access.
So that's already where we say, OK, please do that on behalf of me. Consents mean we have booking services, whatever, different flight portals and all, where I'm registered as a user, and I give access to the agent, to access whatever, directly the airlines, directly to book the flight. So I have four, five, six different tools connected, and I give the consent for each of the booking services. Important here is, what consents do I give? Do I give to book the flight?
Maybe there's a cheaper flight available if I upgrade my membership tier, so do I also allow the agent to upgrade membership tiers in that aspect? And finally, I have selected the flight, or the agent has selected the flight, and then there comes the step-up authentication, because the agent shouldn't book it by himself, but it should intercept and stop and ask me for confirmation. So we have this human-in-a-loop topic. So basically, we have four different main questions. Who is acting? Is it the user, the agent, is it both? And who traces the delegation chain in that aspect?
What was consented? So the topic that we just discussed. Did I discuss or did I consent the booking services? Did I consent the upgrade of a membership tier? And to give already a short answer to that, we'll have a deeper insight of that one later, because we already have solved topics like that with PSD2, or banks have solved that in the past. And who authorizes the payments or this human-in-a-loop topic, in particular for high-risk actions? And finally, where are the credentials? So that's an important topic. We have four, five, six different connected services.
So we need to save the API keys, the tokens for these services somewhere. And it should not be in the agent memory or in the code. So we need vault capabilities. To break it down for the identity interface, we currently have two major protocols in that aspect. We have the MCP protocol, agent-to-tool, and we have the agent-to-agent protocol.
MCP, there's already developing going on there. A good thing is, as an ERM player who already relies on OAuth 2.1, it's easy. So we have OAuth 2.1, we have the PKCE flow as a foundation. We have MCP server, who's acting as a resource server in the OAuth 2.0 context. We have two additional standards, maybe protect resource metadata and resource indicators. So one for the audience binding, the second one, for example. And we have topics like dynamic line registration, so that we can easily and dynamically register the clients, the agents, the MCPs.
And in that aspect, also one more standard emerging. And we have to step up authentication for this payment process, what we have seen, for example. In the agent-to-agent, a little bit more is happening. So currently, developments around these agent cards are happening, because I need this discovery and this authentication, also in some kind of metadata available to other agents, to other services requesting them. But we also have things like the OAuth 2.0 API keys, MPLS, for the authentication between the agents, and some stateful task lifecycle management. So quite a things to do there still.
But to map that a little to the base, as outlined, as an EIN player, if I'm already OAuth 2.1 compliant, I have the base layer already established. But standard bodies are actively working to expand that. And I've shortly listed a current state that will be probably not the final state, because things are moving quite fast. With OAuth 2.1 PKC, I would say that's active. If there's an EIN player who's not supporting that, maybe he shouldn't name himself EIN player. We have the two RFCs, which are just outlined for discovery and audience token binding.
Also, that is published in the market out there. We have topics like demonstrating proof of possession, which is quite important, because that prevents token theft. We have the center constraint tokens with the private keys, so the agent can authenticate that this is probably a token to use. Also published, also out in the market, for some part of the FAPI standard. We have the boost authorization request for secure perm handling, also that is available.
Now we come to topics which are emerging, in particular, in this agent network context where we have the workload identity for non-human actors, for example, emerging. And we have the AI agent auth, which is emerging. And in that aspect, using this workload identity standard and the new standard, also downlisted for delegation, identity delegation chains, and so forth. And we have auth then, as a standard for authorization, which we in CDAS also already implemented.
Thereby, a big thank you and shout out, kudos to Umbrella. They supported us and they also are an active member in the standard bodies here supporting that. And I'm highlighting that because that's really important that we also from Europe participate here and push these topics forward. But key insight, to summarize it up, EIM vendors that already speak OAuth 2.1, OpenID Connect, they have a head start. The challenge is now to extend that for these non-human agent topics which are emerging there. And we have developed a maturity model to figure out how agent-ready an EIM system is.
We have six dimensions for that, listed on the left side, and then the maturity state from non-basic standard to agent-ready. And one important thing, we'll start with the agent identity. I would say if an agent uses shared service accounts, the maturity is none. We can increase that each agent has its own separate API key. We are in a basic level, but that's not far away from agent-ready. Agents are users in a directory. That's better, but it's not agent-ready because we are breaking the consent and the audit handling here and mix it up with users.
So we really need first-class identity in our IEM, including lifecycle. So including a sponsor who is responsible for that, including attestation processes and more. In the authentication, we have the same process. We have static API keys, which is, to be fair, maturity none. Then we have OAuth 2.0 client credentials, it's already better, we are in a basic level with OAuth 2.1 PKCE, we are in a standardized way already active.
And then finally, if we have also the agent-to-agent protocols established and things like step-up authentication, then we come to the area where we are in the agent-ready state. That is quite important because maturity none is implicit.
So we say, OK, I trust the agent, it can do anything. That's maturity none. If we have a constant per application, so we all know that from SaaS applications, we see, is this service allowed to access your application?
Yes, no. That's already better, but it's still not perfect. If you have it on a resource level, so that we can really give that constant resource, it's better, but we basically need a granular, scoped, fine-grained constant. I'll come to that on the next page, because what have we learned from the PC2 lesson? Same for the authorization layer, we run through from role-based to attribute-to-policies.
Important is, since we're acting on machine speed here, that we really have the topic that each access, like in a zero trust, needs this fine-grained per API call or per process step, this authorization layer, plugged in. And as outlined, we now need vault services. So if you have secrets in code or environment variables, that's maturity none. If we already have a centralized secrets manager, it's better, so we come to a basic level. But if we come to auto-rotation, short-lived secrets, we are better, or short-lived tokens.
The agent-ready state is where we have zero standing privileges and secret authentication in place. And finally, the audit and control topic. Application logs, I have the discussion quite often, application logs are not sufficient for auditing. Basic is the seam ingestion, standardized is we have a per-action audit trail. And then finally, we need live revocation and human-in-the-loop for the control level to be really agent-ready. If you come to the consent lesson, what I just outlined, banks solved that granular consent with PC2 already, I would say, years ago.
Now we now need to solve it for the AI agent era, as the AMP layer. To make it in comparison, in the PC2 scenario, we have a bank account, we have a third party app for managing finances. I want to connect my bank accounts to that one, so I give the consent bank account A, I'll give re-transactions for bank account B, I'll give initiated payments, and whatever for a savings account, I don't give permission at all. That's really an easy example, but just to outline the current part of this granularity here. And I have this consent revocable, time-limited, and also auditable.
So what consent was given and when was it used? We now need to transfer the same pattern to the AI agent topic, where an agent acts on behalf of a user. We want not to connect a bank account, but different tools and services now. And then I have something like calendar read events and email sent on user's behalf. That's also an easy example. We probably need to have it more fine-grained, so inbox A I can read, inbox B I can send, or folder 1 I can read, folder B I can't read. And same here, it's revocable per scope and per tool.
And then we end up in a scenario where consent is not just a feature, it's really the bridge between the user intent and the agent authority. So it becomes really an authorization component. And banks use it already today. Is that third-party application allowed to access my bank account data or not? So it's part of the authorization. Now comes where we with CDAS step in. We have one platform ecosystem where we have basically the six buildings block involved. We have CDAS as identity and access control plane with identity, authentication, consent, and authorization.
We have KNIPS as orchestration and integration layer. And we have GLAWG as trust and secrets foundation, so with the wall secrets component and the audit and control component. To break that down and make it simple, we have the agent registry within CDAS. But basically we have this OS 2.1 for MCP with the concept in line with the PSD2 requirements. We have the live location for the human in the loop with client-initiated authentication as one example. So we can really challenge the topics that we have just outlined here. It becomes interesting when we plug in GLAWG.
There we have capabilities like the token vault. So we are able to centrally and encrypted store or two tokens, API keys, certificates with a full audit trail. So we'll see when they were accessed, how they were used. We have the certification lifecycle. So we have this MTLS, which is one of the authentication topics here, where we have all the rotation and all the things. We can always rework that. And we have encryption as a service that helps us because cryptography shouldn't be part of the app. It should be a central crypto policy which we use and can be accessed via APIs.
Important, no secrets in code, no standard privileges, no unmanaged keys, and the agent never holds secrets and tokens are minded, on-demand, per scope, short-lived. And finally, with KNIPS, we have then the agent orchestration integration layer. And that's because agents don't operate in an isolated way. We always need to wire them together in that scenario. So we have the AI-assisted flow design.
Basically, you can describe your flows in natural language and the flows are built up. And really important is this automated lifecycle.
So if an agent registers in this dynamic client processing or dynamic client registering, KNIPS gathers that trigger, starts the onboarding process, or triggers the onboarding, issues credentials to Klavik, maybe configures the scopes, configures the content templates which are required, then maybe informs the sponsor of the agent that there is a new age registering or new service registering for it to use that, and that fully automated and embedded natively in our ecosystem.
And then we have the real-time monitoring with all the live audit trails of every agent access action across all the systems and logging them to use that. What makes us outstanding? It's a European advantage. So we are a core European player. That means your agents can use any AI, but the identity and the access should be governed or must be governed in a sovereign way. That means in the easy part, we have the EU data residency. So all identity data, metadata, everything is hosted and processed in Germany or the European Union. We don't have a transatlantic data transfer in place.
We are regulatory ready. That means we have this GDPR topic and these two DORA requirements, but we also know the lessons from PSD2 for content and other things what are in place. We have no US cloud login, so we don't use the US hyperscalers. Because that means all your data, all your actions are on the European jurisdiction. And finally, as outlined, we have the European ecosystem with CDAS, KNIPS, GLAWG working hand in hand to provide a modern and complete European stack for all these capabilities.
That was just a short run through the capabilities what we just added to our platform, including the maturity model. What you can use now to figure out if your IAM vendor is ready for the agent era. If you want to learn more, we are downstairs at the booth. You can meet me and my colleagues anytime, discuss the topics with us, and we're happy to connect with you. Thanks for listening.
Thank you, Cedric. So, very interesting also, like we are EU-based or even German-based company. We have one question here. Should each agent have a separate identity in the IAM system? Is this maintainable, taking into account that we might have numerous agents spawning for a single mission? Maybe your thoughts on this. So clear answer, yes. Each agent needs to have its separate identity. If it's scalable or not, that's not a question. We need to have it. So the IAM vendors need to provide a solution that is scalable and that can be handled.
And you need to have this automated on-boarding, off-boarding of agents, the complete life cycle that needs to be part of this first class identities. Okay. Thanks a lot.
Again, applause for Cedric. Thank you.
