WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=I3znWC3MEXM NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/I3znWC3MEXM.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.800 --> 00:00:13.440 Okay. s3 00:00:13.440 --> 00:00:20.400 So, when I was a kid growing up in the '9s, we'd be out late all summer riding our bikes off in the neighborhood, playing with friends. s4 00:00:20.400 --> 00:00:30.400 And from the 60s to the 80s, there were these public service announcements on TV where celebrities would come on and they would say, "It's 10 p.m. Do you know where your children are?" s5 00:00:30.400 --> 00:00:36.800 Because apparently our parents at that time needed to be reminded that they had offspring they were responsible for. s6 00:00:36.800 --> 00:00:51.920 And I feel like in this phase of AI where we are right now, um, we're entrusting agents with more and more responsibility, but we still kind of need that public service announcement that says it's 10 p.m. Do you know where your agents are? s7 00:00:54.559 --> 00:01:01.920 So, say you as a user want agent to use an MCP server or API to accomplish tasks. s8 00:01:01.920 --> 00:01:05.920 Now, we know agents without access aren't useful. s9 00:01:05.920 --> 00:01:12.080 So, we give them an end file and we give them some API keys and we let them run off and go do their thing. s10 00:01:12.080 --> 00:01:14.560 And this is fine until it's not. s11 00:01:14.560 --> 00:01:16.640 Uh, so you've heard the horror stories, right? s12 00:01:16.640 --> 00:01:19.119 Or maybe even experience some of them yourself. s13 00:01:19.119 --> 00:01:24.640 Uh, so let's see what this looks like in practice. s14 00:01:36.560 --> 00:01:38.799 this way. s15 00:01:45.680 --> 00:01:46.560 Okay. s16 00:01:46.560 --> 00:01:51.840 So, I have an agent running here that is it's basically an incident management agent. s17 00:01:51.840 --> 00:01:57.920 It is late night and there is a human user but they're probably half asleep. s18 00:01:57.920 --> 00:02:01.680 The agent is responsible for triaging issues that are coming in. s19 00:02:01.680 --> 00:02:02.079 Right? s20 00:02:02.079 --> 00:02:10.080 So if we look at the first one here, I can find the mouse. s21 00:02:10.640 --> 00:02:15.920 So the first one is the backup power supply failed in the server room. s22 00:02:16.160 --> 00:02:22.400 Now the agent is going to use an API key to read the system that is bringing in the reports. s23 00:02:22.400 --> 00:02:27.920 It's going to evaluate what is written there and it's going to decide that it can't do anything about this, right? s24 00:02:27.920 --> 00:02:31.680 Because it's a it's a physical fail failure. s25 00:02:31.680 --> 00:02:38.160 So it's going to escalate that ticket for the morning and there's really sort of no problems yet, right? s26 00:02:38.640 --> 00:03:01.120 So now the second one is the certificate is expiring soon right for TLS agent is going to use that same API key again to read the ticket contents and then it is going to decide that it should renew the certificate and it's going to use another API key to call the cloud hosting service s27 00:03:01.120 --> 00:03:12.239 to uh renew the certificate and then it's going to use the API key from before to make the report for the morning team. s28 00:03:14.000 --> 00:03:16.319 So, here's where it kind of gets fun, right? s29 00:03:16.319 --> 00:03:22.080 So, this one is the billing database is broken and payments are failing. s30 00:03:23.519 --> 00:03:30.000 Agent's going to read that it sees that the solution is pretty clear. s31 00:03:30.000 --> 00:03:36.560 It says that the documented recovery is to delete the database and then restore from what the restore from backup happen automatically. s32 00:03:36.560 --> 00:03:40.000 Um, so it has the Postgress connection string. s33 00:03:40.000 --> 00:03:44.879 So it goes ahead and it drops the database and then it doesn't have a way to check to see if it was backed up. s34 00:03:44.879 --> 00:03:48.000 So it just escalates that for the morning. s35 00:03:48.000 --> 00:03:50.000 And this has really happened, right? s36 00:03:50.000 --> 00:03:53.599 Like it's happened to high-profile companies. s37 00:03:57.519 --> 00:04:04.319 Now if we go to the next one, this one is the main server processes are frozen and they're not recovering. s38 00:04:04.319 --> 00:04:08.080 doing something about it's going to take prod offline for a brief amount of time. s39 00:04:08.080 --> 00:04:11.120 And you can see the the agent decided that it should do that. s40 00:04:11.120 --> 00:04:16.799 And it's using the same API key now that it did to renew the certificate, right? s41 00:04:16.799 --> 00:04:18.799 Because that API key is a kitchen sink. s42 00:04:18.799 --> 00:04:21.919 It can do all of these things with it. s43 00:04:23.520 --> 00:04:28.000 And then finally, we have sites failing for one in three users. s44 00:04:28.000 --> 00:04:31.040 The recommended solution is to scale up, right? s45 00:04:31.040 --> 00:04:33.680 And this is going to incur some amount of spend. s46 00:04:33.680 --> 00:04:41.199 And then it goes ahead and it does that because again it can use that same API key to do this as well. s47 00:04:52.080 --> 00:04:52.400 Right? s48 00:04:52.400 --> 00:04:56.400 So agents with API keys are indeed outpass 10. s49 00:04:56.400 --> 00:04:57.520 They're overprivileged. s50 00:04:57.520 --> 00:05:03.120 So this means they are able to act freely on decisions that they make that you may or may not agree with. s51 00:05:03.120 --> 00:05:05.759 And they can do this even with your supervision. s52 00:05:05.759 --> 00:05:16.720 So you might be familiar with the panic of uh trying to stop an agent mid task because you told it to maybe read a project and it read the project and it found something it thought it should fix and then it starts writing. s53 00:05:16.720 --> 00:05:20.639 Um agents do that even while they're supervised. s54 00:05:20.639 --> 00:05:28.880 And this is becoming even more of a problem because we have more and more agents that are running unsupervised and that only makes it worse because agents want to be helpful. s55 00:05:28.880 --> 00:05:34.639 they're going to use all the permissions that they have access to in order to get the job done. s56 00:05:35.600 --> 00:05:38.800 And we can't just solve this with human in the loop. s57 00:05:38.800 --> 00:05:42.160 We spent decades solving access management for humans. s58 00:05:42.160 --> 00:05:52.160 So just blindly trusting a human who might be a little bit consent fatigued uh or who might be tired enough at night, this isn't really going to be enough. s59 00:05:52.400 --> 00:06:01.120 So in order to see where we can introduce security and access control, we have to take a look at the agentic execution path. s60 00:06:02.320 --> 00:06:07.039 So we have a user who wants to use an LLM to interact with a resource. s61 00:06:07.039 --> 00:06:18.400 Now an agent is a control loop that calls an LLM and often we have an MCP server in between that provides tools that the agent can call and then it connects directly to the resource. s62 00:06:18.960 --> 00:06:26.639 Now an MCP client takes the agent's proposed tool calls and it dispatches them to its MCP server. s63 00:06:26.720 --> 00:06:28.000 And then we have a runtime. s64 00:06:28.000 --> 00:06:32.560 Now this is a process that runs the agent loop and executes the calls. s65 00:06:32.560 --> 00:06:36.160 And this runtime might be a CLI like cloud code. s66 00:06:36.160 --> 00:06:41.120 It might be an SDK like AI SDK or provider agent SDKs. s67 00:06:41.120 --> 00:06:45.199 Or it might be an app like cursor or codeex. s68 00:06:45.440 --> 00:06:48.560 So let's follow a prompt through the execution path. s69 00:06:48.560 --> 00:06:54.400 The user submits the prompt to the runtime which calls the model which sends it to the LM. s70 00:06:54.400 --> 00:07:05.919 The model is then going to propose tool calls which are dispatched by the MCP client to the MCP server which then executes the tools and it calls the resource API. s71 00:07:05.919 --> 00:07:17.280 The API then responds to the MCP server and the MCP client delivers the results to the runtime and then the model will be called and loop repeats until the model is satisfied s72 00:07:17.280 --> 00:07:22.479 and at that point it's going to return the final answer to the user. s73 00:07:22.960 --> 00:07:35.280 So there are a few places in this path where we could implement real access control and we can actually do this with open standards and as kind of a spoiler it's not just OOTH. s74 00:07:36.400 --> 00:07:47.919 So RFC8693 is token exchange and this is an RFC that extends OOTH 2 and I'm going to show you how this spec can be used to address agent access. s75 00:07:49.120 --> 00:07:52.160 So first I want to recap the problems that we're actually trying to solve here. s76 00:07:52.160 --> 00:07:52.560 Right? s77 00:07:52.560 --> 00:08:02.319 So if you remember looking at the audit log as it was going by in the demo, we could see API keys were being used to call endpoints, but we had no idea who was using the API keys. s78 00:08:02.319 --> 00:08:09.280 So, we have credentials that are being used that aren't attributed to a user or an agent identity. s79 00:08:09.280 --> 00:08:15.680 We have an agent that has unrestricted access to any and all permissions that are in an API key. s80 00:08:15.680 --> 00:08:21.120 And finally, we know that we can't just slap human in the loop everywhere because humans make mistakes too. s81 00:08:21.120 --> 00:08:24.720 And also, many agents run autonomously. s82 00:08:26.560 --> 00:08:32.320 So, we can address this with an authorization server called a security token service. s83 00:08:32.320 --> 00:08:36.399 Now an authorization server verifies identities and issues tokens. s84 00:08:36.399 --> 00:08:41.919 So identity providers like Google, Octa, Ozero and so on provide authorization servers. s85 00:08:41.919 --> 00:08:49.120 And if we want an identity chain in our agent execution path, then we have to be able to log in first. s86 00:08:49.760 --> 00:08:56.880 So the authorization server is then going to prompt the user for their consent to delegate access with a subset of their permissions. s87 00:08:56.880 --> 00:08:58.959 And this is the first narrowing of access, right? s88 00:08:58.959 --> 00:09:03.760 We're only delegating some of the user's total permissions to the agent. s89 00:09:04.480 --> 00:09:09.920 The authorization server issues a token that identifies the user and also contains their level of access. s90 00:09:09.920 --> 00:09:17.200 And so right now already we're doing better than the first demo because we actually know who the user is and what they're allowed to do. s91 00:09:17.519 --> 00:09:23.519 So this token identifies the subject on whose behalf the agent is going to act. s92 00:09:23.600 --> 00:09:29.040 In order to support token exchange, we need an OOTH client that's capable of executing code. s93 00:09:29.040 --> 00:09:34.320 So, this might be a gateway between the MCP client and a thirdparty MCP server. s94 00:09:34.320 --> 00:09:41.040 It might be your own custom agent app or a CLI wrapper around an off-the-shelf coding agent. s95 00:09:41.120 --> 00:09:45.839 And we take the prompt and we take the subject token and we send these to the OATH client. s96 00:09:45.839 --> 00:09:59.519 Now the agent loop runs and the model proposes a tool call and then the runtime is going to authenticate with the security token service using its ooth app client credentials or workload identity s97 00:09:59.519 --> 00:10:04.880 and it also sends the subject token that contains the user's identity and level of access. s98 00:10:04.880 --> 00:10:14.560 It creates token exchange request and this request is asking for permissions to access the MCP server for that tool call but only that tool call. s99 00:10:14.560 --> 00:10:20.880 So now we have three key pieces of information that we're missing from the API key demo. s100 00:10:22.160 --> 00:10:26.000 We know the identity of the agent that's requesting access. s101 00:10:26.000 --> 00:10:29.680 We know the identity of the user on whose behalf is acting. s102 00:10:29.680 --> 00:10:33.839 And we know the delegating user's level of access as well. s103 00:10:33.839 --> 00:10:37.680 So now we need to decide if the requested token should in fact be granted. s104 00:10:37.680 --> 00:10:48.480 And we can do this using governance policy which is evaluated against the requested access and who's asking for what resource on whose behalf. s105 00:10:50.000 --> 00:11:05.200 Now if the delegation chain and the requested access are within policy then the security token service issues an access token for the downstream resource and this token has an audience declaring that only this target MCP server is allowed to use it to make requests. s106 00:11:05.200 --> 00:11:13.200 It should be short-lived uh often expiring within a few minutes and it's also ephemeral meaning it should never be stored. s107 00:11:13.760 --> 00:11:19.600 So this token is sent to the MCP client which makes tool call using it as a bearer credential. s108 00:11:19.600 --> 00:11:30.240 The MCP server validates the token and then goes and calls the resource and again it never stores the token and it discards it as soon as the call is done. s109 00:11:30.880 --> 00:11:38.000 So the result flows back up the loop and then it repeats until the model returns the answer to the user. s110 00:11:40.720 --> 00:11:55.600 So if we come back to the demo now we're going to use the same agent only now we have token exchange. s111 00:11:57.200 --> 00:11:57.839 Okay. s112 00:11:57.839 --> 00:12:02.240 So the first thing we have that's different already is that we have an operator sign in right. s113 00:12:02.240 --> 00:12:10.079 So we have authentication and I'm going to authenticate with Google as myself. s114 00:12:13.839 --> 00:12:15.279 So we have the same tickets. s115 00:12:15.279 --> 00:12:16.399 We have the same agent. s116 00:12:16.399 --> 00:12:18.000 It's got the same prompt. s117 00:12:18.000 --> 00:12:20.000 And now we can see what it's going to do. s118 00:12:20.000 --> 00:12:24.399 Now the first item is probably going to be exactly the right because this was a hardware failure. s119 00:12:24.399 --> 00:12:27.920 there's it's going to decide after it reads it that there's nothing it can do. s120 00:12:27.920 --> 00:12:32.240 But as you can see kind of the audit log filling up, we've got a lot more information now. s121 00:12:32.240 --> 00:12:36.320 Um we know who the agent is acting on behalf of. s122 00:12:36.320 --> 00:12:43.360 We know that the agent is calling a prod infra MCP server and we know that it's going to contact certain downstream resources. s123 00:12:43.360 --> 00:12:43.519 Right? s124 00:12:43.519 --> 00:12:54.560 So we have a hardware monitor that is the source of this incident and then when it decides that it can't do anything about it, it uses a right scope to s125 00:12:54.560 --> 00:13:01.680 talk to the pager uh resource in order to escalate to the morning team. s126 00:13:07.360 --> 00:13:18.639 So for renewing the certificate, right, this is actually a pretty safe action and it's going to specifically ask for a scope to only renew the certificate, right? s127 00:13:18.639 --> 00:13:30.240 So it's talking to this cloud host where before we had this API key that could do a ton of different things, but this time it is only asking for permissions, being granted permission to do this one thing. s128 00:13:33.360 --> 00:13:36.880 So now with the billing database right like the billing database is broken. s129 00:13:36.880 --> 00:13:47.200 It uh pretty clearly documents that you are supposed to uh drop the database here but no agent should be able to drop a database. s130 00:13:47.200 --> 00:14:05.760 So what happens is when we make this call it's being eval the policy is evaluating the request against all of the permissions that the user has and uh it sees that there is actually a restriction in place that prevents agents from doing this and this credential never even existed. s131 00:14:05.760 --> 00:14:17.839 So the policy evaluates before the credential is minted, which means you don't have an overprivileged credential that's just floating around then that uh you were supposed to then prevent the entity from receiving. s132 00:14:17.839 --> 00:14:19.199 Um it just doesn't exist. s133 00:14:19.199 --> 00:14:23.600 So there's nothing to leak, there's nothing to replay, and there's nothing to steal. s134 00:14:27.440 --> 00:14:32.800 So this one was the one where it wants to restart prod. s135 00:14:32.800 --> 00:14:41.279 So there are things that agents should probably be allowed to do and things that maybe they shouldn't be allowed to do and then there's some kind of you know something in between, right? s136 00:14:41.279 --> 00:14:46.639 So it's going to ask me as the user for my approval as human in the loop. s137 00:14:46.639 --> 00:14:55.839 I say that it can do that but there's another policy here that says that the human user needs to have a specific role in order to be able to do this. s138 00:14:55.839 --> 00:14:57.839 And I actually do not have that role. s139 00:14:57.839 --> 00:15:02.560 So it's going to prevent me from being able to allow the agent to do this. s140 00:15:02.560 --> 00:15:04.959 uh even though I approved it. s141 00:15:04.959 --> 00:15:12.240 So we can prevent kind of people from just consent fatigue clicking over and over just to get things done. s142 00:15:14.800 --> 00:15:17.360 And then this is the scaling one, right? s143 00:15:17.360 --> 00:15:23.279 So this is something that maybe the user does have permission to do. s144 00:15:23.279 --> 00:15:36.720 So if I say approve on this, I do have permission to do this and I was able to tell the agent that it is indeed allowed to and the policy approved it because I am allowed to do it also. s145 00:15:52.079 --> 00:16:00.880 So the agent access problems that we had discussed they have solutions now we know who the user is and we know who the agent is as well. s146 00:16:00.880 --> 00:16:11.040 The agent also has task scoped short-lived ephemeral access and human in the loop actually has access control that is backed by real policy. s147 00:16:11.040 --> 00:16:16.079 So an exhausted person can't just accept everything that happens. s148 00:16:17.199 --> 00:16:24.560 Now another benefit of using open standards like token exchange is the ability to continue to support emerging technologies. s149 00:16:24.560 --> 00:16:26.880 So this works with off-the-shelf agents. s150 00:16:26.880 --> 00:16:29.360 It also works with custom agents that you might build yourself. s151 00:16:29.360 --> 00:16:30.959 It works with the CLI. s152 00:16:30.959 --> 00:16:38.560 It works with thirdparty as well as proprietary MCP servers, MCP gateways, agent to agent, uh any OOTH identity provider. s153 00:16:38.560 --> 00:16:43.759 It works with OpenClaw and basically anything that might come out next week. s154 00:16:45.040 --> 00:16:55.519 So, it is in fact possible right now to be that responsible parent and to say that yes, you do in fact know where your agents are. s155 00:16:58.720 --> 00:17:00.079 So my name is Kim Maida. s156 00:17:00.079 --> 00:17:10.480 I am the founding GTM engineer and head of Devril at Keycard which is a standardsbased platform for uh providing a security token service and policy governance. s157 00:17:10.480 --> 00:17:19.439 I'm going to be at the Keycard booth for kind of the duration of the event but we're also running a workshop tomorrow on building and securing an MCP server. s158 00:17:20.160 --> 00:17:25.520 You can scan this QR code to connect with me and I really appreciate your time today. s159 00:17:25.520 --> 00:17:27.356 So, thank you very much. s160 00:17:27.356 --> 00:17:29.356 [applause] s161 00:17:31.600 --> 00:17:34.160 We do have time for a couple questions. s162 00:17:34.160 --> 00:17:40.160 Uh, so if anyone has some questions for Kim, um, we can answer those right now and then we got about five five minutes. s163 00:17:40.160 --> 00:17:44.559 So, we can probably do about five short questions if anyone has them. s164 00:17:55.440 --> 00:18:14.960 Um, so it seems like you put the security bar bear barrier uh at the um between MCP to uh resource or is it uh just maybe to clarify that is it at at both places? s165 00:18:14.960 --> 00:18:22.960 I'm wondering if there was like any decision there or like what would motivate you to choose you know where to put these sorts of barriers. s166 00:18:22.960 --> 00:18:32.080 Uh yeah so the the authorization server is sitting in between let me find the slide actually. s167 00:18:44.320 --> 00:18:49.600 So the runtime authenticates to the security token service and identifies itself. s168 00:18:49.600 --> 00:18:53.919 And this is the point at which we have the request that the agent generated. s169 00:18:53.919 --> 00:19:01.919 Um and we also have the the scopes that it's asking for to get the token to call the next thing in line, right? s170 00:19:01.919 --> 00:19:06.000 And the next thing in line in this particular case is the MCP server. s171 00:19:06.000 --> 00:19:10.240 So the downstream resource is like one step farther down. s172 00:19:10.240 --> 00:19:14.880 But if you think about like an OOTH token for a user, right? s173 00:19:14.880 --> 00:19:25.440 So an OOTH token for a user is going to have all of the grants in it that the user accepted when it when we were presented with like here's what access you're going to delegate. s174 00:19:25.440 --> 00:19:33.679 But an agent, you don't want an agent to be using any of those grants that it wants on every single tool call. s175 00:19:33.679 --> 00:19:49.200 So this the service sits in between that so that we can say if the things it's requesting are kind of beyond what we want to allow for the specific tool call then we never send that ooth token down s176 00:19:49.200 --> 00:20:27.679 right so they get that oath token only if they are within requesting something within the scope of what what we want does that make sense based enterprise systems. s177 00:20:27.679 --> 00:20:35.039 Uh there may be some resistance to actually adopt this new uh protocol, new openspec. s178 00:20:35.039 --> 00:20:36.640 Have you encountered that? s179 00:20:36.640 --> 00:20:40.880 and what are the ways to uh get past that? s180 00:20:40.880 --> 00:20:54.320 So, it's not actually a new spec, which is, you know, it it's kind of one of those things like there was this period of time where people were like, oh, you can just use OOTH for for this. s181 00:20:54.320 --> 00:20:57.120 Um, we don't necessarily need a new spec for this. s182 00:20:57.120 --> 00:21:00.720 This spec has actually existed for a little while already. s183 00:21:00.720 --> 00:21:07.200 Um, so there's not kind of that fear of, oh my gosh, we're introducing something completely new. s184 00:21:07.200 --> 00:21:12.000 There are new specs that are coming out almost daily right now. s185 00:21:12.000 --> 00:21:19.360 Um, but they can be combined essentially with this uh with token exchange. s186 00:21:19.919 --> 00:21:23.440 I think we have time for one more question. s187 00:21:27.679 --> 00:21:29.520 I might be asking a big question. s188 00:21:29.520 --> 00:21:32.400 So if you tell me to go look at the thing, that's fine. s189 00:21:32.400 --> 00:21:40.000 Um, I'm in the situation where we know that we don't have enough OOTH scopes defined yet in an MCP server sub just like what you have. s190 00:21:40.000 --> 00:21:48.880 And one of the reluctant things that we've got is like how fine grain do we get with the scope definitions because we know that we're also having to define downstream services s191 00:21:48.880 --> 00:21:52.960 that will have a certain number of these things and someone has to do the authorization check somewhere. s192 00:21:52.960 --> 00:22:05.360 What's your recommendation for getting started with defining your own scopes so that you can realistically manage this thing when you haven't defined enough yet and you're worried about ongoing management over time? s193 00:22:05.360 --> 00:22:18.799 Well, if your resource server already has like specific scopes, that's going to be kind of your place to start because the downstream token, the one that was the OS token for the user is going to have the scopes for the resource, right? s194 00:22:18.799 --> 00:22:21.840 Because it's the user's access to the resource. s195 00:22:21.840 --> 00:22:37.520 So those are kind of like the baseline like those are those are the ones you know that you're going to have and then if you want to have scopes additionally for that kind of govern tool calls if you have like a custom MCP server or something like that then you can layer those on top or you can s196 00:22:37.520 --> 00:22:39.039 just pass them through. s197 00:22:39.039 --> 00:22:39.520 Yeah. s198 00:22:39.520 --> 00:22:39.919 Okay. s199 00:22:39.919 --> 00:22:41.840 Thanks. s200 00:22:41.840 --> 00:22:42.400 All right. s201 00:22:42.400 --> 00:22:44.799 Thank you Kim.