COLIN SIDOTI: Hello, everyone. My name’s Colin Sidoti. I’m the cofounder of Clerk. We do developer tools for authentication. So sign up, sign in, user profile. We give you a set of react components that makes it really easy for you or your agent to get going in a new app. If you’re a B2B company, we also help with that onboarding. So typically after your B2B customers sign up, they need to tell you their company name, invite their team, set roles and permission, set up SAML, set up SCIM. We have a whole other suite of components for that. We call it B2B authentication. But none of you are here for that. You’re here for “Auth for the agentic era,” which I am very excited to talk about for a few reasons. First, I think it proves my thesis a little bit about auth. When we started seven years ago now, we had this belief that auth will just continue to evolve pretty ceaselessly.

And I’ve seen that my whole life. We started with username, password, then email password, then Sign in with Google, sign up with Facebook for like a minute there. Enterprise SSO, passkeys, crypto wallets, and here we are with Agent Auth. The other reason it’s really exciting is because the future has more agents than humans. I think if I said this a year ago, maybe people would have felt a little shaky about it, but today, everyone I believe pretty much believes this. And we’re seeing it very much in engineering where engineers are kind of spinning up many agents to help them with their coding tasks. And I think we’ve learned that agents need a secure way to access and transact with systems. And so the way engineers are doing it is like they’re getting API keys, sometimes they’re setting up sandboxes on entirely separate machines just so they’re fully sandboxed. But this isn’t easy to set up. And I think ultimately we need a better way to do it, so that agents can do more jobs.

I think it’s kind of a shame that AI is kind of bound to helping engineers right now. And so we want to think about: what can we do to unlock kind of the rest of workers to leverage AI in their day-to-day.

This talk is, unfortunately, it’s not a solution. It is a talk about the challenges. So what do we need to do to unlock that future? If there was a solution, I think you all would know about it already, but we’re not there. And so I’m just talking about more of what we’re working on. And I’m going to break that into four different components. First is identity. So who is the agent? Who does it represent? And who is vouching for it? Next is scoping. So what is the agent allowed to do and how are we constraining it? Then approval. So once we know what it’s going to do, who’s actually approving it to go do that thing? And then finally, enforcement. So how do we ensure that this agent that we approve to do this thing is actually doing that thing? And I’d say that all of these kind of need to be solved before agents really proliferate a lot more than they have so far.

So diving straight in, agent identity. Who is the agent? Who does it represent? And who vouches for it?

There are two types of agents. One you’re probably familiar with, and so I started with it, delegated agents, right? Agents that are working on behalf of humans. I want an agent to go access this service for me and do something on my behalf. I’m prompting it to go do that. Pretty straightforward case. It’s the one that people are most familiar with.

The other one we talk about as autonomous agents. So agents working on their own. I don’t like talking about it this way. I believe that typically when we talk about autonomous agents, they’re actually agents working on behalf of an organization. And the canonical use case is like, we’re setting up a chatbot to talk with our customers and that agent needs access to like the customer records to be able to help them and so on. And so you don’t want that agent like assuming an employee’s identity. You want it to have its own identity within your systems. But that’s still an agent that’s delegated. It’s on behalf of the organization rather than the human.

It’s not quite on their own. I know we’re now, I think it’s 120 days past the singularity at this conference. And so despite that, they’re not sentient yet and like totally going on their own. So those are the two types of agents. But then the question is, okay, who’s allowed to vouch for these agents and say confidently this is who the agent is. And for that, it’s pretty convenient because it’s the same parties that vouch for humans and that’s the authentication problem. And so I’m quite familiar with it. There’s three different groups.

The first is services. And I’m drawing parallels in each of these sections. And so, services we use in-house authentication as an example. So that’s like, you’re going to a service and you’re signing in with email and password. The service is keeping track of your password. And so it says, okay, that’s a password match. You are who you say you are. The same concept kind of exists. And it’s really the predominant thing that’s used today for agents is like API keys. And so people will go and provision an API key for their agent and then the service itself is tracking who those API keys belong to.

Second is identity providers. So if you work at a larger enterprise, you’re not actually allowed to sign in with email and password. They make you go through Okta or Microsoft Entra or Google Workspace. Unlike service, like in-house authentication for agents, we don’t see any of that really in the wild today on the enterprise side. However, we do hear very loudly that the enterprises want this. They want to know very confidently when their employees are delegating agents on their behalf and so forth. They want that governance, they want that oversight. And so this is something that’s like going to happen. I will bet a lot of money on it.

And then finally, trusted third parties. So this is kind of the third piece that’s on a typical sign-in form, Sign in with Google. Generally speaking, you are using this if you’re not using enterprise SSO. I think our number is like 70% today. We’ll use this rather than email and password. When we started Clerk, it was just 45%. And so it’s just flying away. But this same concept of like a centralized federated identity provider, we think is going to exist for agents, and fun enough, one landed yesterday. So Stripe Projects, if you watched the keynote, they do this cool thing where, if Stripe Projects is… So Clerk is part of Stripe Projects, and I’m just going to use that example. If a Stripe Projects user is provisioning Clerk, Stripe will actually tell us who exactly the user is so we can provision an account for them. And we’re trusting Stripe to tell us a valid email that they have verified themselves. And so this is like the first example I think I’ve seen where this is happening in the wild. And it’s really cool. If you haven’t used Stripe Projects yet, the amount of friction that it removes just by getting rid of the sign-up step at each service, you wouldn’t expect it. You’re so used to signing up for all these things, but it is just so much easier, and just watching it fly and seeing the agent get through and more steps without needing any intervention from you is very impressive.

We broadly know how agent identity is going to work. There’s that one piece with like agent, or enterprises delegating agents, that like, it’s not quite solved yet, but we roughly know exactly how it’s going to happen. So I like to say, “This is solved. This is not the thing. If you’re wondering why MCP Auth came out like early 2025, but Agent Auth isn’t done yet, this isn’t the thing holding us back.”

Agent scoping, however, might be. So what is agent scoping? We’re talking about what is the agent allowed to do and how are we constraining it? I think when people talk about how agents should be scoped, kind of the first thing that comes up is by role. And this is a case where you’re literally giving an agent your username password and saying, “Go sign in as me and do something on my behalf.” Pretty well understood that this is like not the best way to do things, not the safest way to do things. Generally speaking, you don’t want your agent to have all of your privileges. You want it to have a subset of privileges. And so this is like well understood to be bad. And then the thing that people jump to is by permissions. And so if you’re familiar with MCP Auth at all, this is effectively what MCP Auth does. They piggyback on the OAuth spec and say, instead of granting the agent everything, let’s send you through an OAuth consent flow and you’ll pick off like exactly which permissions you want to give the agent. So you can imagine in Google, like you’d be picking a read email or write email or read calendar or write calendar and trying to give it just a constrained set.

The issue with that is standing privilege, which is a little bit of security lingo, but basically once you give it that permission, it has that permission forever. And by and large, like if I’m telling an agent, “Hey, I need to add something to my calendar.” And then like five days from now I’m like, “Hey, I need to make some slides.” And something wrong happens, right? It’s an LLM, it’s not deterministic, and it starts messing with my calendar. I’m like kind of upset because that has nothing to do with drafting slides. And so somehow we want to constrain things more. And so the kind of like obvious answer to pull from our hat is like, we need to find a way to do this by task. In an LLM, you’re prompting, it’s like there’s a unit of work. You’re saying go do this thing, or maybe your agent is telling another agent to go do this thing.

We’re able to break things down by tasks, but what we don’t know is like very specifically, like how should we specify those tasks to work into a Agent Auth system? And so this is my first mystery system, and it’s one that I don’t have an answer to, right? So I’m just going to point at a couple specs, areas where we’re working on it.

First is called AgentPass. It’s from Clerk. And we go about this kind of by not trying to solve it. We say, if we create like a system of checks and balances, like we know that there’s going to be one party approving the task and then the service is also going to need to let the task happen. And so like, if we leave it undefined, then maybe the person approving the task or the service will say, “You know what? That’s too broadly scoped of a task. We’re not going to let it happen.”

There’s another spec called Mission-Bound OAuth written by a guy named Karl McGuinness. He worked at Okta for like a decade, was their chief product architect. He’s taking the opposite approach, like how can we super rigidly define the task lifecycle? And that was, and he does like tasks and subtasks and like when they end and so forth. That was adopted by another spec called AAuth that this other identity guy, has been in the space for 15 years, wrote. And the difference between these two is that AAuth kind of fills in all the other gaps. Mission-Bound OAuth is like really just the spec for, “How do I define a task?” AAuth kind of solves the other problems of scoping and enforcement and so on, or at least thinks about and contemplates the other problems. And so I guess the takeaway I want you to have is like, okay, this is a problem that exists. These are some things that I could read to learn more about it. But yeah, I don’t have the exact answer except that we kind of know that like roles or permissions, like those aren’t going to be the answers. Somehow we need to constrain it more. Who approves what the agent is about to do and how? The first part of this is, well, where do we expect approvals to happen? So we have now a task that’s scoped and someone, somehow that task needs to get approved. And so we are going to, thankfully say it’s the exact same places that can vouch for approvals, and drawing parallels again kind of one by one.

The services—approval is an authorization problem. Services are very used to doing in-house authorization, right? Kind of countless examples, but like the internal RBAC system is a way to like preapprove certain permissions. The scopes on API queues, again, it’s preapproving on certain tasks. And that API keys is basically how we’re seeing, or API key scoping rather, is how we’re seeing engineers do this today, and it’s all preapprovals. There’s not much in the way of like, “Okay, agent is doing this task. How do we, point in time, get additional approval to do it?” And yes, but we do know that like, we don’t know how that happens, but we know where it happens. It can happen at the service level. For the same reasons we talked about before, enterprises being enterprises, they don’t want their employees kind of delegating agent tasks or agent approvals within… Well, they don’t want the employees doing it themselves without the enterprise having oversight and approval on it or governance on it.

And so somehow, some way, services aren’t just going to be allowed to run an approval dashboard; it’s also going to get foisted up into identity providers. Last one, trusted third parties. I was trying to think of a case where like trusted third parties are not just doing identity regularly, but actually an approval action. And I came up with Link, where they’re approving a purchase. Again, we think the same concept is going to happen with agents. And of course, again, it did with Stripe Projects, where Stripe is not just telling Clerk, “Hey, this user wants a Clerk account.” It’s also saying “They want a Clerk account and they want to provision this plan. Will you let it happen?” And so, same exact case as agent identity: services, and third parties we’re actually seeing in the wild, identity providers, we’re hearing very loudly that it needs to happen and we don’t have a spec yet.

The real challenge on approvals is like, how do they happen? And that’s what’s really like undefined still. We talked about preapprovals. There’s kind of generally agreement that preapprovals are like not good enough. Somehow we need to get point-in-time approvals for certain sensitive actions and there isn’t spec for it. So this is my mystery system number two. Clerk with AgentPass, we took a very similar approach of like not solving it, but giving a place for it to be solved. And so we say, “Whether the service or the identity provider or the third party is building an approval dashboard, like they will be considered an authority.” An authority is where approvals happen, and it’s kind of up to the authority to decide, “Do I need a human in the loop for this task or do I not?” And if not, how to do that? And our mindset is like, well, since we don’t really know how this happens, we should create an environment where like a bunch of different authority startups can kind of compete against each other and figure out the best way to do it, instead of trying to be too rigid with it.

Other ones working on this, there’s a lot. So MCP does things at the service level with an additional consent screen that has the standing privilege problem. I think that’s broadly like why this is an issue still. And then Okta and AAuth have their own spins at this as well. More at the protocol level, they’re also not really saying how it should happen. I think everyone except MCP is kind of taking this tact of, let others kind of decide how approval should happen, whether a human should be brought in the loop or not. You can imagine that, like an enterprise is going to approach that problem very differently than anyone, than like a consumer tool.

Final one is agent enforcement. And so this one I think is talked about a lot less. It’s more of a gradient in terms of, to what extent do we need it? I think we can actually launch like a V1 of Agent Auth before this is done, but what am I talking about? So how do we ensure that the agent only does what was approved and how do we do that in real time, specifically if we’re the service? And so it’s very clear that services will want to be able to operate some kind of enforcement engine. We don’t know the exact shape of this, but basically what we know is someone’s going to say, “Okay, I want my agent to do this thing.” They’re going to get it approved, or they’re going to scope it, they’re going to get it approved, and then they’re going to bring it to a service or the agent is going to bring it to a service and say, “Okay, I’m now executing this task.” And the service doesn’t just want to see that and then let any API requests through, right?

They want to make sure that the API requests that are happening actually map to the task that was approved. And you’ll see, so I was talking about the gradient, like if you talk to an ecommerce company, they’re maybe a little more okay with like, “Well, if extra stuff gets bought and we have to refund it, it’s not that big of a deal.” But if you talk to like a bank, clearly they’re going to want more enforcement on moving money and stuff, making sure that what was approved is actually the API requests that are happening. And so how is this going to happen?

I have it listed as mystery system three here, but the core element is pretty obvious. It’s just that the service needs a way of verifying confidently that what task was approved, right? And so at some point, we need the task to be signed somehow cryptographically so that we can, or the service can tell, “Okay, this is what was approved. Now I can kind of map the session and see what the agent is doing, so that if it goes off the rails, I can stop it.” Both AgentPass and AAuth make this possible. So AAuth is adopting missions, so we both believe that this is going to happen. We go about it in slightly different ways, but neither of us are actually trying to solve the final problem of how do we build that system. I think for the engineers in the audience, it doesn’t sound like the hardest thing to build, right? Like just you get the session, you look at all the requests, you run an LLM against… It’ll work. A little hand wavy, but like doing something, it should be pretty feasible to make it come together, as long as we know confidently what the task is. And this to me is another big kind of issue with MCP Auth. It doesn’t actually carry… It doesn’t have any concept of a task. And so, when the agent is doing something with a MCP-generated OAuth credential, the service has no idea why they’re there. They just know that X, Y, Z permissions were approved. And that’s just not enough to like build a meaningful enforcement layer.

So these are my three keys to agent proliferation. So task scoping, the approval mechanism, and the enforcement engine.

One thing that’s I think particularly striking, especially right now, is I don’t think any of us would have guessed that—early 2025, MCP Auth is taking off and people are excited about it—I don’t think anyone would guess it would still be here Q2 of 2026. And a lot of what’s going on is just like debate about the spec and not too much like, let’s just build it and see what happens. One thing, and I guess I’m in finding myself, especially with the launch of Stripe Projects, I’m finding myself increasingly feeling like we might not solve it at the spec level. We might just solve it at the like, Stripe is just going to do Stripe Projects and agentic wallets, and they’re going to get a nice consortium of companies together to put a stake in the ground and say, “This is like a V1.” And yeah, I kind of think that’s what’s going to happen now if I’m very much speculating.

As fun as the spec level debates are, I think we’re seeing just putting a stake in the ground is seemingly getting traction faster from my perspective. And we really enjoyed collaborating on the Stripe Projects spec, and the way kind of identity became part of it was very exciting to us.

I have a quick bonus slide here. The really exciting thing about Agent Auth, it’s like we can talk about it in the context of Agent Auth, but if you think about these three issues, what we’re doing is we’re solving… We’re creating a common interface to authorization. So how can I get access to do an arbitrary task within an arbitrary service? That has never existed before. And that’s kind of unlike authentication, right? If you try to teach an agent how to sign in to a sign-in form, it’s probably going to work on like 95% of the internet, but there is no common interface to authorization. And it’s certainly very fun to think about it through the lens of Agent Auth, because you’re going to have agents generating subagents and subagents, and just like running around systems, and so on.

But I guess one thing I would like to try to impress upon you is like, we have no idea the efficiency gains that are going to come from that. It’s something that we’ve just not really been able to contemplate because I mean, if you go to five different companies, they all are doing authorization in five completely different ways. It’s like a space, a startup space that just like hasn’t worked, authorization-as-a-service. There’s a famous Google whitepaper called Zanzibar that seven years ago-ish, people were really excited everyone’s going to adopt this format, and we’re going to have a standardized spec. And it just never landed. And I think now with agents, we have this real incentive to figure it out—what is the common interface to authorization going to be? And I think it’s going to unlock, much like every new AI model, it’s just going to unlock more than we can kind of imagine.

People are going to find very creative ways to use it. And so I’d encourage you to just think about that a little more.