CIAM for AI: Authn/Authz for Agents — Michael Grinich, CEO of WorkOS

My talk that was up here said "CIAM" for AI. That's a bit of industry lingo. It stands for Customer Identity and Access Management. Really, what I'm going to be talking about here is Auth, login for agents. We just heard from someone from Hex.

Hex is actually a WorkOS customer. We provide identity services to lots and lots of different SaaS businesses, B2B products, and our fastest growing segment is AI companies. It turns out AI products need identity and authentication, so we have a lot of experience seeing this.

So I'm going to talk about how you can bring identity specifically to agentic-based applications, what we're seeing in the world today. So to start, I'll just start with a little bit of a story. I want you to imagine that you're building a new chat tool, kind of like a ChatGPT internally for one of your companies, and it's like an IT support tool.

So it's going to help people not have to reach out to your IT team to get help with their laptop, debug issues they might have. So you ship this thing, and a user signs in, and they say, "OK, my laptop had been filling up with files.

Let's delete some unused files just to clear up some space." And the LLM thinks for a bit, and then it goes, "Certainly, sir. I went ahead and deleted your production database." And this is a bit of a fictitious situation, but it's not too far off from reality where these non-deterministic agentic systems can go off the rails and have pretty destructive actions in your environment, in your product.

And these agents only work if you give them access to everything. This example here, you might say, "Well, I'll just disable access to the production database." But what about Jira? What about Salesforce or your Slack instance, your email?

Agents are only as powerful as the systems you give them to. So inherently, there's this whole problem around kind of identity, authentication, and authorization for these systems. And really, what I want to emphasize here is there's a shift coming where we need to think about agents as really having first-class identity support.

What defines an agent in the B2B SaaS ecosystem? It's different than a bot or an integration. Agents are really a new paradigm for engineers and also enterprise IT to be working with. And my call to all of you is actually to collaborate with us to figure out how we can come together to work on these new standards for agent identity so users can stay safe and protected, and we can all leverage it to scale and grow forward.

Agents behave a little bit different than people. Agents interact across many, many different tools, and specifically, they need to act on behalf of users. They're similar to users, but like I mentioned, they need that wide data access to do a lot of different things.

They might need to be able to access data from multiple different users in one. So the identity stuff here I'm going to talk about, they're similar to users but a bit different.

Agents really need to support a machine identity natively. If you've ever heard of machine-to-machine auth, anybody heard about that before, like certificate-based auth? It's actually not the same framework as agents, because in those scenarios, you really just have services talking to each other.

Agents behave more like people and systems, so it's kind of this hybrid between a machine and a person identity. And last, I'll just say here before diving into some more details, we really need to do this. AI is clearly taking over the world.

It's kind of preaching to the choir here at the AI Engineer World Summit. But

inside of the enterprise, people are racing to adopt agents because they understand the productivity gains that it can have. So we can't just wait to do this and hope that it takes care of itself. We need to figure it out very soon.

There's a lot ofurgency around it. So I'm going to switch gears a little bit and talk about, first of all, why identity for agents is hard. What makes it different, and why is it challenging? Well, the first thing is agents need to log in in a headless way.

And when I say that, I mean that they need to build a sign-in without necessarily typing into a web browser. It's different than API auth, because you might want tokens to persist for a while but not forever. You also might want your agent to actually use the front-end application and click around like a computer-used system.

So they need to be able to sign in, but at the same time, not be signed out like a normal user. These sessions need to be long-lived. There's a question around where these credentials should live, how to refresh them, how to agent-store them securely.

This is one of the hard problems around agents. You'll hear from Paul for browser-based in a little bit. That's a question for browser-based. As people sign in and create sessions, where is that stored, and how is it kept secure?

Another challenge here on agents is the least privilege access model. So giving agents only a scoped-down ability to do something very specific. On the one hand, you want to scope down an agent's access to a very small amount.

It can only send a certain email, access a certain amount of data. But on the other hand, these non-deterministic systems, you want to give them access to do a lot of things. You want to actually give it access to your whole environment, your whole code base, maybe all of your bugs, all of your customer conversations.

So there's an authorization challenge around this where the existing least privilege model doesn't necessarily apply. You can't really constrain it. Permissions need to be dynamic for agents.

And lastly here, compliance. That example I gave earlier around the agent deleting the production database,

it's something we need to have a track record of who's done what. Agents also need to be tied to a person at the end of the day, often for legal compliance. If you do something like SOC 2 compliance, all of your code has to be reviewed by people.

What happens if you have agents reviewing code? And lastly, agents can just do a lot of stuff really fast. There's an old joke. I think it goes, "To error is human, but to screw up 10,000 times per second, you need a computer."

Agents will be like that,right? They'll be able to go spawn other agents and do a lot of stuff. And so the visibility and the observability into agentic systems will be just as important. So logging systems, enterprise logging management, how you get agent logs into those things, all very hard, all very complicated, but important to solve for us to actually scale these into production.

So it's really challenging, actually, to kind of bring identity and build these agentic systems. I want to propose a few architecture patterns here as to how we can actually do it. And these are things that I'm kind of seeing people start adapting out in the wild.

There's four of them. I'll go through them each individually. These are not prescriptive by any means or like the be-all, end-all. It's just some things that I've seen so far. Cool. It's persona shadowing, delegation chains, capability tokens, and lastly, escalation to humans, human-in-the-loop.

Allright. Persona shadowing. So persona shadowing is sort of like impersonation, where you give an agent an identity that shadows a user. So this reflects off of a user. It's kind of like a secondary user from your identity system.

It has a subset of the privileges that a user might have, and it lets that agent go do things on behalf of a user. And this separation lets the system enforce stricter limits in access control around that actual shadow agent here.

So you get this isolation and accountability. However, every action is still explicitly tied to an original human identity, which has the benefit there. Impersonation, just pure impersonation, gives too much power if it's just exactly mirrored as a person.

So this kind of shadow-scoped identity lets you delegate a subset of the privileges. And you can even create role templates off of this. This is probably the closest I've seen to people using agent identity in the wild. You kind of take your enterprise IDP, and if there's the Michael Prime, the human Michael, I have Agent 1 Michael and Agent 2 Michael or something like that, which are shadow personas off of my own identity scoped down.

So this is one way that you can achieve identity for agents. A second here is delegation chains. So if you've ever used JWTs, JSON Web Tokens, where they're signed, there's a cryptographic signature you can verify as you pass them along from system to system to system.

They're stateless in that way. Delegation chains are kind of like that, where you can mint a token for an agent that maybe has some verifiable permission and pass it on step by step. It means that each link in the chain must carry forward the original user's authorization.

So it requires a different level of kind of remote procedure, calling in that way, context passing. And it's sort of like those shadow personas in the sense that you can layer it on top of shadow users. This can be supported by a few different things.

I'll talk about in a second the UMA and OIDC extensions. But this kind of idea of delegating access step by step by step is becoming more popular. So again, you create that token, you pass it to different systems, and it can persist from one to the other.

Capability-based tokens. So essentially, given a token that can do a specific thing, Agent X can read Bob's calendar for the next 60 minutes. You create a token just for that action, essentially only for that thing. It's like a secure voucher.

And those can expire after a certain amount of time. They can have scoped access. These tokens can be self-contained and time-bound, so it can simplify how actually verification works on it. And essentially, possession of that token, of that voucher, lets you prove that you're authorized to do something, so you can pass it along.

Kind of similar to the JWT stuff I mentioned earlier, but around capabilities versus roles or permissions. You could even have a token like this minted for just one specific action, one specific API call. If you're familiar with the macaroons work that Google has done, this is kind of a version of that.

And lastly here, escalation to humans, human-in-the-loop, approve everything. Pretty simple to understand. When an agent needs to do something, it bubbles it up to you, and you hit approve or deny. The problem with this is that users get consent fatigue.

Hit approve, approve, approve, approve. If you have your Mac or your Windows laptop and it's asking you, "Hey, do you want to install this thing?" Eventually, users just start hitting approve on everything, just OAuthing, giving broad scopes. And so this actually doesn't really achieve a secure model, even though from a compliance perspective, it might be acceptable from IT.

So these are four techniques that people are kind of adopting today: persona shadowing, delegation chains, capabilities tokens, and escalation to humans. I think actually theright approach is a combination of these things in different scenarios. So depending on what application you're building, the access patterns, who your customers are, kind of what restrictions they have in their environment, you might adopt different pieces of these or all of them, or maybe something totally different.

But they're just some of the architectural techniques that I'm seeing for kind of securing and bringing identity to agentic systems. OK. We're going to keep going. I'm going pretty fast. Next, I want to talk about one of my favorite things, which is acronyms.

We love acronyms at WorkOS. There's acronyms everywhere in the identity and security space. I want to talk a little bit about some emerging standards and protocols specifically for bringing identity to agentic systems that are out there. So some of these you might have heard of.

Some of these you certainly haven't. They're brand new. But I'll go through a few of them just so you'll have some lingo as you think about this maybe over the next year. Cool. The first is OAuth. How many people have built something with OAuth?

Pretty much everybody. Yeah, OAuth. Standard Authorization Delegation System on the internet. OpenID Connect, if you're not familiar with that, it's kind of like OAuth's younger, hotter cousin or something. Essentially, it allows for delegation of the identity and authorization.

This has come to MCP relatively recently. So through MCP, you can add an OAuth 2.1 authorization server, split the authorization from the resource server, and essentially create identity for MCP servers. The problem with it is it was built for human consent and not machines.

So it kind of depends on a user interface. We need to adapt it for machine auth. It also has static scopes. There's a lot of problems with it for agentic identity. But the benefit is everybody here knows it,right?

And it's already integrated with a lot of applications. So there's a ton of momentum just generally around OAuth for agentic identity.

UMA, user-managed access. This is actually an extension to OAuth that allows a user or resource owner to proactively grant another party or requester access to resources from a central authorization server, kind of like what we're seeing with the MCP work that I mentioned.

It essentially lets a user set policies around what an agent can do, but uses the OAuth-based handshake to enforce those policies on resource APIs. So it's an extension to OAuth for those resources. Agents are really all about accessing resources and doing specific actions.

So for an AI agent, it could leverage this UMA to control maybe what a personal AI assistant is allowed to do. It's externalizing the content and access policy rather than baking it into the OAuth consent dialogue that you approve specific things.

It's on a go-forward basis, user-managed access.

Another one is GNAP, GNAP, Grant Negotiation and Authorization Protocol. If you're a masochist like me, you can go read the RFC 9635. There's a lot of cool stuff in this. This is designed actually for a dynamic negotiation of token scopes.

So we've all probably seen in OAuth, you have these static token scopes. Gmail, it's like read and write access. Maybe it's your Twitter account. It can post tweets. But we really need dynamic tokens, excuse me, dynamic scopes, because as an agent is running, it might need to go do something that you didn't previously authorize it to do, that you might not have known it needed to do.

Maybe it proposes it wants to go do something that wasn't even in the original scope. So this dynamic negotiation of tokens is actually an important way to have interaction with agentic identity. GNAP is actually a flexible framework for this.

It was built before all the stuff around agents. So it's pretty cool. It's relatively well-baked. Unfortunately, it's not that well implemented out there in the wild. So it's a lot of really good ideas, but kind of lower on the implementation stack.

There's more. OIDCA, OpenID Connect for agents. This is very much in the protocol phase. It's an emerging protocol for OpenID Connect. I actually was told recently that the guy that's doing this is kind of doing it without the consent of the OIDC Federation.

So maybe it's not even real. I don't know. This is how cutting edge this stuff is. But essentially, it allows you to bake agent identity claims and delegation chains into OpenID Connect more natively. So people are really trying to bring OpenID Connect into the agentic world.

It also allows for cryptographic attestations for tokens. If these big words don't mean anything to you, don't worry. But essentially, it's an extension to OIDC. And last one here, secure credential presentation. The WC3 created something called verifiable credentials a while ago.

It's really used for people. So if you get a degree from Stanford, they can mint that. And actually, you can have a signed JSON object that says you got a Bachelor's of Science degree. People are applying this to agentic systems, which is pretty cool.

So an agent could have this verifiable credential. Alice does work at WorkOS, Alice agent, and that could be passed on to other systems. So leveraging this existing verifiable credential work.

I'm sort of running short on time, so I'm going to skip forward a little bit of some of this stuff. In the industry, what we're seeing is that it's still really early. And the pattern that's really emerging is middleware for agents.

So rather than baking it into the application code, people are writing their agentic code and then leveraging services or open-source frameworks to actually create a trust boundary in between your agentic code and enterprise systems. You can't guarantee your agent is going to do anything very specific.

Even if you have evals around it or guardrails, people can still prompt inject. They can prompt hijack. You kind of have to treat your agent as untrusted. And so this idea of putting a layer in between that's managed, that can be dynamic, that can actually log and enforce things is the most common.

This is what we've done at WorkOS. We've built a bunch of stuff around here. We have an identity product called AuthKit. That's what I was mentioning for MCP. Cursor uses this today at WorkOS. We also have something called FGA for authorization, granular access to permissions.

And we actually run this middleware. We even have a system that can detect fraud, bots, abuse. So we found this middleware approach of layering something in between application code and kind of enterprise resources to be really, really powerful.

Microsoft is doing some cool stuff with their workload identities, actually. And I would also recommend going looking at Cloudflare's work around their MCP auth. Cloudflare is a fantastic networking stack solution. And because they're in the network layer, they already are doing this middleware stuff.

So to kind of wrap up, what's next? Well, I would say in the previous world, especially around enterprise IT, it was very black and white. There were trusted things and untrusted things. There were apps that were blessed by IT and apps that were maybe not blessed that were kind of using renegade products.

And you could kind of know what to trust and what not. Unfortunately, this is broken down. Everything's now in a gray area. Because you might have trusted products that now have agentic behavior and go do crazy things out in the world,right?

And you might have products that are actually haven't been trusted by IT, but you need to adopt them and bring them in and start using them more and more. Or even potentially interacting with existing products through agents that IT can't see.

Something like Claude's computer use,right? Or we'll kind of talk a little bit about Paul will talk about browser base, be able to log in to existing systems, but have agent experiences on top of it. Today, about 95% of traffic for most apps is people interfacing with them.

It's humans logging in and doing stuff today. And maybe about 5% is automated, or you might have an API where people are scripting stuff. And what I anticipate is this is actually going to transition, where it'll go from 95% maybe to 50%.

And then eventually, I think what we're going to see is that 95% of traffic and activity will actually be agents interfacing with products. And 5% will be us mere mortals doing it instead of agents. And this is actually going to be really profound.

It's going to allow for a brand new level of collaboration with machines, much more productivity, connecting to these third-party systems. It's going to be really, really, really powerful. But it requires us to have a totally new way of thinking about identity for agentic systems, for this to be secure and for not to erode user trust.

And I think it's just going to keep going from here. It's not going to stop. We're going to get more and more and more and more agents in the world. If we have billions of people on the planet today, I think we're going to have trillions of agents at some point going and doing things for us, kind of like a giant army of interns working, making us more productive.

I think that's really exciting. If you're interested in this and working on identity or you're building agents, what I would ask is just please send me a message or come talk with us. We're really excited to help support people building products like this and engineers.

And we would love to hear from you. So you can scan this and DM me on Twitter or just email me. Thanks so much for the time. Excited to chat with you.

Thank you so much, Michael. I have a super interesting question for you. You project 95% agentic interaction with these APIs. What's your timeline to 50%? How long do you think it's going to take us?

I think it depends on the product. Yeah, I haven't quite seen this yet. But you know how there's those restaurants that open just for doing delivery food? Ghost kitchens, you know? And then you're like, oh, I've ordered pizza from that place a bunch of times.

I'm going to go actually check it out. And you go in, you're like the only one there. I think it's going to be like that for software. There will be apps that we use exclusively through agents. Perplexity just launched the ability to book hotels through Perplexity.

And there's actually a company that provides an API for doing this that doesn't actually have a normal interface. They're like. So I think it's already happening. It's just like Alan Kay that said that future is already here.

Equally distributed.

It's just not equally distributed. So it's probably already happening amongst you.