So good morning and warm welcome also from my side. Thanks for the introduction and also thanks to the Coding on Coal 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 asks 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, 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 contents, so my confirmation to proceed there. 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, okay, please do that on behalf of me. Consents mean we have booking services, whatever, different flight portals and all, where I'm just a user, and I give access to the agent, to access whatever, Bunkingcom, 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 a flight, or the agent has selected a flight, and then there comes a 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, 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 this 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, mTLS, 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 AI 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. We have OAuth 2.1 PKC, I would say that's active. If there's an EAM player who's not supporting that, maybe he shouldn't name himself EAM player. We have the two RFCs, which are just online 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 work identity for non-human actors, for example, emerging. And we have the AI agent OAuth, which is emerging. And in that aspect, using this work identity standard and the new standard, also downlisted for delegation, identity delegation chains and so forth. And we have OAuth 10 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, ERM 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. And we have developed a maturity model to figure out how agent ready an IAM 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 IAM, 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. Consent is quite important because maturity none is implicit.
So we say, okay, I trust the agent. It can do anything. That's maturity none. If we have a consent 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 consent on resource, it's better. But we basically need a granular, scoped, fine-grained consent. 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, blacked in. And as outlined, we now need vault services. So if you have secrets in code or environment variables, that's maturity none. If you already have a centralized secrets manager, it's better. So we come to a basic level. But if you come to auto-rotation, short-lived secrets, we are better, or short-lived tokens.
The age-ready state is where we have zero standing privileges and secret authentication in place. And finally, the audit and control topic. Application locks, I have the discussion quite often. Application locks 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 age-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. 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? And 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 Glavik 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 OAuth 2.1 for MCP. With the granular consent in line with the PSD2 requirements. We have the live location for the human in the loop. With client-initiated back-channel authentication as one example.
So we can really challenge the topics that we have just outlined here. It becomes interesting when we plug in Glavik. 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 life cycle. So we have this MTLS which is one of the authentication topics here. Where we have auto 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 life cycle.
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 agent 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, NIST 2, DORA requirements.
But we also know the lessons from PSD 2 for content and other things what are in place. We have no US cloud login. So we don't use the US hyperscalers.
Of course, that means all your data, all your actions are under European jurisdiction. And finally, as outlined, we have the European EIM 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 EIM 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 are 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 EIM 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 EIM 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.
