Thank you very much for the introduction. Really appreciate the attendance. Good morning, everybody. I'm guessing that most people here probably aren't the same people that attended the boat party last night, but who knows?
So, as it was mentioned in the introduction, my name is Alex Wilson. I've been in this space for approximately 16 years. I started my career at CyberArk. You may know them as Idera. It's a cheap shot, and I'm aware that we've also been acquired, so it's all in good jest. I then spent six years at PwC, where I led the advisory practice in the UK for privileged access management.
So, over that time, I've spent the majority of it advising clients on their roadmap, their strategy, and to implement their identity programs. And today, before I talk about identity, I want to talk about payments.
It's 2008, and somewhere inside a bank sits a fraud analyst, reading yesterday. Literally yesterday.
Overnight, her team's batch systems reconciled all of the card transactions from the day before, and this morning, those printouts sit on her desk. In those pages are the fraudulent transactions that the rules caught, and those that the rules missed. And by the time she finds them, the money has already moved. That was state-of-the-art. Authenticate the card.
Chip, pin, CVV, and trust the transaction. Catch the mistakes tomorrow. And what broke it wasn't a breach. It was volume. Card transactions had exploded, fraudsters started operating at machine speed, and it turned out the answer wasn't better authentication. The card was already authenticated. The gap sat between authentication and action. And that is where the money was moving.
So, the industry built a new layer. Real-time, contextual, every card transaction scored in under 100 milliseconds before the money moved.
Logged, attributable, replayable. It sat between authentication and action, and it became the control plane that nobody knew they needed until they had one. Everything I just described is about to happen to identity.
This time, it's us in the room holding those printouts. How did we get here? Ten years ago, the environments that we operated in were fundamentally different. They were static in nature. We had servers and databases that lived for years. We relied heavily on humans to manage and maintain that infrastructure and to deploy new applications. We coped with largely manual processes, and we invested heavily in defending the perimeter. Since then, everything has shifted. Our environments have become dynamic, cloud native, ephemeral, instances spinning up and down faster than any humans can track.
The balance of operations has shifted from humans to machines, with pipelines and workloads doing the heavy lifting that we were once responsible for. Automation has gone from being a nice-to-have to a necessity. To keep up with technical volume, but also to ensure that our businesses remained competitive. And of course, the perimeter has somewhat dissolved, and with it, that threat landscape has shifted. Ten years ago, attackers broke through the wall. Now that wall has gone, the play is to compromise identity itself.
Valid credentials, legitimate-looking service accounts, trusted supply chains. And we've seen significant supply chain attacks that worked precisely because compromised software had valid credentials. No firewall in the world was going to stop that. Regulations have also tightened. Not just in scope, but in specificity. We're no longer being asked, do you have controls?
Instead, we're being asked, show me the decision that led to this action. And the frameworks that we built and used ten years ago to manage identity and access, they're still in play today. That in itself isn't really the problem. They were well-designed for the world that they were built for. The problem is that we're now trying to extend them to cover our modern ways of working.
And that, I strongly suspect, is where the majority of us in this room are starting to run into the same challenges. Take role-based access control. Roles were originally built for people. People with jobs. Jobs with responsibilities. And those responsibilities that we could map onto permissions. Forgetting for one second that many of those roles end up over-permissioned, they do largely function as intended. They allow a user to do their job. Agents don't have jobs. They have context. And they act on that context at runtime.
We can't really write a role for something that hasn't decided what it's going to do yet. We then have just-in-time approval.
Actually, a really good way to start reducing those excessive permissions, providing there's a frictionless approach for users to request access on demand. But that expects a human at each end of the process. Somebody requests. Somebody reviews. And somebody approves. That works at human pace. It doesn't work when a pipeline needs access to production 40 times an hour. Or a workload spins up 1,000 ephemeral instances per minute. There's nobody at the other end of that ticket. So we stop asking and we start granting standing privileges because we can't make that real-time decision fast enough.
Then there's the assumption underneath all of this. That we actually know what's out there. Most of our governance models are built on cadence. We run a discovery. We scan for resources. We look for identities and accounts. We catalog them. We map access to them. We build policies. We certify the access. And we do this on a cycle. That's okay if your environment is relatively static. You can run a discovery on a Monday. It's still going to look roughly the same on a Friday. It's not great if you have a container that spins up, runs a workload, and disappears in 30 seconds. It was born.
It acted. And it was destroyed before we ever knew that it existed.
Obviously, it's very difficult to control access to something if we don't know it exists. It's also very difficult to discover something if it's already gone.
So, again, the frameworks aren't broken. They do the job that they were built for. The problem is we're now using them for a different job. And I'm sorry to say, and I'm sure you can see exactly where this is going, that job is about to get significantly harder.
Now, depending on the stats you read, 45 to 1 or much greater, non-human identities outnumber us significantly. And when you look at the frameworks we've just discussed, RBAC, JIT, the governance models, you name them, they were built when humans were the dominant identity class. 45 to 1 shows us that the world has flipped, but those frameworks haven't. And actually, it's not really the ratio that should concern us. That number counts for the non-human identities that we provisioned with a defined purpose, with known intent, that do predictable things.
Agentic AI changes the shape of the problem. An agent doesn't run a predefined command. It decides what to do based on context, and it chains those decisions together faster than any approval workflow can keep up with. Its intent isn't something we set when we provision it. It emerges at runtime. So how do we actually start really taking this forward? We have to go back and we have to challenge some of the core concepts within identity that we are all so familiar with that it's only natural to stop consciously challenging them. Myself included.
I think we're all guilty of just accepting the defaults at times, and we have to think about this more seriously. The first is the language. We've been calling this access management for the best part of 20 years. Access management is a term that bundles two distinct decisions. Authentication and authorization. Authentication is who are you? And this area has evolved significantly. I'm sure many of us in the room remember walking around with the RSA secure ID tokens.
Nowadays, we generally have passkeys, mobile authenticator apps, and things like conditional access. So the check at the door has actually become very smart. Then we have authorization. What should you be allowed to do?
And this, unfortunately, has remained largely stagnant. We assign permissions at the point of provisioning. We log in once, and then we do trusted, and then effectively we're trusted for hours. And we get away with that most of the time because most people do predictable work with good intent. So there is an element of trust. For agents, that trust factor is largely irrelevant. Then we have standing privilege. And I will concede that people are looking more at things like zero standing privilege just in time here, but this is still the fundamental approach that most organizations take.
The right to deploy, the right to read a database, the right to call an API. Those permissions persist whether they're being used or not. The privilege exists outside of the action. And that's not carelessness generally. It's structural. If you think about the asymmetry, if we under-provision an account, our applications don't work. Our users complain, and we're inundated with escalations. On the other hand, if we over-provision an account, nothing visible really happens.
So of course, we naturally lean towards the option of least friction, but this does mean that those entitlements pile up across the directory, available for misuse, whether the identity is active or not. And the third point here, we log access, not authorization. We understand who, what they connected to, where they connected from, when, and maybe why they needed access. What we don't really capture is why they perform the activity in a certain way. And although not ideal, we can often reverse-engineer this from intent for human users.
But for agents who may have already taken five or six routes to achieve their outcome, the next route they take could be so obscure and potentially damaging that we really don't understand the intent. We don't understand the why. So these are just three default ways of thinking, and there's many more. All of them are closely related, and all of them need one more thing to be able to take the next step. They need a new layer. One layer whose entire job is to answer the question that we've been avoiding. Should this thing, right now, be able to perform this action?
This can't just be a bolt onto an identity provider. It can't be another module sitting inside a PAM solution. It can't be a policy engine sitting in isolation. This has to be a combination of your existing business policies, your processes, the investments that you've made in technology already, working together to perform four critical functions, importantly, at runtime.
The first, it has to act as a decision engine. It needs to be able to evaluate live context. It has to provide an enforcement path, and it needs to leave a decision record. So let's have a look. Starting at the top, any identity, human, workload, or agent, they should all flow through this path. Why? Because we're trying to answer the same question. We go through the various authentication mechanisms that we're all familiar with today that suit the type of identity that is trying to verify itself. We then get to this point of session-based authorization.
And if we're lucky, we may have that session-based authorization accompanied by a ticket reference, maybe an approval workflow, or some sort of user justification. But this goes back to the point of logging in once and being trusted for hours. And if we extrapolate this across a large organization with hundreds or potentially thousands of administrators and developers who are running multiple concurrent sessions at a time for potentially eight hours a day, the attack surface is actually quite significant.
And then if you add agents into the mix whose behavior we can't predict beyond that door, we actually start to lose control at scale. We don't know what's going to happen. So this is where we have to drop into the next layer, and this is where the authorization control plane comes in. This layer has to work within the session itself at runtime. And it has to continuously evaluate context in real time.
It serves absolutely no purpose if it can only react 10 minutes after a user's machine has been infected with malware or after Claude has decided that the best way to fix an issue is to go off and delete all of your production databases. It has to be able to step in, evaluate the action, look at the context, make a decision, and deliver that decision before every action is executed. When we talk about context and existing investments, what do we mean? On the left-hand side, we have some examples. Most of us use IDPs.
If you change a user's role, we don't want to be waiting two days before these authorizations are reflected on your target systems. This has to be automated. Your EDR solutions, as soon as they detect a shift in the threat score, that's a significant change in the context. The permissions of any in-flight session should change immediately, not 10 minutes later.
And then, of course, we have the typical kind of conditional access factors. Things like the time, the location, the geography, your multi-factor authentication posture. So regardless of your privileges, whether you're a database admin or not, what you should be able to perform should also be dictated by those factors.
Now, for us to be able to actually use this layer, we have to be able to enforce it. And there are three key ways to do this. They can be used in isolation or in conjunction with each other.
The first, zero-trust network access. We can physically restrict access to the target systems unless the traffic flows through this layer, whether they have credentials or not. The second is a credential-based approach. We can obfuscate the credentials or ideally remove them completely and issue them as the user or identity goes through the layer. And the third is a permissions-based approach. We have just-in-time, we have zero-standing privileges, but what I'm really talking about is within the session itself, runtime authorizations.
Regardless of your permissions, going back to the point, we have to look at the context and then determine whether an action is appropriate. So ultimately, any connection going through this authorization control plane to any type of system, a database, an MCP server, a cloud console, should all be captured through this plane. And if it's not, that's where we use our investments in our scene solutions to do reconciliation. We look at endpoint telemetry and network observability. The output of all of this must not be a long-lived credential.
It should be an ephemeral grant scoped to a specific action that's expired when it's done. How do we actually start doing this in practice? There's various bits that sit under the bonnet. One bit that I want to talk about today is the policy. We have to use the policy language that is computationally cheap to evaluate and very quick. And in this case, also human-readable. I'm not sure if Florian's still in the room, but this is an example of AWS Cedar.
Now, if you're not familiar with this, one good way to think about this, or at least the way that I think about this, is for authentication, we have single sign-on, and that started to help with that centralization. For authorizations, this policy engine is doing the same thing. Where you have disparate scattered applications with separate permissions models, this allows you to start centralizing it. And for every action, and for all of the traffic flowing through the layer, we evaluate those actions against these four parameters.
The identity, the who, what action they're trying to perform, are they just connecting, are they deleting tables, the resource they're connecting to, that's the width, and then when is the context, it's the conditions. So in this example, and I'm not sure if you can make out the text, effectively, we're allowing a member of that particular role, the data engineer, to connect to a payments database table, but only when those conditions are met, and these are based on your business policies.
In this case, they're connecting from Germany during business hours, and their threat score is below a certain threshold. And then you may have noticed at the top, we have the annotation at MFA. This is how the decision is delivered. So when they connect to this database table, they should be prompted for multi-factor authentication. And you may also realize this is upstream of your applications, so it doesn't matter whether your application supports MFA or not. Let's have a look at two more examples and bring Agenda KI into the mix.
On the left-hand side, and again, don't worry if you can't see the text, a human user is connecting to a database. They're a member of the same role that they'll use when they connect via Cloud. When they connect to a payments table, and they run a select command, you'll see the annotation at the top. The last name column is redacted. So that's how the decision is delivered. If that same user, with exactly the same identity, with the same permissions, does the same activity through Cloud, Cloud is actually going off and connecting to an MCP server.
So we can apply a policy in a slightly different way. So now we can restrict or permit access to the MCP tools that are being exposed. And for most companies, we want to be a little bit more restrained about the activity that can be performed.
So here, we're allowing that user to only perform read activities when using Cloud. And we're forbidding Cloud from being able to write anything.
So, what this actually does. The three defaults that we looked at earlier, it takes authentication and session-based authorization to decisions at the moment of action. We take standing privileges to ephemeral grants per action based on context. And we transform access logs into the bigger picture. Why was an action allowed based on the context at that time? Does this all sound like a pipe dream? Does it sound hypothetical? Will this actually happen? I'll give you three reasons why I think it will.
The first, physics. We operate at machine speed now. There is no choice. We can't keep up with the decisions the agent's making unless we start doing this automatically. The second is regulation. Three different regulations, three different purposes, all arriving at the same question. That's not a coincidence, okay? We now need to understand under what context or under what policy certain actions were performed. And the third, and I think probably the most important piece, does anybody know what we used to call this in the late 1800s? I think I heard it there. A horseless carriage. Exactly.
It took 30 years before we started calling this an automobile. This is what's happening to authorization right now. The thing comes first, the name comes later. This is already being built piece by piece inside products that call themselves something else. The name will catch up. Anybody know what this is? This is an easy one. This is not just an automobile. This is a time machine. So going back to 2008, payments fixed this with a layer between authentication and action. Not a replacement, a new layer.
So when you go to the bar this evening and you tap your card or a vendor takes you out for an expensive meal and they get their card out to pay, remember that that layer is deciding how good your evening is about to be. We need to start doing the same thing for identity. We've spent 20 years perfecting who are you. The next 20 years should be focused on should you be doing this. Thank you.
Thanks, Alex. They've finally woken up. You've pulled in a few more and they've finally woken up. There are a couple of questions. We only have time for one.
Alex, I'm sure, will be at your booth. So for the more detailed questions, do pop along and ask him or one of his colleagues. The question we have here is, you said agent access is not predictable. How can you define your access policies up front when access is not predictable?
Yeah, absolutely. So I would be thinking more about the outcome. So where we're looking at things like MCP servers that expose specific business tools, I would probably look at the criticality of what those business tools can do, and then I would build the policies around a kind of default to knife the really critical tools first, and then I would start reducing them over time and starting to open up that access when we have more confidence. Great. Thanks very much once again for Alex Wilson. Thank you.
