Scaling Enterprise Identity Programs in the AI Era

Good morning, everyone. Great to see you all this early here. But I wonder how many of you did the walk this morning. I don't know what kind of marathon walk it was, probably a 5K. Anyone here in the room? Because I was just curious how you recover from this.

Okay, so I don't feel that bad anymore. Because let me tell you, when you wait up front, you see everybody really jazzed up, very fit for the day. You feel like you're doing something wrong. Way better start now. Thank you all. Having that said, hello again. I'm Florian, Florian Holzhauer, based out of Seattle. But as a lot of you probably can guess based on the accent, I'm German. So I started here in Berlin with AWS, then later moved to the Pacific Northwest.

And these days, I'm the general manager, as they call it, for IAM Identity Center and the supporting functions such as Identity Store and Builder ID. And as you can imagine, we hear a lot about Gen AI. Pretty sure I don't have to explain what it is anymore. We hear a lot about how to secure it, how to scale it. So I figured I'd give a little bit of an overview over what we hear from customers, how we think about it, and what the overall narrative is. Keeping it rather high level to give a really nice entrance point here.

And then afterwards, I would very much also look forward for follow-up conversations and questions if you want to dig deeper. Having said that, let's directly jump in with the TLDR. I figured that's maybe nicer than just an agenda. In all those conversations and what we hear about trends, there are four themes or security principles, as we call it, that arise usually. The first one is, we will talk more about this in a minute, which AI brings you in a less deterministic world. There's more randomness, for the lack of a better word.

And the good news in all this, because this may sound scary at first, is you have a really nice strategy to still use all the battle-proven security mechanisms of the past by pushing this into the deterministic parts of the area. I see folks taking pictures of the slides. They will be published later as well, just in case, to simplify this. The other thing you also want to do in a less deterministic world, you want to double down on defense in depth. You want to make sure that all your layers are covered. That's what we're going to talk about a bit more.

And least privilege gets way more important than usual. And last but not least, and that's, I would say, the only net new thing. Everything else you probably already heard in earlier conversations. Every agent action always is, in some shape or form, initiated by a human. So you want to make sure that you always know, not just the agent identity, but also the human identity. So we're going to touch on this a bit more.

Now, I gave you a lot of spoilers what we will talk about. Usually you talk about this in five different pillars. They're all lined up here in those wonderful marketing-approved colors.

Today, I will single out identity and access. So the most important thing not to take out of this is, if you just do what Florian told me, I'm safe, I'm set up for success, I can scale. That's probably a little bit more. I will hint at this, but we do have a lot of materials about all the other pillars. And I figured 8.30 a.m., caffeine just kicking in, 20-minute talk. It would be pretty mean to dig into all of those, which is why we're starting with identity and access. I hinted at this before. We're seeing some changes, some new challenges. So let's get, oh, the clicker doesn't work.

Now it worked. What changes? We enter a more non-deterministic word.

Usually, when you execute something in a classic code word, you know exactly it happens over and over at the same time, no matter how often you run it. If you enter the same prompt, there is a very high chance the execution behind the scenes will slightly vary each time, which also means you have more nuance in the risk profile. It also means who exactly does the final deciding factor, who decides what gets executed, and you have, like I just said, a more hybrid human-slash-workload identity, which you also need to reason about.

Obviously, that's all a little bit high-level, so let's dig a little bit deeper. What does non-deterministic actually mean? The classic code situation, pretty easy. You have a blob of code. You can analyze it. You can have your threat model. You can go all over it, and you know pretty well it will happen like this. IAM happens to transfer over one billion requests per second. I can guarantee you they will exactly yield the same result over and over again, or we probably all would talk about different things today. Access patterns are predictable. You set your permissions.

You have your security review, all those things once and done. Now, as we move towards Genii, I already mentioned it, you have a more nuanced code path execution.

Usually, you enter a prompt, and the agents try to unblock themselves. They learn. They evolve over time.

So, by design, they will change how their access patterns are. You have a very hard time to predict this. Very hard time does not mean it's impossible because there are a lot of security boundaries you can draw around this. There are certain parameters, but there's still more nuance. It's not exactly one billion requests per second, and you have always the same execution again. And the last one also is very interesting. You have a very hard time to reproduce why something may have failed unless you're really good in all your logging, in your observability, in your debugging capabilities.

Something that now veers out of the specific identity domain, but even there, important to keep in mind because otherwise you end up in a world where you get a lot of customer requests and you have no idea what they're talking about. The other part of non-deterministic, which also changes how to think about security and identity in that phase, is that we see for a lot of customers that they evolve within their use of agentic AI. At the very beginning, you have what we call a non-agency agent. Strange word, but what it means is, essentially, the input is triggered by a human.

The agent tells you what to do, but you, as a human, do the actual change. You execute a command, you click a button, whatever it is. Think the classic chatbot, the classic support functions, which we all know, and some of the more funny ones you also can ask to provide a Python script instead. And then we see with many customers they slowly ease themselves way into the more adventurous parts of Gen AI. You enter a world where you still have a human in the mix, but first the agent asks for approval before executing a command.

Eventually, you end up in a situation where the agent does the changes entirely programmatically based on certain rules and boundaries. And at the very end, you end up in what we call full agency. That is usually what you hear in all the big headlines, and that's also very, very impressive because it sets you up for a very different scale, which is the agents initiate themselves, they communicate, and they execute. And as you can imagine, this also triggers a very different question around how to reason about boundaries, how to reason about identity.

There is a really interesting question about how exactly do you now combine identities of agents calling other agents, like who exactly now is who in all this situation. A lot of things to solve about. From a security perspective, this sounds a little bit overwhelming. Sort of an invisible Rube Goldberg machine. You don't really know what's going on. The good news is it is way less scary than it sounds like.

By doing what we said in the very first slide, you push everything when it comes to security in such a word, including all the identity parameters outside of the model, which is where the ambiguity happens, where the randomness happens. What this specifically means is you make sure any controlling mechanisms, such as IAM policies, for example, in an AWS world, happen outside of the model, where you have a classic, traditional, deterministic call path.

You make sure that around this wonderful box, and we'll talk more about the box and how this actually is too, you draw the access controls on all boundaries. Input, output, data access on all those layers. So you draw all the parameters around the box where you still have the reliable world. And we already spoke about this, you really need to double down on defense in depth.

You will, as things evolve, be really happy if you make sure that you have multiple layers of defense, and if there may be something glitches because you didn't anticipate an error, you still will be safe. There still will be nothing happening.

Now, I spoke a lot about boxes, agents. What does this actually mean from an identity context? And how does this mean from an authorization decision context? And the way we think about this is essentially in this flow. What is it, left?

Sorry, that's my weak spot. At the left side, you have the initiator of the agent. In a non-agency world, it's a client. As you move towards full agency, you talk about systems initiating the agent. They communicate with an agent, which then usually have some sort of gateway into the resources you want to analyze. When I'm talking gateways, it's usually MCPs, that's APIs, something along those lines. A gateway then gives access to resources, which could be a data lake, your database, a bucket, anything along those lines.

And the interesting new part now is that you want to have in this entire flow every time two validations. You first want to check, is the user actually allowed to call the agent, where user obviously now also could mean the system on behalf of the user, where you have full agency. And the same way, you want to know who the actual agent is, and this is going to be a very important piece for the rest of the flow. And you want to make sure if the agent allows the access to the resource. So in that sense, you already have a security perimeter within the agent itself.

And then you do pretty much the same game. We have these wonderful animated slides. I'm just combining them. In the gateway, all over again, where you have exactly the same questions, but from the gateway's perspective. Is the agent, is the user allowed to call me, and then also am I allowed to call the resources?

Am I allowed to call the resources is probably the most interesting one here because you almost always want to have the same agent for, let's say, multiple clients, multiple cost centers, multiple departments, and it's pretty rare that all of them should be able to operate on all the data, which is an important thing you need to model in your security phase. Modeling essentially means you need to ask yourself four key questions. You want to first obviously reason about how do I prevent unauthorized access? You need to be able to distinguish who can access my resources.

Traditionally, this always meant the principal, the user. Today, you have two identities. You have the workload identity and the customer's identity. Access scoping is important. And something way more important these days is just-in-time access. Just-in-time access because agentic AI tends to move pretty fast basically because of the velocity of the decisions, but also because it's usually way better connected. So you need to be way better these days both in detection and remediation in real time, which is something we see as an interesting challenge with some of our customers.

If you react within 48 hours, it will be an interesting conversation. Those are the four questions you overall need to look at this. As a reminder, we had those five different pillars. You want to review those in all five pillars.

Today, we will be especially looking at how to solve this in an identity context. Well, and so far, I was mainly preaching. So I can see this will be, okay, now, how do I think about this? How do I do this? And the easiest way to explain it is with a slightly simplified version of how the flow actually looks like. It is essentially what we explained before. You have a client calling the agent with an application, interfacing with the data. What we are omitting here is the gateway. That's essentially the errors to the downside, the gateway to all those resources.

And just for good measure, we also highlighted the model. Now, from a securing axis, from an identity security axis, how do I now actually implement this? First of all, you implement the authorization controls outside of the model. You do it before, but also within the call path. That's why we have the number one splintered all over the place. You want to make sure you have the authorization between the client and the agent. As we said in the slide before, you want to make sure that the client actually is allowed to call the agent in the first place.

You also want to have this within your layer, but you also want to even validate the access authorization right when you access the data, when you access the tools. And the obvious one in an AWS world are IAM policies, SEPs. We offer a lot of tools there to simplify this, such as policy generation, access analyzer, unused access findings, which helps you to move towards a least privileged permissions.

For instance, you also want to audit and remediate overly permissive roles, which is the ongoing process of removing anything that's not needed, which is something where the earlier mentioned access analyzer comes into play again because they also even offer you policies how to remediate, how to get to what fine-grained resources.

And you want to encourage to always go to the least privileged permissions because the key problem is, like I said before, that you operate in a much higher, faster-paced world, so you don't have the classic, I get a change, I review the change, my security engineer reviews the change, and that's how I can adjust my posture. If you don't move to a more, let's say, near real-time world, it will get pretty challenging to secure or also to remediate if you actually do have a breach. You then want to propagate user identity through the AI agent.

From an AWS perspective, the best tool we have there today is within Bedrock Agent Core. It's Bedrock Agent Core Identity, which makes sure that you always have the workload identity, the agent identity, so to speak, together with the user identity, so you can have all those policies and access decisions and similar tied together. As we discussed earlier, you want to make sure that you always reason about both and can reflect this in your entire authorization model. This decision happens only on the cow path. You want to make sure this happens in transit.

This is where essentially the metadata flows with you, even as you, for example, may assume roles between identities within AWS. You then finally also want to implement dynamic credential delegation. That's a lot of funny words, which essentially means you usually want to delegate fine-grained permissions for the specific task to the agent. The overall workload may have more permissions, but using technologies like STS, you can get very fine-grained policies, very fine-grained permissions for the specific workload. And most important, you want to make sure they're very, very short-lived.

They should live for the duration of the task, and then they get invalid. Because the beautiful power of Gen AI is that it is really good in unblocking itself, but sometimes doesn't really know if it's a good idea.

Like, within my team conversations, we often compare Gen AI approaches today. They will evolve, obviously, with an intern on too much caffeine.

Obviously, some of my interns also do interesting things, and that's why you want to make sure that not for whatever reason you have a more powerful permission within the session from a different workload earlier, which the agent still can use to unblock themselves, but wreak havoc in the process. So above all, dynamic credential delegation is key here. And in the same vein, granular access for each capability beyond the session policies, beyond the access policies, you also want to make sure that the capabilities as a whole have been fine-grained again.

So, for example, what kind of model are they allowed to access? What kind of tools and APIs are they allowed to call? Which is another defense in depth layer, which, for example, could mean, let's say, network policies.

Is, for example, your agent allowed to only access non-production resources? You do not just want to model this in IAM policy, but you also want to make sure you have the right VPC and point parameters, the right network firewalls as well. I see the timer already flipping orange. So in that sense, let's move on to a recap.

At the very, very end, if you want to set yourself up for success to scale in a Gen AI world, it is surprisingly simple tools to use, but they are deceivingly simple because you need to make it really diligent when it comes to how fine-grained your permissions are, how fast you can respond. But the good news is a lot of this is tried and true already. A lot of the tools I discussed, except for maybe the workload identity bit, are tools which already exist for quite a while.

Most important, you want to make sure that every agent traces back to a human, traces back to the human identity, because you always will want to make sure you authorize based on both. The combination of both is key. You can start pretty easy when you move over the agency slide we had earlier. You start with human initiated and the human checkpoint. And as you get your guardrails in place, as you evolve, you then move into a full agency world and get to play catch-up using the tools we discussed. And you always want to make sure this decision happens in as deterministic as possible space.

You want to make sure it is where you exactly have, let's say, a binary decision to make. You don't want to have this in a more ambiguous world where the LLM may end up in a different call path each time. And that should set you up for success. But as a reminder, the same ideas with slightly different tools apply for all the different pillars we discussed in the beginning. Today we spoke mainly about the identity part, but you have the same for data access, for auditability, for network controls.

And this is how you set yourself up to scale, because you remove the need to review this as a human each time and to be safe. And with that, eight seconds over. Thank you very much. I hope it was a good start.

Well, congratulations on making it in the time. Just a quick question then. Many organizations are experimenting with AI agents faster than their identity architectures can evolve. In your experience, what is the single biggest scalability bottleneck enterprises encounter when trying to extend IAM controls to agentic AI workloads? I would probably say the right balance on risk appetite. There is a certain balance, because there obviously is risk, but you also don't want to move too slow. And in that sense, the right way to solve it is to have a productive conversation.

Don't rely on, we always did it like this. Have a honest conversation about what are risks, what is acceptable risk, how do we mitigate this, what are the right deficits in depth layers. And I think that's an easy way to set you up for success. Great. Thanks very much, Florian. Thank you.