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

Channel: aiDotEngineer

Published at: 2025-07-21

YouTube video id: D4Dswf-__RM

Source: https://www.youtube.com/watch?v=D4Dswf-__RM

[Music]
My talk that was up here said Syiam for
AI. Um 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 O login for
agents. Um, we just heard from uh from
someone from Hex. Hex is actually a work
OS customer. We provide identity
services to lots and lots of different
SAS 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'm going to
talk about um how you can bring identity
specifically to aentic 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
like a a new chat tool, you know, kind
of like a chat GBT internally for one of
your companies and it's uh 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, 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 has 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
say yeah certainly sir I went ahead and
deleted your production database
and this is you know a bit of a
fictitious situation but it's not too
far off from reality where these
nondeterministic agentic systems can go
off the rails and have pretty
destructive actions in in your um 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 course
or your Slack instance or 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 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 SAS
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 the identity
stuff here I'm going to 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
off anybody heard about that before like
certificate based off 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
in systems. So it's kind of this hybrid
between a machine and 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
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 going to 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 when I say that I mean that
they need to be able to sign in without
necessarily typing into a web browser.
This is different than like API off
because 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 to agents store them securely.
This is one of the hard problems around
agents. You'll hear from Paul for
browser base in a little bit. Um, that's
a question, you know, for browser base,
like as people sign in and create
sessions, where is that stored? How's it
how's 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 want to scope down an agents access
to very small amount. It can only send a
certain email or access a certain amount
of data. But on the other hand these
non-determinist nondeterministic systems
you want to give them access to do a lot
of things. you know, you you want to
actually give it access to your whole
environment, your whole codebase, maybe
all of your bugs, all of your customer
conversations. Um, so there's an
authorization challenge around this
where the existing like lease 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's 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 sock 2 compliance, you know, all of
your code has to be reviewed by people.
What happens if 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 error is human but to screw up 10,000
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 want to
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 beall 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
in 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
RO templates off of this. This is
probably the closest I've seen to people
using agents identity in the wild. You
kind of 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 scope
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 they're 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
that 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 calling in that way context
passing uh and it's sort of like those
shadow personas in the sense that you
can you can layered 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 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
given 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 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 timebound. 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 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 hit approve or
deny. Um problem with this is that uh
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 want to install
this thing? Eventually, users just start
hitting approve on everything, just
ooth, 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 going to keep going. I'm going
pretty fast. Um, next I want to talk
about um one of my favorite things which
is acronyms.
Uh, we love acronyms at work OS. Um,
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 aic 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 OOTH.
How many people have built something
with OOTH? Like pretty much everybody.
Yeah. OOTH. Uh standard authorization um
delegation system on the internet. Um
Open ID Connect. If you're not familiar
with that, it's kind of like OOTH's like
younger hotter cousin or something. Um
essentially allows for delegation of the
identity and authorization. This has
come to MTP relatively recently. So you
can through MCP um you can add a OOTH
2.1 authorization server split the
authorization from the resource server
and essentially create identity for MCP
servers. Um OOTH problem with it is it
was built for human consent and not
machines. So it kind of depends on like
a a user interface. We need to adapt it
for machine off. It's also has static
scopes. There's a lot of problems with
it for aentic 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 OOTH for
aentic identity
user managed access. This is actually an
extension to OOTH that allows a user or
resource owner to pro proactively grant
another party a requesttor 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 or
like what an agent can do but uses the
ooth based handshake to enforce those
policies on resource APIs. as an
extension to OOTH 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 to control maybe
what a personal AI assistant is allowed
to do. It's externalizing the consent
and access policy rather than baking it
into the OOTH consent dialogue that you
approve specific things. It's it's on a
go forward basis user managed access.
Another one is GNAP. GANAP 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 designed
actually for dynamic negotiation of
token scopes. So, we've all probably
seen in OOTH, 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
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 a gentic identity.
Um, Gap 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
wellbaked. 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, Open ID Connect for
agents. Um, this is very much in the
protocol phase. Um, it's an emerging
protocol for open ID 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. U this is how
cutting edge this stuff is. But
essentially allows you to bake agent
identity claims and delegation chains
into open ID connect more natively. So
people are really trying to bring open
ID 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, 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 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 work OS 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
going to 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 to 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 going to do anything very
specific. Even you know if you have eval
around it or guardrails, people can
still prompt inject they can prompt
hijack. Um you kind of have to treat
your agent as like untrusted. And so
this 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 work OS. Um
we've built a bunch of stuff around
here. We have an identity product called
OKIT. That's what I was mentioning for
MTP. Um like cursor uses this today at
work OS. 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 on their MCP off. 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 kind of 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, there
were trusted things and untrusted
things. There were apps that were
blessed by it and apps that were maybe
not blessed that you're kind of using
renegade products and you could you
could kind of know what to trust and
whatnot. 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 like haven't been trusted by
it, but you need to adopt them and bring
them in and start using them more and
more. Um, or even like potentially
interacting with existing products
through a agents that it can't see.
Something like Claw's computer use,
right? Or we'll kind of talk a little
bit about Paul talk about browser base,
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 you might have an API or
people are scripting stuff. And what I
anticipate is this is actually going to
transition where it'll go, you know,
from 95% maybe to 50% and then
eventually I think what we're going to
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 going to 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 going to be really,
really, really powerful, but it requires
us to have a totally new way of thinking
about identity for agent systems for
this to be secure and for not to erode,
you know, 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, you know, I
think we're going to 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.
>> Thank you so much, Nicole. 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 going to take
us?
>> I I think it depends on the product. Um,
yeah. I mean, I I haven't quite seen
this yet, but um you know how there's
those like restaurants that open just
for doing delivery food?
>> Ghost.
>> Ghost kitchens, you know? Um, and then
you like you're like, "Oh, I've ordered
pizza from that place a bunch of times.
I'm gonna 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.
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 K
that said, the future is already here.
It's just not equally distributed. So,
it's probably already happening amongst
you.
[Music]