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

[on-hold music] My talk that was up here said CIAM for AI.

Um, that's a bit of industry lingo. It stands for customer identity and access management. Really what I'm gonna be talking about here is auth login for agents. Um, we just heard from, uh, 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. Turns out AI products need identity and authentication, so we have a lot of experience seeing this.

So I wanna talk about, um, 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.

Um, I want you to imagine that you're, uh, building, uh, like a, a new chat tool, you know, kind of like a ChatGPT internally for one of your companies, and it's, uh, it's like an IT support tool.

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

Uh, let's delete some, some unused files, um, just to clear up some space." And the LLM thinks for a bit, and then it goes, "Yeah, certainly, sir. I went ahead and deleted your production database."

And this is, you know, a bit of a, 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, in your, um, your environment and 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? Um, agents are only as powerful as the systems you give them to. So inherently, there's this whole problem around kind of identity authentication, authorization for these systems.

And really what I wanna 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. A-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, uh, behave a little bit different than people. Um, you know, agents interact across many, many different tools, and specifically, they need to act on behalf of users. They're, they're similar to users, but, um, 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 i-identity stuff here I'm gonna talk about, they're similar to users, but, but a bit different.

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

Um, agents behave more like people than systems, so it's kind of this hybrid between a machine and a, and a person identity. And last, I'll just say here before diving into some, uh, 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, um, AI Engineer World Summit. But, um, uh, 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, like, wait, wait to do this and hope that it takes care of itself. We need to figure it out very soon. There's a lot of urgency around it.

So I'm gonna switch gears a little bit and talk about, first of all, why, um, identity for agents is hard. Like, 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 s- when I say that, I mean that they need to be able to sign in without necessarily typing into a web browser.

It's, it's different than, like, API auth 'cause you might want tokens to persist for a while but not forever. Um, you also might want your agent to actually use the front-end application and click around like a computer use system.

So they need to be able to sign in but at the same time, um, uh, not be signed out like a, like a normal user. Um, these sessions need to be long-lived.

There's a question around where these credentials should live, how to refresh them, how do agents store them securely. This is one of the hard problems around, around agents. You'll hear from Paul, uh, for browser-based in a little bit.

Um, that's a question, you know, for browser-based. Like, as people sign in and create sessions, where is that stored? How is it, 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. You know, on the one hand, um, you wanna scope down an agent's access to a very small amount.

It can only send a certain email or access a certain amount of data. But on the other hand, these non-determini- non-deterministic systems, you wanna give them access to be able to do a lot of things.

You know, you, you wanna actually give it access to your whole environment, your whole code base, maybe all of your bugs, all of your customer conversations. Um, so there's an authorization challenge around this where the existing, like, 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, um, you know, it, it, 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, you know, all of your code has to be reviewed by people.

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

Agents will be like that, right? Like, 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, it's really challenging actually to, to kind of bring identity and build these agentic systems. Um, I wanna propose a few architecture patterns here as to how we can actually do it.

Um, and these are things that I'm kind of seeing people start adapting out in the wild. Um, I'll go-- There's four of them. I'll go through them, uh, each individually.

Um, uh, these are not prescriptive by any means or, like, the be-all, end-all. It's just some things that I've, I've seen so far.

Cool. It's persona shadowing, delegation chains, capability tokens, and lastly, escalation to humans, human-in-the-loop.

All right. 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, that agent go do things on behalf of a user.

And this separation lets the system enforce stricter limits and access control around that, um, that actual, uh, shadow, shadow agent here. So you get this, like, isolation and accountability.

However, every action is still explicitly tied to an original human identity, which has the benefit there. Um, impersonation, just pure impersonation, gives too much power, um, 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, like, role templates off of this. This is probably the closest I've seen to people using agents-- i-iden-identity in the wild. You kinda take your enterprise IdP, and if there's, like, the Michael prime, the human Michael, I have, like, Agent One Michael and Agent Two 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, uh, identity for agents.

A second here is delegation chains. So if you've ever used JWTs, JSON Web Tokens, where there's, uh, they're signed, there's a cryptographic signature you can verify as you pass them along from system to system to system, um, you know, they're, 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, you know, verifiable permission and pass it on step by step.

Um, it, 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, um, uh, calling in that way, context passing.

Uh, and it's sort of like those shadow personas in the sense that you can, you can layer it on top of shadow, shadow users. Um, this can be supported by a few different things I'll talk about in a second, the, the UMA and OIDC extensions, um, but this is-- this kind of idea of delegating access step by

step by step, um, is, is becoming more popular. So again, you create that token, you pass it to different systems, and it can persist from, from one to the other.

Capability-based tokens. So essentially giving 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, es-essentially only for that thing.

You know, it's like a secure voucher, and those can expire after a certain amount of time. They can have scoped access. Um, these tokens can be self-contained and time-bound, so it can simplify how actually verification works on it.

And essentially, po-possession of that token, of that voucher, lets you prove that you're authorized to do something so you can pass it along. Kinda similar to the JWT stuff I mentioned earlier, but around capabilities versus roles or permissions.

You could even have a, a token like this minted for just one specific action, one specific API call. Um, if you're familiar with the Macaroons work that Google has done, this is kind of a version, a version of that.

And lastly here, escalation to humans, human-in-the-loop. Approve everything, right? Pretty simple to understand. When an agent needs to do something, it bubbles it up to you, and you hit Approve or Deny.

Um, problem with this is that, uh, p-- users get, you know, consent fatigue. Hit Approve, Approve, Approve, Approve. You know, if you have, like, a-- like, your Mac or your Windows laptop, and it's asking you, "Hey, do you wanna install this thing?"

Eventually, users just start hitting Approve on everything, just OAuthing, giving broad scopes. And so this actually doesn't really achieve, um, a secure model, even though from a compliance perspective it might be acceptable from IT.

So these are four techniques that people are, um, kind of adopting today, persona shadowing, delegation chains, capability tokens, and, you know, escalation to humans. Um, I think actually, like, the right approach is a combination of these things in different, different scenarios.

So depending on what application you're building, the access patterns, you know, who your customers are,

like, what, kind of what restrictions they have in their environment, um, you might adopt different pieces of these or all of them or maybe something totally different. Um, but they're just some of the architectural techniques that I'm seeing for kind of securing and bringing identity to agentic systems.

Okay. We're gonna keep going. I'm going pretty fast. [chuckles] Um, next I wanna talk about, um, one of my favorite things, which is acronyms.

Uh, we love acronyms at WorkOS. Um, there's acronyms everywhere in the identity and security space. I wanna 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 those-- some of these you certainly haven't. They're brand new. Uh, but I'll go through a few of them just so you'll have some, 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? Like, pretty much everybody. Yeah, OAuth. Uh, standard authorization, um, delegation system on the internet. Um, OpenID Connect, if you're not familiar with that, it's kind of like OAuth's, like, younger, hotter cousin or something.

Um, essentially allows for delegation of the identity and authorization. This has come to MCP relatively recently, so you can, through MCP, um, you can add a OAuth 2.1 authorization server, split the authorization from the resource server, and essentially create identity for MCP servers.

Um, OAuth, problem with it is it was built for human consent and not machines, so it kinda depends on, like, a, a user interface. We need to adapt it for machine auth.

It's also-- has static scopes. There's a lot of problems with it for i-- uh, agentic identity. But the benefit is everybody here knows it, right? And it's, 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 pr- pro- proactively grant another party, a requester, access to resources from a central authorization server.

Kind of like what we're seeing with the MCP work that I mentioned. Um, it essentially lets a user set policies around, like, 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. Um, so you know, for an AI agent, it could leverage this UMA to control maybe what a personal AI c- assistant is allowed to do.

It's externalizing the content in access policy rather than baking it into the OAuth consent dialogue that you approve specific things. It's, it's on a go-forward basis. User-managed access.

Another one is GNAP, GNAP, Grant Negotiation and Authorization Protocol. Um, 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 d- 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.

You know, maybe it's your Twitter account, it can post tweets. But we really need, like, dynamic tokens, or uh, dy- 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, um, interaction with, with agentic identity.

Um, uh, GNAP is actually a flexible framework for this. It was built before all the stuff around agents. Um, so it's like pretty, pretty cool. It's like 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, um, kind of lower on the implementation stack.

There's more. OIDCA, OpenID Connect for agents. Um, this is very much in the protocol phase. Um, it's an emerging protocol for OpenID Connect. I actually was told recently that the guy that's doing this is kind of, uh, doing it without the consent of the OIDC Federation, and so maybe it's not even real.

I don't know. Um, 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, um, cryptographic attestations for, for tokens. Um, if these big words don't mean anything to you, don't worry. Um, uh, 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, like get a, you know, a degree from Stanford, they can like mint that and actually you can have a signed JSON object that says, you know, you got a Bachelor's of Science degree.

Um, people are applying this to agentic systems, which is pretty cool. Um, so you know, an agent could have this like verifiable credential. You know, Alice does work at WorkOS, Alice agent, and that could be passed on to other systems.

So leveraging this existing, um, verifiable credential work.

I'm sort of running short on time, so I'm gonna skip forward a little bit of some of this stuff. Um, 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, in between your agentic code and enterprise systems.

You can't guarantee your agent is gonna do anything very specific. Even, you know, if you have evals around it or guardrails, people can still prompt inject, they can prompt hijack.

Um, you kinda have to treat your agent as like untrusted. And so this l- idea of like putting a layer in between that's managed, that can be dynamic, that can actually log and enforce things, um, is the most common.

This is what we've done at WorkOS. Um, we've built a bunch of stuff around here. We have an identity product called AuthKit. That's what I was mentioning for MTP.

Um, like Cursor uses this today at WorkOS. We also have something called, um, FGA for authorization, granular access to permissions. And we actually run this middleware. We even have a, 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. Um, Microsoft is doing some cool stuff with their workload identities actually.

And I would also recommend going looking, looking at Cloud- Cloudflare's work around their MCP Auth. Um, Cloudflare is a fantastic, like, networking, you know, stack solution. Um, and because they're in the network layer, they, they already are doing this middleware stuff.

So to kinda wrap up what's next. Well, I would say like in the previous world, especially around enterprise IT, it was very black and white. You know? Th- there were trusted things and untrusted things.

There were apps that were blessed by IT and apps that were maybe not blessed, that were kinda using renegade products. And you could, you could kinda know what to trust and whatnot.

Unfortunately, this has broken down. Everything's now in a gray area. 'Cause you might have trusted products that now have agentic behavior and can go do crazy things out in the world, right?

And you might have products that are actually like haven't been trusted by IT, but you need to adopt them and bring them in to start using them more and more.

Um, or even like potentially interacting with existing products through agen- agents that IT can't see. Something like Claude's computer use, right? Or we'll, we'll kind of talk a little bit about...

Paul, Paul will talk about browser-based. You know, be able to log in to existing systems, but have agent experiences on top of it. Today, about 95, you know, percent of traffic for most apps is people interfacing with them.

It's humans, you know, logging in and doing stuff today, and maybe about 5% is automated or m- you might have an API where people are scripting stuff. And what I anticipate is this is actually gonna transition, where it'll go, you know, from 95% maybe to 50%, and then eventually I think what we're gonna see is that like

95% of traffic and activity will actually be agents interfacing with products, and like 5% will be us mere mortals doing it instead of, instead of agents. And this is actually gonna be really profound.

It's gonna allow, allow for like a brand-new level of collaboration with machines, much more productivity. You know, connecting to these third-party systems. It's gonna 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, you know, user trust.

And I think it's just gonna keep going from here. It's not gonna stop. We're gonna get more and more and more and more agents in the world. If we have billions of people on the planet today, you know, I think we're gonna have like trillions of agents at some point going and doing things for us.

Um, kind of like a giant army of interns working, making us more productive. I think that's really exciting. Um, if you're interested in this and working on identity or you're building agents, um, 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.

Um, thanks so much for the time. Excited to chat with you. [audience applauding]

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

I, I think it depends on the product. Um, yeah, I mean, I, I haven't quite seen this yet, but, um, you, you know how there's those like restaurants that open just for doing delivery food?

Ghost kitchens.

Ghost kitchens, you know? Um, and then you like s- you're like, "Oh, I've, I've ordered pizza from that place a bunch of times. I'm, I'm gonna go actually check it out."

And you go in and you're like the only one there. I think it's gonna be like that for software. There will be apps that we use exclusively through agents.

Um, Perplexity just launched the ability to book, um, uh, hotels through Perplexity, and there's actually a company that provides an API for doing this that doesn't actually have like a normal interface.

They're like... So I, I think it's already happening, it's just, you know, like, like, uh, was it Alan Kay that said, "The future's already here-

Equally distributed

... it's just not equally distributed."

Yeah, yeah.

So it's probably already happening amongst you. [upbeat music]