WEBVTT 1 00:00:10.400 --> 00:00:14.800 Hello, everyone. My name's Colin Sidoti. I'm the cofounder of Clerk. 2 00:00:15.700 --> 00:00:20.340 We do developer tools for authentication. So sign up, sign in, 3 00:00:20.400 --> 00:00:21.140 user profile. 4 00:00:21.140 --> 00:00:25.040 We give you a set of react components that makes it really easy for you or your 5 00:00:25.100 --> 00:00:29.680 agent to get going in a new app. If you're a B2B company, 6 00:00:29.740 --> 00:00:31.060 we also help with that onboarding. 7 00:00:31.140 --> 00:00:33.780 So typically after your B2B customers sign up, 8 00:00:33.920 --> 00:00:37.780 they need to tell you their company name, invite their team, 9 00:00:37.860 --> 00:00:39.900 set roles and permission, set up SAML, set up SCIM. 10 00:00:40.400 --> 00:00:42.600 We have a whole other suite of components for that. 11 00:00:42.660 --> 00:00:46.480 We call it B2B authentication. But none of you are here for that. 12 00:00:46.540 --> 00:00:49.580 You're here for "Auth for the agentic era, 13 00:00:51.200 --> 00:00:55.980 which I am very excited to talk about for a few reasons. First, 14 00:00:58.360 --> 00:01:00.620 I think it proves my thesis a little bit about auth. 15 00:01:01.360 --> 00:01:03.640 When we started seven years ago now, 16 00:01:04.540 --> 00:01:08.300 we had this belief that auth will just continue to evolve pretty ceaselessly. 17 00:01:09.460 --> 00:01:12.200 And I've seen that my whole life. We started with username, password, 18 00:01:13.080 --> 00:01:15.320 then email password, then Sign in with Google, 19 00:01:16.340 --> 00:01:20.820 sign up with Facebook for like a minute there. Enterprise SSO, 20 00:01:21.460 --> 00:01:23.480 passkeys, crypto wallets, 21 00:01:24.340 --> 00:01:26.960 and here we are with Agent Auth. 22 00:01:28.600 --> 00:01:32.680 The other reason it's really exciting is because 23 00:01:34.020 --> 00:01:37.660 the future has more agents than humans. I think if I said this a year ago, 24 00:01:37.800 --> 00:01:41.660 maybe people would have felt a little shaky about it, but today, 25 00:01:43.060 --> 00:01:45.220 everyone I believe pretty much believes this. 26 00:01:45.640 --> 00:01:49.540 And we're seeing it very much in engineering where engineers are kind of 27 00:01:49.600 --> 00:01:53.380 spinning up many agents to help them with their coding tasks. 28 00:01:55.080 --> 00:01:59.560 And I think we've learned that agents need a secure way to 29 00:01:59.920 --> 00:02:02.160 access and transact with systems. And so 30 00:02:04.820 --> 00:02:07.480 the way engineers are doing it is like they're getting API keys, 31 00:02:07.480 --> 00:02:10.900 sometimes they're setting up sandboxes on entirely separate machines just so 32 00:02:10.960 --> 00:02:13.420 they're fully sandboxed. 33 00:02:15.380 --> 00:02:16.860 But this isn't easy to set up. 34 00:02:17.020 --> 00:02:19.560 And I think ultimately we need a better way to do it, 35 00:02:19.960 --> 00:02:24.920 so that agents can do more jobs. I think it's kind of 36 00:02:24.980 --> 00:02:29.040 a shame that AI is kind of bound to helping engineers right now. 37 00:02:29.440 --> 00:02:30.720 And so we want to think about: 38 00:02:31.360 --> 00:02:35.840 what can we do to unlock kind of the rest of workers to leverage AI in 39 00:02:36.500 --> 00:02:40.660 their day-to-day. This talk is, 40 00:02:41.660 --> 00:02:45.700 unfortunately, it's not a solution. It is a talk about the challenges. So 41 00:02:48.180 --> 00:02:52.000 what do we need to do to unlock that future? 42 00:02:54.020 --> 00:02:56.320 If there was a solution, I think you all would know about it already, 43 00:02:56.960 --> 00:02:57.760 but we're not there. 44 00:02:57.760 --> 00:03:00.040 And so I'm just talking about more of what we're working on. 45 00:03:01.900 --> 00:03:04.540 And I'm going to break that into four different components. 46 00:03:06.180 --> 00:03:10.640 First is identity. So who is the agent? 47 00:03:10.700 --> 00:03:15.580 Who does it represent? And who is vouching for it? Next is scoping. 48 00:03:15.760 --> 00:03:18.900 So what is the agent allowed to do and how are we constraining it? 49 00:03:20.200 --> 00:03:23.120 Then approval. So once we know what it's going to do, 50 00:03:23.480 --> 00:03:28.140 who's actually approving it to go do that thing? And then finally, enforcement. 51 00:03:28.320 --> 00:03:33.060 So how do we ensure that this agent that we approve to do this thing is 52 00:03:33.360 --> 00:03:34.660 actually doing that thing? 53 00:03:36.020 --> 00:03:40.960 And I'd say that all of these kind of need to be solved before agents really 54 00:03:41.060 --> 00:03:43.660 proliferate a lot more than they have so far. 55 00:03:45.420 --> 00:03:50.120 So diving straight in, agent identity. Who is the agent? 56 00:03:50.560 --> 00:03:52.620 Who does it represent? And who vouches for it? 57 00:03:54.440 --> 00:03:58.920 There are two types of agents. One you're probably familiar with, 58 00:03:58.980 --> 00:04:02.100 and so I started with it, delegated agents, right? 59 00:04:02.220 --> 00:04:04.880 Agents that are working on behalf of 60 00:04:05.040 --> 00:04:08.220 humans. 61 00:04:08.220 --> 00:04:12.760 I want an agent to go access this service for me and do something on my behalf. 62 00:04:13.040 --> 00:04:15.460 I'm prompting it to go do that. Pretty straightforward case. 63 00:04:15.560 --> 00:04:20.480 It's the one that people are most familiar with. The other one we 64 00:04:20.560 --> 00:04:24.760 talk about as autonomous agents. So agents working on their own. 65 00:04:26.300 --> 00:04:27.660 I don't like talking about it this way. 66 00:04:28.820 --> 00:04:31.400 I believe that typically when we talk about autonomous agents, 67 00:04:31.480 --> 00:04:34.460 they're actually agents working on behalf of an organization. 68 00:04:34.780 --> 00:04:36.720 And the canonical use case is like, 69 00:04:38.360 --> 00:04:43.320 we're setting up a chatbot to talk with our customers and that agent 70 00:04:44.480 --> 00:04:48.280 needs access to like the customer records to be able to help them and so on. 71 00:04:48.420 --> 00:04:51.680 And so you don't want that agent like assuming an employee's identity. 72 00:04:51.800 --> 00:04:56.500 You want it to have its own identity within your systems. But 73 00:04:58.960 --> 00:05:00.520 that's still an agent that's delegated. 74 00:05:00.580 --> 00:05:03.720 It's on behalf of the organization rather than the human. It's not quite on 75 00:05:03.760 --> 00:05:04.700 their own. I know we're now, 76 00:05:05.420 --> 00:05:09.620 I think it's 120 days past the singularity at this conference. And so 77 00:05:11.680 --> 00:05:15.480 despite that, they're not sentient yet and like totally going on their own. 78 00:05:16.040 --> 00:05:19.980 So those are the two types of agents. But then the question is, okay, 79 00:05:20.060 --> 00:05:24.500 who's allowed to vouch for these agents and say confidently this is 80 00:05:26.660 --> 00:05:29.380 who the agent is. And for that, 81 00:05:30.260 --> 00:05:34.460 it's pretty convenient because it's the same parties that vouch for humans 82 00:05:35.500 --> 00:05:38.460 and that's the authentication problem. 83 00:05:39.400 --> 00:05:40.600 And so I'm quite familiar with it. 84 00:05:40.960 --> 00:05:43.700 There's three different groups. The first is services. 85 00:05:46.360 --> 00:05:49.800 And I'm drawing parallels in each of these sections. And so, 86 00:05:50.760 --> 00:05:54.420 services we use in-house authentication as an example. So 87 00:05:55.960 --> 00:05:56.440 that's like, 88 00:05:56.440 --> 00:05:58.860 you're going to a service and you're signing in with email and password. 89 00:05:59.680 --> 00:06:02.340 The service is keeping track of your password. And so it says, okay, 90 00:06:02.400 --> 00:06:04.580 that's a password match. You are who you say you are. 91 00:06:05.460 --> 00:06:06.940 The same concept kind of exists. 92 00:06:07.000 --> 00:06:11.700 And it's really the predominant thing that's used today for agents is like API 93 00:06:11.880 --> 00:06:12.320 keys. 94 00:06:12.320 --> 00:06:16.390 And so people will go and provision an API key for their agent and then the 95 00:06:16.520 --> 00:06:20.590 service itself is tracking who those API keys belong to. 96 00:06:21.550 --> 00:06:24.450 Second is identity providers. 97 00:06:24.710 --> 00:06:27.050 So if you work at a larger enterprise, 98 00:06:27.460 --> 00:06:30.070 you're not actually allowed to sign in with email and password. 99 00:06:30.130 --> 00:06:33.850 They make you go through Okta or Microsoft Entra or Google 100 00:06:33.870 --> 00:06:37.690 Workspace. Unlike service, 101 00:06:37.770 --> 00:06:40.290 like in-house authentication for agents, 102 00:06:40.650 --> 00:06:45.070 we don't see any of that really in the wild today on the enterprise side. 103 00:06:45.350 --> 00:06:49.170 However, we do hear very loudly that the enterprises want this. 104 00:06:49.690 --> 00:06:51.610 They want to know very confidently 105 00:06:53.110 --> 00:06:56.960 when their employees are delegating agents on their behalf and so forth. 106 00:06:56.980 --> 00:06:58.640 They want that governance, they want that oversight. 107 00:06:58.840 --> 00:07:00.960 And so this is something that's like going to happen. 108 00:07:02.240 --> 00:07:06.440 I will bet a lot of money on it. And then finally, trusted third parties. 109 00:07:07.080 --> 00:07:10.200 So this is kind of the third piece that's on a typical sign-in form, 110 00:07:10.280 --> 00:07:12.600 Sign in with Google. Generally speaking, 111 00:07:12.800 --> 00:07:16.280 you are using this if you're not using enterprise SSO. 112 00:07:17.200 --> 00:07:19.440 I think our number is like 70% today. 113 00:07:19.600 --> 00:07:22.680 We'll use this rather than email and password. When we started Clerk, 114 00:07:22.800 --> 00:07:25.120 it was just 45%. And so it's just flying away. 115 00:07:26.020 --> 00:07:30.880 But this same concept of like a centralized federated identity provider, 116 00:07:31.080 --> 00:07:35.320 we think is going to exist for agents, and fun enough, 117 00:07:36.320 --> 00:07:39.480 one landed yesterday. So Stripe Projects, 118 00:07:40.680 --> 00:07:44.320 if you watched the keynote, they do this cool thing where, 119 00:07:45.080 --> 00:07:48.200 if Stripe Projects is... So Clerk is part of Stripe Projects, 120 00:07:48.280 --> 00:07:49.440 and I'm just going to use that example. 121 00:07:49.800 --> 00:07:52.320 If a Stripe Projects user is provisioning Clerk, 122 00:07:52.920 --> 00:07:57.320 Stripe will actually tell us who exactly the user is so we can provision an 123 00:07:57.360 --> 00:07:58.193 account for them. 124 00:07:58.240 --> 00:08:02.680 And we're trusting Stripe to tell us a valid email 125 00:08:03.320 --> 00:08:04.840 that they have verified themselves. 126 00:08:05.520 --> 00:08:10.040 And so this is like the first example I think I've seen where this is happening 127 00:08:10.120 --> 00:08:14.240 in the wild. And it's really cool. If you haven't used Stripe Projects yet, 128 00:08:15.960 --> 00:08:20.360 the amount of friction that it removes just by getting rid of the sign-up step 129 00:08:20.440 --> 00:08:22.920 at each service, you wouldn't expect it. 130 00:08:23.080 --> 00:08:25.120 You're so used to signing up for all these things, 131 00:08:25.680 --> 00:08:27.560 but it is just so much easier, 132 00:08:27.560 --> 00:08:32.000 and just watching it fly and seeing the agent get through and more steps without 133 00:08:32.080 --> 00:08:36.960 needing any intervention from you is very impressive. We 134 00:08:37.280 --> 00:08:41.320 broadly know how agent identity is going to work. 135 00:08:42.840 --> 00:08:46.480 There's that one piece with like agent, or enterprises delegating agents, 136 00:08:46.560 --> 00:08:48.160 that like, it's not quite solved yet, 137 00:08:48.320 --> 00:08:51.680 but we roughly know exactly how it's going to happen. So I like to say, 138 00:08:51.680 --> 00:08:51.680 "This is solved. This is not the thing. 139 00:08:51.680 --> 00:08:51.680 If you're wondering why MCP Auth came out like early 2025, 140 00:08:51.680 --> 00:08:52.353 but Agent Auth isn't done yet, this isn't the thing holding us back." 141 00:09:03.680 --> 00:09:08.640 Agent scoping, however, might be. So what is agent scoping? 142 00:09:08.960 --> 00:09:13.240 We're talking about what is the agent allowed to do and how are we constraining 143 00:09:13.280 --> 00:09:14.113 it? 144 00:09:16.880 --> 00:09:19.720 I think when people talk about how agents should be scoped, 145 00:09:19.880 --> 00:09:22.960 kind of the first thing that comes up is by role. 146 00:09:23.840 --> 00:09:28.750 And this is a case where you're literally giving an agent your 147 00:09:28.870 --> 00:09:30.290 username password and saying, "Go sign in as me and do something on my behalf." 148 00:09:33.190 --> 00:09:37.090 Pretty well understood that this is like not the best way to do things, 149 00:09:37.830 --> 00:09:40.270 not the safest way to do things. Generally speaking, 150 00:09:40.330 --> 00:09:43.010 you don't want your agent to have all of your privileges. 151 00:09:43.010 --> 00:09:44.610 You want it to have a subset of privileges. 152 00:09:44.670 --> 00:09:46.570 And so this is like well understood to be bad. 153 00:09:47.390 --> 00:09:50.630 And then the thing that people jump to is by permissions. 154 00:09:51.190 --> 00:09:53.250 And so if you're familiar with MCP Auth at all, 155 00:09:54.270 --> 00:09:56.190 this is effectively what MCP Auth does. 156 00:09:56.670 --> 00:10:00.050 They piggyback on the OAuth spec and say, 157 00:10:00.310 --> 00:10:02.110 instead of granting the agent everything, 158 00:10:02.890 --> 00:10:07.150 let's send you through an OAuth consent flow and you'll pick off like exactly 159 00:10:07.270 --> 00:10:10.770 which permissions you want to give the agent. So you can imagine in Google, 160 00:10:10.830 --> 00:10:15.430 like you'd be picking a read email or write email or read calendar or write 161 00:10:15.450 --> 00:10:19.270 calendar and trying to give it just a constrained set. 162 00:10:21.730 --> 00:10:25.150 The issue with that is standing privilege, 163 00:10:25.250 --> 00:10:26.890 which is a little bit of security lingo, 164 00:10:27.030 --> 00:10:30.650 but basically once you give it that permission, it has that permission forever. 165 00:10:31.670 --> 00:10:34.230 And by and large, like if I'm telling an agent, "Hey, 166 00:10:34.290 --> 00:10:37.470 I need to add something to my calendar." And then like five days from now I'm 167 00:10:37.490 --> 00:10:41.410 like, "Hey, I need to make some slides." And something wrong happens, right? 168 00:10:41.470 --> 00:10:45.350 It's an LLM, it's not deterministic, and it starts messing with my calendar. 169 00:10:45.350 --> 00:10:49.890 I'm like kind of upset because that has nothing to do with drafting slides. 170 00:10:49.950 --> 00:10:52.630 And so somehow we want to constrain things more. 171 00:10:53.870 --> 00:10:57.950 And so the kind of like obvious answer to pull from our hat is like, 172 00:10:58.040 --> 00:11:01.410 we need to find a way to do this by task. In an LLM, you're prompting, 173 00:11:01.470 --> 00:11:04.810 it's like there's a unit of work. You're saying go do this thing, 174 00:11:04.930 --> 00:11:08.570 or maybe your agent is telling another agent to go do this thing. We're able to 175 00:11:08.610 --> 00:11:10.570 break things down by tasks, 176 00:11:11.950 --> 00:11:15.870 but what we don't know is like very specifically, 177 00:11:16.590 --> 00:11:21.210 like how should we specify those tasks to work into 178 00:11:22.110 --> 00:11:24.470 a Agent Auth system? 179 00:11:24.610 --> 00:11:27.250 And so this is my first mystery system, 180 00:11:29.830 --> 00:11:34.410 and it's one that I don't have an answer to, right? 181 00:11:34.470 --> 00:11:36.030 So I'm just going to point at a couple specs, 182 00:11:37.150 --> 00:11:41.270 areas where we're working on it. First is called AgentPass. 183 00:11:41.350 --> 00:11:42.190 It's from Clerk. 184 00:11:43.910 --> 00:11:47.610 And we go about this kind of by not trying to solve it. We say, 185 00:11:48.490 --> 00:11:50.370 if we create like a system of checks and balances, 186 00:11:50.470 --> 00:11:53.830 like we know that there's going to be one party approving the task and then the 187 00:11:53.890 --> 00:11:57.410 service is also going to need to let the task happen. And so like, 188 00:11:57.750 --> 00:11:59.170 if we leave it undefined, 189 00:11:59.370 --> 00:12:03.070 then maybe the person approving the task or the service will say, 190 00:12:03.150 --> 00:12:05.070 "You know what? That's too broadly scoped of a task. 191 00:12:05.070 --> 00:12:08.410 We're not going to let it happen." There's another spec called Mission-Bound 192 00:12:08.450 --> 00:12:11.350 OAuth written by a guy named Karl McGuinness. 193 00:12:11.430 --> 00:12:15.670 He worked at Okta for like a decade, was their chief product architect. 194 00:12:17.050 --> 00:12:18.130 He's taking the opposite approach, 195 00:12:18.190 --> 00:12:21.050 like how can we super rigidly define the task lifecycle? 196 00:12:22.550 --> 00:12:23.850 And that was, 197 00:12:25.030 --> 00:12:27.930 and he does like tasks and subtasks and like when they end and so forth. 198 00:12:28.810 --> 00:12:33.310 That was adopted by another spec called AAuth that this other identity guy, 199 00:12:33.350 --> 00:12:36.050 has been in the space for 15 years, wrote. 200 00:12:38.030 --> 00:12:42.290 And the difference between these two is that AAuth kind of fills in all the 201 00:12:42.330 --> 00:12:45.150 other gaps. Mission-Bound OAuth is like really just the spec for, 202 00:12:45.150 --> 00:12:45.883 "How do I define a task?" 203 00:12:47.690 --> 00:12:51.490 AAuth kind of solves the other problems of scoping and enforcement and so on, 204 00:12:51.570 --> 00:12:53.570 or at least thinks about and contemplates the other problems. 205 00:12:53.990 --> 00:12:56.770 And so I guess the takeaway I want you to have is like, okay, 206 00:12:56.840 --> 00:12:59.190 this is a problem that exists. 207 00:12:59.190 --> 00:13:02.230 These are some things that I could read to learn more about it. 208 00:13:02.230 --> 00:13:02.550 But yeah, 209 00:13:02.810 --> 00:13:06.750 I don't have the exact answer except that we kind of know that like roles or 210 00:13:06.790 --> 00:13:08.370 permissions, like those aren't going to be the answers. 211 00:13:08.430 --> 00:13:10.090 Somehow we need to constrain it more. 212 00:13:10.430 --> 00:13:14.690 Who approves what the agent is about to do and how? 213 00:13:16.570 --> 00:13:19.950 The first part of this is, well, where do we expect approvals to happen? 214 00:13:20.010 --> 00:13:23.170 So we have now a task that's scoped 215 00:13:24.990 --> 00:13:27.290 and someone, 216 00:13:27.930 --> 00:13:30.230 somehow that task needs to get approved. 217 00:13:31.330 --> 00:13:32.990 And so we are going to, 218 00:13:35.150 --> 00:13:38.790 thankfully say it's the exact same places that can vouch for approvals, 219 00:13:39.290 --> 00:13:43.010 and drawing parallels again kind of one by one. The 220 00:13:43.110 --> 00:13:47.190 services-approval is an authorization problem. 221 00:13:47.690 --> 00:13:50.870 Services are very used to doing in-house authorization, 222 00:13:50.930 --> 00:13:55.630 right? Kind of countless examples, 223 00:13:55.630 --> 00:13:58.830 but like the internal RBAC system is a way to like preapprove 224 00:13:59.610 --> 00:14:02.750 certain permissions. The scopes on API queues, again, 225 00:14:02.810 --> 00:14:05.470 it's preapproving on certain tasks. 226 00:14:08.230 --> 00:14:12.730 And that API keys is basically how we're seeing, or API key scoping rather, 227 00:14:12.810 --> 00:14:16.170 is how we're seeing engineers do this today, 228 00:14:16.950 --> 00:14:20.730 and it's all preapprovals. There's not much in the way of like, "Okay, 229 00:14:21.070 --> 00:14:23.510 agent is doing this task. How do we, point in time, 230 00:14:23.630 --> 00:14:28.210 get additional approval to do it?" And 231 00:14:28.790 --> 00:14:31.670 yes, but we do know that like, we don't know how that happens, 232 00:14:31.730 --> 00:14:34.330 but we know where it happens. It can happen at the service level. 233 00:14:36.130 --> 00:14:40.110 For the same reasons we talked about before, enterprises being enterprises, 234 00:14:40.830 --> 00:14:45.490 they don't want their employees kind of delegating agent tasks 235 00:14:46.090 --> 00:14:49.370 or agent approvals within... Well, 236 00:14:49.450 --> 00:14:52.990 they don't want the employees doing it themselves without the enterprise having 237 00:14:53.050 --> 00:14:57.810 oversight and approval on it or governance on it. And so somehow, some way, 238 00:14:59.310 --> 00:15:02.130 services aren't just going to be allowed to run an approval dashboard, 239 00:15:02.370 --> 00:15:07.070 it's also going to get foisted up into identity providers. 240 00:15:08.870 --> 00:15:10.450 Last one, trusted third parties. 241 00:15:10.950 --> 00:15:14.390 I was trying to think of a case where like trusted third parties are not just 242 00:15:14.430 --> 00:15:18.570 doing identity regularly, but actually an approval action. 243 00:15:19.290 --> 00:15:23.630 And I came up with Link, where they're approving a purchase. Again, 244 00:15:23.690 --> 00:15:27.490 we think the same concept is going to happen with agents. And of course, again, 245 00:15:27.590 --> 00:15:30.990 it did with Stripe Projects, where Stripe is not just telling Clerk, 246 00:15:32.750 --> 00:15:32.890 "Hey, 247 00:15:32.890 --> 00:15:35.470 this user wants a Clerk account." It's also saying "They want a Clerk account 248 00:15:35.550 --> 00:15:39.350 and they want to provision this plan. Will you let it happen?" And so, 249 00:15:40.150 --> 00:15:42.930 same exact case as agent identity: services, 250 00:15:42.950 --> 00:15:45.570 and third parties we're actually seeing in the wild, identity providers, 251 00:15:45.890 --> 00:15:49.290 we're hearing very loudly that it needs to happen and we don't have a spec yet. 252 00:15:50.250 --> 00:15:53.230 The real challenge on approvals is like, how do they happen? 253 00:15:53.450 --> 00:15:57.790 And that's what's really like undefined still. We talked about preapprovals. 254 00:15:58.170 --> 00:16:02.610 There's kind of generally agreement that preapprovals are like not good enough. 255 00:16:02.690 --> 00:16:07.390 Somehow we need to get point-in-time approvals for certain sensitive actions and 256 00:16:07.410 --> 00:16:11.710 there isn't spec for it. So this is my mystery system number two. 257 00:16:13.230 --> 00:16:14.063 Clerk with AgentPass, 258 00:16:14.110 --> 00:16:19.070 we took a very similar approach of like not solving it, 259 00:16:19.490 --> 00:16:23.890 but giving a place for it to be solved. And so we say, 260 00:16:23.890 --> 00:16:23.890 "Whether the service or the identity provider or the third party is building an 261 00:16:23.890 --> 00:16:24.523 approval dashboard, like they will be considered an authority." 262 00:16:37.130 --> 00:16:41.310 An authority is where approvals happen, and it's kind of up to the authority to 263 00:16:41.350 --> 00:16:45.390 decide, "Do I need a human in the loop for this task or do I not?" 264 00:16:47.130 --> 00:16:50.230 And if not, how to do that? And our mindset is like, well, 265 00:16:50.930 --> 00:16:52.170 since we don't really know how this happens, 266 00:16:52.230 --> 00:16:55.050 we should create an environment where like a bunch of different authority 267 00:16:55.170 --> 00:16:57.770 startups can kind of compete against each other and figure out the best way to 268 00:16:57.830 --> 00:17:00.310 do it, instead of trying to be too rigid with it. 269 00:17:01.830 --> 00:17:04.530 Other ones working on this, there's a lot. So MCP 270 00:17:06.070 --> 00:17:11.070 does things at the service level with an additional consent screen that has the 271 00:17:11.110 --> 00:17:11.990 standing privilege problem. 272 00:17:12.050 --> 00:17:14.490 I think that's broadly like why this is an issue still. 273 00:17:16.230 --> 00:17:20.010 And then Okta and AAuth have their own spins at this as well. 274 00:17:21.710 --> 00:17:24.910 More at the protocol level, they're also not really saying how it should happen. 275 00:17:25.870 --> 00:17:26.703 I think 276 00:17:28.090 --> 00:17:31.650 everyone except MCP is kind of taking this tact of, 277 00:17:32.850 --> 00:17:37.630 let others kind of decide how approval should happen, 278 00:17:37.790 --> 00:17:41.270 whether a human should be brought in the loop or not. You can imagine that, 279 00:17:41.850 --> 00:17:44.510 like an enterprise is going to approach that problem very differently 280 00:17:46.410 --> 00:17:47.770 than anyone, 281 00:17:47.770 --> 00:17:51.730 than like a consumer tool. Final one is agent 282 00:17:51.790 --> 00:17:55.710 enforcement. And so this one I think is talked about a lot less. 283 00:17:56.730 --> 00:17:59.510 It's more of a gradient in terms of, 284 00:18:00.630 --> 00:18:01.990 to what extent do we need it? 285 00:18:01.990 --> 00:18:05.730 I think we can actually launch like a V1 of Agent Auth before this is done, 286 00:18:06.890 --> 00:18:07.890 but what am I talking about? 287 00:18:07.950 --> 00:18:12.530 So how do we ensure that the agent only does what was 288 00:18:12.550 --> 00:18:16.590 approved and how do we do that in real time, specifically if we're the service? 289 00:18:16.810 --> 00:18:21.570 And so it's very clear that services will want to be able to operate 290 00:18:21.690 --> 00:18:24.990 some kind of enforcement engine. 291 00:18:26.130 --> 00:18:29.430 We don't know the exact shape of this, but basically what we know is 292 00:18:31.080 --> 00:18:32.410 someone's going to say, "Okay, 293 00:18:32.490 --> 00:18:35.250 I want my agent to do this thing." They're going to get it approved, 294 00:18:35.330 --> 00:18:37.130 or they're going to scope it, they're going to get it approved, 295 00:18:37.530 --> 00:18:40.570 and then they're going to bring it to a service or the agent is going to bring 296 00:18:40.590 --> 00:18:42.190 it to a service and say, "Okay, 297 00:18:42.370 --> 00:18:47.230 I'm now executing this task." And the service doesn't just 298 00:18:47.270 --> 00:18:52.180 want to see that and then let any API requests through, 299 00:18:52.330 --> 00:18:55.800 right? They want to make sure that the API requests that are happening actually 300 00:18:55.900 --> 00:18:59.920 map to the task that was approved. And you'll see, 301 00:19:00.360 --> 00:19:03.040 so I was talking about the gradient, like if you talk to an ecommerce company, 302 00:19:04.060 --> 00:19:06.040 they're maybe a little more okay with like, "Well, 303 00:19:06.100 --> 00:19:08.120 if extra stuff gets bought and we have to refund it, 304 00:19:08.280 --> 00:19:11.380 it's not that big of a deal." But if you talk to like a bank, 305 00:19:12.460 --> 00:19:15.200 clearly they're going to want more enforcement on moving money and stuff, 306 00:19:15.260 --> 00:19:19.490 making sure that what was approved is actually the API requests that are 307 00:19:19.560 --> 00:19:21.680 happening. And so how is this going to happen? 308 00:19:24.020 --> 00:19:27.140 I have it listed as mystery system three here, 309 00:19:28.580 --> 00:19:32.120 but the core element is pretty obvious. 310 00:19:32.210 --> 00:19:36.210 It's just that the service needs a way of verifying 311 00:19:36.700 --> 00:19:38.340 confidently that 312 00:19:40.640 --> 00:19:43.820 what task was approved, right? And so at some point, 313 00:19:43.940 --> 00:19:48.860 we need the task to be signed somehow cryptographically so that we can, 314 00:19:49.300 --> 00:19:53.520 or the service can tell, "Okay, this is what was approved. 315 00:19:53.920 --> 00:19:57.840 Now I can kind of map the session and see what the agent is doing, 316 00:19:58.260 --> 00:20:00.020 so that if it goes off the rails, 317 00:20:00.540 --> 00:20:05.210 I can stop it." Both AgentPass 318 00:20:05.520 --> 00:20:08.500 and AAuth make this possible. 319 00:20:08.980 --> 00:20:13.500 So AAuth is adopting missions, so we both believe that this is going to happen. 320 00:20:15.400 --> 00:20:17.220 We go about it in slightly different ways, 321 00:20:18.420 --> 00:20:22.600 but neither of us are actually trying to solve the final problem of how do we 322 00:20:22.640 --> 00:20:25.480 build that system. I think for the engineers in the audience, it 323 00:20:27.280 --> 00:20:29.960 doesn't sound like the hardest thing to build, right? 324 00:20:29.960 --> 00:20:32.540 Like just you get the session, you look at all the requests, 325 00:20:32.640 --> 00:20:37.240 you run an LLM against... It'll work. A little hand wavy, 326 00:20:37.400 --> 00:20:39.160 but like doing something, 327 00:20:40.840 --> 00:20:43.020 it should be pretty feasible to make it come together, 328 00:20:43.800 --> 00:20:46.400 as long as we know confidently what the task is. 329 00:20:46.620 --> 00:20:50.100 And this to me is another big kind of issue with MCP Auth. 330 00:20:51.000 --> 00:20:54.580 It doesn't actually carry... It doesn't have any concept of a task. And so, 331 00:20:55.560 --> 00:20:59.720 when the agent is doing something with a MCP-generated OAuth credential, 332 00:21:01.440 --> 00:21:06.220 the service has no idea why they're there. They just know that X, Y, 333 00:21:06.280 --> 00:21:07.460 Z permissions were approved. 334 00:21:07.620 --> 00:21:09.800 And that's just not enough to like build a meaningful 335 00:21:11.720 --> 00:21:16.600 enforcement layer. So these are my 336 00:21:17.640 --> 00:21:22.460 three keys to agent proliferation. So task scoping, the approval mechanism, 337 00:21:23.260 --> 00:21:24.360 and the enforcement engine. 338 00:21:26.420 --> 00:21:31.220 One thing that's I think particularly striking, especially right now, 339 00:21:31.440 --> 00:21:34.560 is I don't think any of us would have guessed 340 00:21:34.700 --> 00:21:38.200 that-early 2025, 341 00:21:38.780 --> 00:21:43.740 MCP Auth is taking off and people are excited about it-I don't think 342 00:21:43.800 --> 00:21:47.120 anyone would guess it would still be here Q2 of 2026. 343 00:21:48.900 --> 00:21:52.740 And a lot of what's going on is just like debate about the spec 344 00:21:54.080 --> 00:21:58.760 and not too much like, let's just build it and see what happens. 345 00:22:00.300 --> 00:22:02.700 One thing, and I guess I'm in finding myself, 346 00:22:02.800 --> 00:22:04.400 especially with the launch of Stripe Projects, 347 00:22:05.300 --> 00:22:10.300 I'm finding myself increasingly feeling like we might not solve it 348 00:22:10.340 --> 00:22:12.380 at the spec level. We might just solve it at the like, 349 00:22:13.220 --> 00:22:16.180 Stripe is just going to do Stripe Projects and agentic wallets, 350 00:22:16.360 --> 00:22:21.300 and they're going to get a nice consortium of companies together to put a 351 00:22:21.360 --> 00:22:24.340 stake in the ground and say, 352 00:22:24.860 --> 00:22:27.340 "This is like a V1." And yeah, 353 00:22:27.500 --> 00:22:31.260 I kind of think that's what's going to happen now if I'm very much speculating. 354 00:22:32.760 --> 00:22:34.740 As fun as the spec level debates are, 355 00:22:34.860 --> 00:22:39.720 I think we're seeing just putting a stake in the 356 00:22:39.740 --> 00:22:43.500 ground is seemingly getting traction faster from my perspective. 357 00:22:43.920 --> 00:22:48.040 And we really enjoyed collaborating on 358 00:22:50.660 --> 00:22:52.380 the Stripe Projects spec, 359 00:22:53.220 --> 00:22:58.200 and the way kind of identity became part of it was very exciting to us. 360 00:23:00.720 --> 00:23:04.520 I have a quick bonus slide here. 361 00:23:05.160 --> 00:23:10.160 The really exciting thing about Agent Auth, 362 00:23:11.900 --> 00:23:14.000 it's like we can talk about it in the context of Agent Auth, 363 00:23:14.900 --> 00:23:17.340 but if you think about these three issues, 364 00:23:18.200 --> 00:23:19.950 what we're doing is we're solving... 365 00:23:21.360 --> 00:23:24.700 We're creating a common interface to authorization. 366 00:23:25.740 --> 00:23:29.220 So how can I get access to do an arbitrary task within an arbitrary service? 367 00:23:30.280 --> 00:23:32.640 That has never existed before. 368 00:23:33.760 --> 00:23:37.380 And that's kind of unlike authentication, right? 369 00:23:39.180 --> 00:23:43.400 If you try to teach an agent how to sign in to a sign-in form, 370 00:23:43.460 --> 00:23:46.000 it's probably going to work on like 95% of the internet, 371 00:23:46.600 --> 00:23:50.700 but there is no common interface to authorization. And 372 00:23:52.480 --> 00:23:55.480 it's certainly very fun to think about it through the lens of Agent Auth, 373 00:23:55.500 --> 00:23:59.580 because you're going to have agents generating subagents and subagents and just 374 00:23:59.600 --> 00:24:02.140 like running around systems, and so on. 375 00:24:04.380 --> 00:24:05.213 But I guess 376 00:24:07.600 --> 00:24:09.780 one thing I would like to try to impress upon you is like, 377 00:24:10.360 --> 00:24:14.280 we have no idea the efficiency gains that are going to come from that. 378 00:24:14.660 --> 00:24:19.120 It's something that we've just not really been able to contemplate because I 379 00:24:19.240 --> 00:24:21.100 mean, if you go to five different companies, 380 00:24:21.540 --> 00:24:24.260 they all are doing authorization in five completely different ways. 381 00:24:24.400 --> 00:24:28.040 It's like a space, a startup space that just like hasn't worked, 382 00:24:28.120 --> 00:24:29.300 authorization-as-a-service. 383 00:24:30.480 --> 00:24:34.780 There's a famous Google whitepaper called Zanzibar that 384 00:24:36.080 --> 00:24:37.180 seven years ago-ish, 385 00:24:37.400 --> 00:24:39.840 people were really excited everyone's going to adopt this format, 386 00:24:39.860 --> 00:24:43.680 and we're going to have a standardized spec. And it just never landed. 387 00:24:43.840 --> 00:24:45.200 And I think now with agents, 388 00:24:45.260 --> 00:24:50.040 we have this real incentive to figure it out-what is the common interface to 389 00:24:50.120 --> 00:24:53.980 authorization going to be? And I think it's going to unlock, 390 00:24:55.900 --> 00:24:57.520 much like every new AI model, 391 00:24:57.660 --> 00:25:00.900 it's just going to unlock more than we can kind of imagine. People are going to 392 00:25:00.920 --> 00:25:02.480 find very creative ways to use it. 393 00:25:02.960 --> 00:25:06.660 And so I'd encourage you to just think about that a little more.