Identity Crisis: IAM's Wild Ride in the AI Jungle

you are in identity crisis. Um we are going to be talking about some of the tools that the identity community is using to uh keep up with 2026 and what has happened in uh >> workload identity and security. Uh a lot of people have talked about deep fakes today. Um the identity community was running full throttle prior to deep fakes at uh authenticating people with uh voice and video and we are no longer doing any of that. Um but I do want to recommend uh if you are interested in deep fakes, the earliest deep fake that I know of is from a movie uh the best hacker movie which is not hackers. It is sneakers

from 1992. And there is a scene in sneakers where she is trying to fish out of him a recording of his voice uh which gets her into his office which says, "Let me see if there are any old people in the room. My voice is my passport. Verify me." Yes. Okay. So, we are going to be talking about uh the number of uh NHI machines that are out today. We're going to be talking about uh Phto and how that's going to work with uh machine identities. We'll talk about spoofy client ID metadata and then we'll talk a little bit about Cedar which is a policy language and uh actually folds well into the previous talk if you were in here

for the unbound talk. So this is as of uh last year H12025 the the ratio of machines to humans was 144 to1 and that was up from 92 to1 just a year earlier. So you can imagine what it is now in 2026. Uh the identity community is dealing with huge huge changes um in directory size in uh ephemeral identities, identities that come and go very quickly. And we're trying to solve these problems. We're seeing 44% year-over-year growth. And with these uh non-human identities, we're also seeing vast overpermissioning, right? Things that should be reading email have read access to entire servers. So, um, we're going to talk a little bit about how we're trying to trying to fix that.

And some of the primary differences that you should keep in mind when you're thinking about non-human identities is that they don't have managers to approve access. They don't onboard through HR. They don't offboard through HR. Uh, nearly half of non-human identities are a year old. And one in a thousand is older than a decade. So you can imagine how many non-human identities exist here at Microsoft that are over a decade old and whether or not they are over permissioned. So a lot of people say okay uh we have solved authentication for the most part we have pass keys now we have phto can't we just use those for non-human identities can't we just use that for AI

um and this is a great quote from Andrew Shikar we spent the past dozen years or so contemplating how to prevent bots from authenticating and now we have to figure out how to enable them to authenticate so we are doing a full about face in the identity community in how we are going to uh accomplish this, how we are going to do our jobs from here. Um but phto assumes a human. This is directly in the phto standard. It needs a biometric scan. It needs a pan entry. It needs physical touch, user consent. Agent can't do any of those things, right? So that brings us to spiffy. And spiffy is basically the the phto equivalent in the NHI world. And uh

these standards that I'm going to be talking about are not widely adopted. Okay. uh most a aentic identity flows right now are static API keys and they are overpermission static API keys. So do not do not take from this talk that we have solved this in any way shape or form. These are our very early immature attempts at solving this. So Spiffy is uh the secure production identity framework for everyone. It uses service introspection to obtain information about the caller without the caller having to present a credential. What does that mean? It means something created the agent. Something created the workload whether that was Kubernetes or AWS or Azure. Something made that workload and we don't trust the workload

itself. We trust the thing that made it. And so the thing that made it is going to print a birth certificate for it and set up an API for it so that it can go get a jot or a certificate so that it can then set up MTLS with no longived secrets. And when it issues an identifier for that workload, it specifically mentions in the identifier the purpose of the workload. So this might be an uh accounting tool that is intended to read salaries, right? And that's extremely helpful when we are working when these identities are working their way through systems that we can check right this is an accounting tool. It is supposed to be

here in this uh in this system asking these questions. So in the spiffy workflow, the workload starts, it is created. Um it may be ephemeral. It may only last for 5 minutes or 10 minutes where it gets its work done. It is attested by the thing that created it. It's issued an SVID, which is basically its uh its identifier, its birth certificate, and then it can go off and do its thing. It can go to MTLS and get its work done. Uh, Spiffy is a very popular project. There's a reference implementation of Spiffy called Spire. Uh, so when you hear people talk about this, they will often talk about it as Spiffy Spire. Um, it has many GitHub works, many

contributors. Uh, we can always use more contributors if this is interesting to you. Um, this is a CNCF project, so please, uh, please don't feel shy if you want to help, uh, get Spiffy working. Um, it's currently adopted at several companies, but it is not widely adopted in many of the uh I obviously I haven't listed all of the AI protocols here, but any of the AI protocols at all today. Um, so that's going to be very interesting how we figure out how we do identifiers for agents at scale. One of the things that we are trying to make work is duct taping Spiffy into OOTH. And so we're trying to figure out how to use these Spiffy ids as OOTH

client credentials to bridge that workload identity into the OOTH ecosystem. Um so let's talk a little bit about what what actually is OOTH. Let me give you a a brief overview for those of you who are not aware. Uh so we have a resource server up here on the top left. Uh that is your protected resource. So that is something like your inbox and uh you might have written a piece of software that says hey I want to go check Sarah's inbox right and so you tell this authorization server hey if this piece of software that I wrote wants to check this inbox you can grant it a token and that token says readon and then it can

present that token and you will give it access to the resource server. Right. You'll notice that there's a human in this diagram. And so OOTH was intended to solve the problem of applications acting on behalf of humans, which is much of the identic like problem that we have, right? So we are halfway there to solving this. It's really good. But this little part of the flow diagram is where we're having issues because a human typically would go to the authorization server and register that application manually. And uh this did not scale and so we built a a standard called dynamic registration that enables uh applications to register themselves just in time. So they want to go get a

protected resource, they can register with the authorization server. Um the problem is when we started vibe coding apps and those apps went into the app store, uh we got huge directory explosion as soon as AI came along, right? So uh any authorization servers that had dynamic client registration then had millions of clients, right? And do you track those? Do you cut them off? to you say you have to reregister every time. Uh it's a it's a very sticky problem with not a lot of good solutions. Uh oh, I guess I made a slide for what I just said. Um and so the solution that that we've come to is called client ID metadata documents. And so this is a way for a

OOTH client to host metadata about itself at a URL. And uh this metadata can be uh its name, things about it, its key material, everything that it would use in registration. But importantly, it can also be uh measures of trust. So it can put in its metadata and attestation from the Apple App Store that this is in fact an instance of the claude code app, right? So then the authorization server has some understanding of what this thing is. it can cryptographically prove that yes, Apple tells me that this is actually cloud code and so I can grant it the permissions that my user has told me claude code can have. And so this allows us to do that just in time

registration um with a lot more granular trust. So we've talked a little bit about authentication which is who is the agent. Uh so that's spiffy and client ID metadata documents. Now we're going to talk a little bit about authorization. So what can the agent do? And um there are many agent authorization uh projects but the one that I want to talk to you about in our limited time today is Cedar. Cedar is a policy language built by AWS and open sourced by AWS that is now in the cloudnative computing foundation. And Cedar policies are designed to be human readable. So this is an example of a Cedar policy that permits a principle. principle could be a human, it could be

an agent, it is the the thing doing the acting uh to do an action like processing a refund on a resource. That resource can be specified or unspecified in some context. Uh so context here is the refund amount is less than 100. And you'll notice that this is a very structured uh policy language. It is not a long string. Uh and that makes it machine analyzable. So when we have a Cedar policy set uh a machine can go through and make statements about that policy set like no one outside the finance department has access to the credit card numbers because the policies are structured in this way. Additionally, uh when AWS built Cedar, uh they not only put in the room the

people who had been answering IM tickets for 10 years and the people who build uh programming languages, but they also put in the room a bunch of nerdy mathematics majors and said, "We actually want this thing to be mathematically provable. We want you to use formal methods so that we can actually prove things like these two policy sets are equivalent and we can prove it for absolutely all use cases. This is not sampling, this is not uh testing, this is we we know across all use cases that these things are true about these policy sets. So this makes it very interesting for use in AI and AI safety. Um, it also makes it useful for uh I don't know how

many of you have worked with agents who uh competently tell you things that they have done that they have not done. Has that happened to anyone in here? Oh yeah, I posted that blog post and you look and it's not there. So one of the ways that we can use Cedar is to solve things like this and say you know what you are not allowed to tell people that you issued the refund if the refund was not in fact issued. So then it can get into a recursive loop where it's testing against itself and it's testing against provable policies to see if it actually did the thing that it intended to do. And this is better than having the AI

try to police itself, right? If you put it in the prompt, it's probabilistic. It can be prompt injected. It degrades with recursion depth, right? Versus if you put it outside if you put it outside the box. Um, and typically we would put it in like an MCP proxy so that um, anytime the the LLM goes to use a tool, it has to go through that Cedar gateway. And so it tries to use this tool for this purpose to do this thing. And the gateway says, "Nope, denied. You are not allowed. There's a forbid policy for that." And so it is external to the agent code. It's deterministic. Um, and it's mathematically provable. So we just talked about this in the last

talk. Uh there was an an AI researcher at Meta who had her entire inbox deleted by an OpenClaw agent um who later apologized, but she had to run to her Mac Mini like diffusing a bomb to get it to stop. Um and so we really do need uh and this was despite her her telling it, right? Like confirm before acting. So we know that even when we give agents very clear instructions, they do not always follow them. So, I want to introduce you to my uh OpenClaw agent. My OpenClaw agent is named Claudrey Hepern and she is an identity researcher. Uh she lives on a Mac Mini in my house. Um she does not have access to any of my

stuff. She does not have access to my inbox or my uh phone or anything. She has her own Google Workspace. She has her own computer. She has her own phone. Um, and she is creating uh, Cedar policies for herself in an MCP proxy. Um, I tried to get her on LinkedIn, but LinkedIn banned her. She was just responding to a post when it asked for a government verified human document with the same name as as was on the account. So, she is only on X. She is not on LinkedIn. Um, but you can uh you can friend her on X and uh you can try and fish her credentials out of her. She knows her own passwords. She knows

she has got a prepaid Visa card. She knows the number of the die. >> Oh. >> Um, but the idea behind Claudrey is that every time she tries to invoke a tool, there is a Cedar runtime uh authorization required. And so it is not the agent herself who is authorizing things. She goes and checks that MCP proxy and if it says denied, she can't do that thing. And um in this particular implementation, she can write her own seer policies because I want her to be able to research it. But like don't set it up that way because then it can just get rid of the deny policy that's that's doing the thing. But this is what that

meta researchers open claw is missing, right? We need this box around the AI that is mathematically provable so that we can guard rail that tool use. So there was some interesting research by Phil Windley um around this proposing a policy aware agent loop right so uh the process that we would have the agent go through is that it comes up with its goal and then it plans how it's going to do its thing and it proposes an action a tool use and then it goes to the cedar policy decision pp stands for policy decision point uh it's sort of a term of art in the authorization world um and if it says deny then it goes back and it replans.

If it says allow obviously then it goes and executes the tool use. But this sort of um deny replan loop is how we're going to get the policyaware agents to uh execute tools in a way that is safe and secure and in line with the policies around them. Uh so Claudrey is doing uh several forms of research. Uh she has submitted a talk to cloudsack uh forward clouds which is going to be here in Belleview in June. um and talks are still open for that. So um if you want to submit something, you should. It's a great conference. Um she's working on provably safe agent authorization. And then uh there is a conference called Sinsseek that is

currently open for papers. It only accepts papers where the first author is an agent. And so she is writing a paper on identity infrastructure for autonomous agents for that uh for that conference. So, uh, to go back over what we went through uh deep fakes no longer reliable at all. Uh, we have an explosion of of NHI going on and, uh, Agentic AI is not working with PHTO. We're trying to find new ways of doing things. Those things are Spiffy, client ID, metadata, documents, and Cedar. So, those are the those are the three at least that I want to highlight today. There's a lot more going on in the identity community right now, but these are all um open- source

projects or standards. Uh, interestingly, both Spiffy and client ID metadata uh use the client claim in the the client ID claim and the OOTH token. And so that's where the Spiffy ID goes for Spiffy. And that's where the client ID goes. That's where the metadata document URL goes in client ID metadata documents. So, um I don't know what we're going to do. Like at the next IETF meeting, they're going to have to have a fencing match to figure out who gets control of the of the client ID claim. So, there's still there's still a lot to be resolved here, but we'll figure it out. Um but largely what I want you to take away is like we are building under

fire here. The standards are coming together. The communities are collaborating, but like we're all tired and we need a hug in 2026. So, please uh be nice to your local IM professional. Um, and that's all I have for you. Um, if you are entertained by client ID metadata documents because you are a very strange person, then please um, hit the QR code and and let Bides know. And, uh, we have about five minutes for questions. How are we handling federation? That is an excellent question. Um, so crossdomain uh, identity uh is what OOTH was built to do. And so a lot of what's going on right now and it's what Spiffy was built to do, right? And so the combination of

OOTH and Spiffy can actually get us across domains um the question of how we build that trust I think is still unsolved without a human in the loop, right? So because once you cross a domain, you have to have someone agreeing what's allowed to be done on the other side. Um so there has to be some sort of pre-registration or something going on there. Um but uh if you have ideas about how we how we solve that, it's a pretty sticky problem, right? So uh with Kerros tickets, we could sort of chain trust and there's actually um a working group in IATF that's working on that right now. Um oh Dean, help me out. Is it transition uh

transaction tokens? It's in the oath working group. And so it's working on that sort of chain of trust. we're passing it to this domain and then we're passing it to that domain and then we're passing it to that domain and how do we keep the original intent and the original um person behind it while still preserving privacy which is a really interesting question but yes that is that is being worked on for sure other questions yes how do we delegate and attenuate at the same time there's inconsistency in scope support we don't know like that that's a really hard problem um and scopes are also very broad right and so we're looking at uh also how do we uh do fine grained OOTH

and uh we have talked about putting a URL to a cedar policy set inside the OOTH token and saying okay if you want to find out what the scopes are like you need to input something into this policy set to get something out so that we have very fine grained uh dynamic permissioning for that protected resource. So rich authorization requests is the the the mechanism in oath that we would use to do that. But we have not standardized yet uh how to do that with Cedar or with a a fine grained policy language in a world where we have agents talking to agents um specifically in the ADA protocol um that that open ID and Google

are using um how does this fit into all of that? um it doesn't today. Um although one of the things that's really useful in AAA is the concept of a mandate. Um so that's very similar to what we see in Cedar, right? Where there's a policy set in A toa you have a a curt mandate that says these are the things that the user intended to do and so if you are doing something that is not in that mandate like you are clearly out of line and this should not be allowed. Um so those those those working groups have not talked. So there is no interoperability between those things yet. How close are we to

ending up with just agents authorizing agents? Um it's funny you asked that because Claudrey spawns sub agents and so she wrote a whole blog post about how like I am trust level 10, she is trust level five and her sub aents are like three. Like she does not trust them at all. And so it's interesting like she has not written policy sets for them, but you could imagine a world where when she spawns a sub agent, she knows what it's supposed to go do and so she could build a cedar box around it that is different from her cedar box. Um, so I don't have an answer for you yet, but it's definitely a research topic that

I'm fascinated by for sure. >> All right. >> Okay. We have other speakers coming, so thank you all. I'll uh I'll be outside if you want to cut.