So, hello. What I would like to start, maybe we'll start with a quick self-introduction, so if everybody can quickly say your name again and then one sentence about the topic, and then we will start with the first question. All right. Yash Prakash, co-founder of Reva. Very interested in what's happening around dynamic authorization, intent-based access control, and how you can bring policy-based access as well as signals to sort of make it much more dynamic in the agentic era that we are entering now. Alex Olivier, co-founder of Cerbos, and also the chair of the OpenID AuthZen Working Group.
This whole topic is something that we have to move to as an industry as we now move to a world where we have identities, be it agent or otherwise, working at machine speed, and we need to be able to keep up from an architecture perspective. Thomas Mayfield, I'm head of Decentralized Trusts at the Cardano Foundation. I'm also the founding CEO of a company called Viridian, spun out of the foundation. My perspective here is slightly different than my fellow colleagues.
I believe everything that they've mentioned about policy and risk mitigation is absolutely important, but my positioning here is the identifiers that they are actually bound to, that those policies actually bind to, are also extremely significant, and that ultimately underlays the real value of those policies and risks. Can I ask the technicians in the background to start the counter here?
Otherwise, I'll lose time. Thank you very much. So maybe first question to set the baseline to yours. So identities traditionally have been driven by predefined roles and static policies. What has fundamentally changed in enterprise environments that now requires continuous signal-informed decisions instead?
Yeah, I think great question, Rainer. So when we look at how things have evolved, right, so when we look at enterprises primarily dealing with workforce identities where the people who would come in with a certain role set, you could have managed with assigning roles which would not change over a period of time.
Yes, there would be joiner, mover, lever processes that you would build, but that is first of all flawed in terms of achieving the zero-trust principles that you would be predefining and pre-assigning access. We would want to move away from it just to also meet the zero-trust and zero-standing privileges standpoint. But also when you look at how we are evolving towards a lot more non-human as well as agentic identities, it becomes critical that we don't assign static permissions, which basically means, especially in the agentic era, the agents need to have a lot more permissions, right?
Most of them becoming over-permissive in nature. So you need to, first of all, in order to move away from that, you need to look at how we can bring dynamic policy-based access, right? How do we not assign permissions at the time of creating an agent or generating and registering an agent, right? So you have to assign that access dynamically based on the task or the goal that agent is performing. So I think it is time that we move away from the static role-based provisioning that we have been doing to a more dynamic policy-based access control. Great.
So maybe, Alex, maybe you want to comment a little bit on how does that then look like, this emerging ecosystem for security signals, real-time risk evaluation, and policy-based authorization? How does that work? Maybe educate us a little bit.
Yeah, so if we look at how we've been managing this for humans and employees and kind of building on that point, if you look at your typical IGA process, so a new employee is registered in your HR system, that triggers off a series of workflows inside of some IGA tools, for example, and these are new identities which hopefully are going to be inside of the business for months, if not years, and you can maybe wait for 6, 12, 24 hours for their roles and such to be provisioned across the ecosystem.
If we now look at what's going on in this very dynamic world of not necessarily just agents, but more very ephemeral workloads, if we go pre-AI, which feels like ages ago now, you might have batch jobs, you might have analytics workloads, you might have data processing steps. These are workloads, these are ultimately identities that will spin up for some period of time. They need to get permissions to do something, and then they die, and you kind of move on with your life.
You can't wait for a 6, 12, 24-hour IGA-style process to set up those identities and then set up their permissions and roles. So if you look at what's happening across the standards ecosystem, which I look at it from the authorization perspective, but more broadly, we now have these mechanisms that are being standardized. You look at things like shared signals and cape and risk events, which is a way for other components inside of your enterprise architecture to send signals that this new identity exists or needs to be revoked or it needs to be updated in some shape or form.
This session's expired, et cetera. That then tying into a very dynamic policy evaluation, where those signals feed into the evaluation checks that are done when a workload, be it an agent or otherwise, or a human, tries to do some things inside of the system. It's that source and it's that drive for that real-time context which then drives, ultimately, the policy and the real-time decisioning that needs to happen so you're not waiting on that static role that might take six hours to turn up and then disappear again. We're at this point where we have these underlying components.
You look at what's going with OAuth and AuthFederation, AuthZen, for the way to talk to a real-time decision from a decision point, share signals as a way of delivering those messages. We're now getting to the point where we have all these building blocks where we can actually build this very reactive, signal-driven, dynamic environment which is going to become more and more necessary as more of our work as enterprises shifts to this very dynamic workflow and agents ultimately doing things and need to be able to control their intent. Okay.
Yes, thank you very much. I was asking myself, so it's now a long-running session and all those kind of agent loops. As soon as you don't decide the authorization at the beginning of the login process anymore and you have to stretch that over time, so where do you guys think that a decision at once at the login stops holding and how are teams catching up today, if at all?
I mean, writing all those policies in the end, that might be quite difficult if you can't predict how things are going on and what agents are going to do there. I'm not sure if Thomas or maybe Yash want to answer on that.
Well, policy is your domain, so I'm going to pass to you, Yash, and then maybe I'll compliment. So when we look at how, again, things have evolved, so earlier when we used to have humans logging in, we could potentially have assigned access permissions that were driven through role-based, attribute-based. We could have evaluated that and put that as part of your session.
Now that session would hold or the user would hold all the permissions that they could have to perform any task in any application, but that is changing because first and foremost from an agentic standpoint, the access that the agent should have has to be very, very precisely scoped, right? So you have a task for booking a travel or a tour plan that you have, so the scope has to be very, very narrowed down, and that cannot happen when you are just basing it on the login, right? So you don't know the intent. You don't know the action that that particular agent is going to perform.
So you cannot just rely on essentially assigning the permissions at the time of login. So what we are moving towards is more of an action-based permissions that you need to assign. So every hop that an agent is making or the agent is calling another agent or an MCP server or tool, at every hop you need to now start looking at how do I reduce the scope, how do I assign the right set of permissions before that invocation can happen, right? So that's where we are moving towards both the declarative policies, which are deterministic in nature, right? So we work with AWS on CDER.
We have OPA as well where it provides us the framework for building and offering declarative policies, which are deterministic in nature. The second is applying the non-deterministic or probabilistic way of identifying the intent. You probably have heard through the sessions of how intent is becoming important. It is going to become critical because you need to capture what the action is and based on that apply various algorithms to identify the drift as well as assign the right set of permission before the action can be taken.
So, yes, we are moving away from a login-based session credentials as well as permissions assigned to that session to a more action-specific permissions that get assigned in real time. Okay, so interesting.
So maybe, Thomas, you already said you might have a different view on this topic and my question would be then if identity policy and signal orchestration, where do you see the biggest maturity gap today? And is there a foundational area that you think gets overlooked?
Well, the foundation is verifiable identity. The thing that is required until you get to these steps where you have the ability to activate policies to do authorization. If your authorization effectively results in an OAuth token being issued, then that becomes the identity, that becomes the authority, and you have to trust the issuer of that. And that's your single point of failure. That's your attack vector. And what we are looking at really is verifiable identity that one can survive compromise attacks where the actual human role isn't what's required for the agentic AI.
What we have for humans isn't good enough for agents. Agents need delegated authority. We need to know who commissioned these agents, who gave them the authority to actually act. And that's a completely different paradigm shift in the identity that is required for those agents. It needs to be long-lived. It needs to have a cryptographic chain of proof of what it's actually done. And it also needs to be ready to address the threat model, which is that. It's compromise recovery. Assume that the agent is going to be compromised. How do you revoke it? And to my colleague's point, in real time.
We can't wait. We can't even wait for five minutes. It has to happen real time. And then finally, the quantum resistance element.
I mean, everything that we've discussed here today, these are all budget items on the majority of these companies' budget sheets in this conference. But the reality here is that you need to have a quantum strategy. And you can leverage that using the protocols we're building on at Veridian, which is Cary and ACDC. And I'll delve a bit into that in the presentation that follows this afterwards. But that would be my point there. It's really about that verifiable identity.
It must be owned by the organization, linked to the legal entity registration, and have the ability to delegate authority through a cryptographic chain. And not just single OAuth credentials that can be picked up, cloned, and copied. That's my perspective. Okay. So I had one other question in mind. Because I was thinking, you were thinking about policies who define or which define actions for agents. So I would say the identity of the agent is then important. We are asking, what is this agent allowed to do? And you were then more talking, okay, who authorized that?
And you're bringing in the user identity as a context, correct? And I'm asking myself now, I mean, are you overseeing something here? If you just say, okay, these actions are allowed for this agent, how do you know if the user context is actually allowed to see the data which is retrieved in there? I don't know who wants to answer that question. But that came to my mind when listening. So I think there's a very common view, and I think there's a contrarian view to this, which is an agent, if it's acting on behalf of a human, a user, should have an attenuated set of permissions of that user.
So I'm Alex. I want to spin up an agent to go and fix my calendar because it's always a nightmare. I don't want to give it my Google token which can do everything. It needs to be a scoped-down version that can only go and view and maybe edit but never delete my calendar entries. It should never go in my email or anything like that. And I think that is a pretty good mental model. But the contrarian version of that is there's also a model where, imagine you're a global business, which many of us are. You have a team sitting in the U.S.
who need to go and pull together some report based on global sales data. Well, based on all the data restrictions we have and the privacy compliance we have, I might go and instruct my agent to go and do it, and that will go and talk to an agent that's sitting in Europe. One's sitting in Asia, one's sitting in Australia. And those agents will maybe have privileged access to data inside of that region, but me as someone sitting in the U.S., doesn't have access to it.
So actually in that case, the agent that's doing a task for me in this other trust domain essentially has more permissions than I do, and so I think there's still a lot of work we need to do from how we rationalize and think about that delegation chain, because it's not always an attenuation, I don't think. I think that's the happy path right now. But there's also these other models which flows into identity and how you can verify the credentials across that flow flows into intent, and you need a different type of identity for that other intent.
And this stuff is so new, and these use cases are only popping up every week, and there's about six different RFCs every week about ways to do agent identity and missions and planning. So we as a group of identity professionals need to go and figure out these use cases and run them down, because I think there's potentially a chance that we need to rethink some of the more foundational assumptions that have gone into agent identity. If I could just add a little bit more context and complexity.
So in that scenario, Alex is absolutely right, but we're still only talking about verification and data transfer within the same organization. How do you do this now across organizations? Our work nowadays is... You're asking too difficult questions, sorry. ...is across organizations. So that underlying foundational identity then also has to be verifiable by outside the walls of your business, by your organization, your domain.
So, again, it gets even harder than that. But, no, it's definitely fundamental problems that need to be solved. But that's just my additional thoughts on that.
Okay, great. So, I mean, now let's do the traditional elevator pitch maybe. So a final statement from your side. So if there's a security or platform leader in this room now here and he can only find one thing within the next 12 months to prepare for a signal of authorization, what's that signal's highest leverage or advice from your side what you would give to them? I don't know, Josh, if you want to start.
Yeah, I think start off by looking at policy as code, which is one of the foundational things that you would need to move in that direction. Identify use cases that you need to address because obviously agent AI is coming in thick and fast. Your business is asking you to move as quickly as possible to secure those agentic workloads. So prioritize that. You also have transformation that your organization might be doing.
So, again, look at applications that would fall in that bracket and see if you can, again, start consuming policy as code, as foundational building block for authorization. Signals can come from everywhere, right? So start looking at which systems are going to provide you with the right set of signals. It could come from your identity provider. It could come from endpoint network. So start using standards like Alex mentioned. So CAPE and SSF provide the foundational building blocks for bringing in those signals.
And most importantly, use policies in conjunction with these signals to make the right dynamic and continuous decisions. Alex?
Yeah, so completely agree. We need to get to a policy as code approach. There's a prerequisite step I'd say in there is the first thing is start looking across your enterprise. Start identifying who are the product owners, the domain owners that understand what the systems are, what the capabilities, the actions that can be done inside of those systems, and start building that database.
It might just be a spreadsheet to start, but you need to start assigning ultimately owners and who's responsible for each of the capabilities and actions across your systems because ultimately they're the things you're going to build policy around. And a lot of the work is just going to do the legwork across your business and understand, okay, what those capabilities are because the moment you let an agent loosen that environment, they're going to go and try every single one of those until they can achieve its goal.
And just an additional point on go to your vendors, go to your suppliers, and encourage and ask and ultimately demand standards adoption because that's the only way we're going to be able to scale this out broadly across the industry. I couldn't agree more with my colleagues here. I think my perspective here would be if you are spending money on authorization with a service provider or building yourself, ask your architect team or ask that supervisor who is providing it to you, what is the identity that's underneath it? What exactly is this authorization built on? What is the foundation?
Because the next decade, that's where the risk is going to be. It's going to be on the identity piece that all of these systems are being built on, which was designed for closed systems that we are now trying to use as open loop systems. That would be my positioning. Okay. Thank you very much. So I think then we finished on time. Unfortunately, I think not too much time for questions anymore. So I would say thank you very much for joining us here and giving us all this insight and learnings. Thank you very much. Thank you.
