It's 10pm. Do You Know Where Your Agents Are? — Kim Maida, Keycard

AI Engineer · 23 min · 201 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:01[music]
00:12Okay.
00:13So, 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.
00:20And 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?"
00:30Because apparently our parents at that time needed to be reminded that they had offspring they were responsible for.
00:36And 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?
00:54So, say you as a user want agent to use an MCP server or API to accomplish tasks.
01:01Now, we know agents without access aren't useful.
01:05So, we give them an end file and we give them some API keys and we let them run off and go do their thing.
01:12And this is fine until it's not.
01:14Uh, so you've heard the horror stories, right?
01:16Or maybe even experience some of them yourself.
01:19Uh, so let's see what this looks like in practice.
01:36this way.
01:45Okay.
01:46So, I have an agent running here that is it's basically an incident management agent.
01:51It is late night and there is a human user but they're probably half asleep.
01:57The agent is responsible for triaging issues that are coming in.
02:01Right?
02:02So if we look at the first one here, I can find the mouse.
02:10So the first one is the backup power supply failed in the server room.
02:16Now the agent is going to use an API key to read the system that is bringing in the reports.
02:22It's going to evaluate what is written there and it's going to decide that it can't do anything about this, right?
02:27Because it's a it's a physical fail failure.
02:31So it's going to escalate that ticket for the morning and there's really sort of no problems yet, right?
02:38So 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
03:01to uh renew the certificate and then it's going to use the API key from before to make the report for the morning team.
03:14So, here's where it kind of gets fun, right?
03:16So, this one is the billing database is broken and payments are failing.
03:23Agent's going to read that it sees that the solution is pretty clear.
03:30It says that the documented recovery is to delete the database and then restore from what the restore from backup happen automatically.
03:36Um, so it has the Postgress connection string.
03:40So 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.
03:44So it just escalates that for the morning.
03:48And this has really happened, right?
03:50Like it's happened to high-profile companies.
03:57Now if we go to the next one, this one is the main server processes are frozen and they're not recovering.
04:04doing something about it's going to take prod offline for a brief amount of time.
04:08And you can see the the agent decided that it should do that.
04:11And it's using the same API key now that it did to renew the certificate, right?
04:16Because that API key is a kitchen sink.
04:18It can do all of these things with it.
04:23And then finally, we have sites failing for one in three users.
04:28The recommended solution is to scale up, right?
04:31And this is going to incur some amount of spend.
04:33And then it goes ahead and it does that because again it can use that same API key to do this as well.
04:52Right?
04:52So agents with API keys are indeed outpass 10.
04:56They're overprivileged.
04:57So this means they are able to act freely on decisions that they make that you may or may not agree with.
05:03And they can do this even with your supervision.
05:05So 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.
05:16Um agents do that even while they're supervised.
05:20And 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.
05:28they're going to use all the permissions that they have access to in order to get the job done.
05:35And we can't just solve this with human in the loop.
05:38We spent decades solving access management for humans.
05:42So 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.
05:52So in order to see where we can introduce security and access control, we have to take a look at the agentic execution path.
06:02So we have a user who wants to use an LLM to interact with a resource.
06:07Now 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.
06:18Now an MCP client takes the agent's proposed tool calls and it dispatches them to its MCP server.
06:26And then we have a runtime.
06:28Now this is a process that runs the agent loop and executes the calls.
06:32And this runtime might be a CLI like cloud code.
06:36It might be an SDK like AI SDK or provider agent SDKs.
06:41Or it might be an app like cursor or codeex.
06:45So let's follow a prompt through the execution path.
06:48The user submits the prompt to the runtime which calls the model which sends it to the LM.
06:54The 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.
07:05The 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
07:17and at that point it's going to return the final answer to the user.
07:22So 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.
07:36So 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.
07:49So first I want to recap the problems that we're actually trying to solve here.
07:52Right?
07:52So 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.
08:02So, we have credentials that are being used that aren't attributed to a user or an agent identity.
08:09We have an agent that has unrestricted access to any and all permissions that are in an API key.
08:15And finally, we know that we can't just slap human in the loop everywhere because humans make mistakes too.
08:21And also, many agents run autonomously.
08:26So, we can address this with an authorization server called a security token service.
08:32Now an authorization server verifies identities and issues tokens.
08:36So identity providers like Google, Octa, Ozero and so on provide authorization servers.
08:41And if we want an identity chain in our agent execution path, then we have to be able to log in first.
08:49So the authorization server is then going to prompt the user for their consent to delegate access with a subset of their permissions.
08:56And this is the first narrowing of access, right?
08:58We're only delegating some of the user's total permissions to the agent.
09:04The authorization server issues a token that identifies the user and also contains their level of access.
09:09And 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.
09:17So this token identifies the subject on whose behalf the agent is going to act.
09:23In order to support token exchange, we need an OOTH client that's capable of executing code.
09:29So, this might be a gateway between the MCP client and a thirdparty MCP server.
09:34It might be your own custom agent app or a CLI wrapper around an off-the-shelf coding agent.
09:41And we take the prompt and we take the subject token and we send these to the OATH client.
09:45Now 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
09:59and it also sends the subject token that contains the user's identity and level of access.
10:04It 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.
10:14So now we have three key pieces of information that we're missing from the API key demo.
10:22We know the identity of the agent that's requesting access.
10:26We know the identity of the user on whose behalf is acting.
10:29And we know the delegating user's level of access as well.
10:33So now we need to decide if the requested token should in fact be granted.
10:37And we can do this using governance policy which is evaluated against the requested access and who's asking for what resource on whose behalf.
10:50Now 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.
11:05It should be short-lived uh often expiring within a few minutes and it's also ephemeral meaning it should never be stored.
11:13So this token is sent to the MCP client which makes tool call using it as a bearer credential.
11:19The 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.
11:30So the result flows back up the loop and then it repeats until the model returns the answer to the user.
11:40So if we come back to the demo now we're going to use the same agent only now we have token exchange.
11:57Okay.
11:57So the first thing we have that's different already is that we have an operator sign in right.
12:02So we have authentication and I'm going to authenticate with Google as myself.
12:13So we have the same tickets.
12:15We have the same agent.
12:16It's got the same prompt.
12:18And now we can see what it's going to do.
12:20Now the first item is probably going to be exactly the right because this was a hardware failure.
12:24there's it's going to decide after it reads it that there's nothing it can do.
12:27But as you can see kind of the audit log filling up, we've got a lot more information now.
12:32Um we know who the agent is acting on behalf of.
12:36We know that the agent is calling a prod infra MCP server and we know that it's going to contact certain downstream resources.
12:43Right?
12:43So 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
12:54talk to the pager uh resource in order to escalate to the morning team.
13:07So 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?
13:18So 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.
13:33So now with the billing database right like the billing database is broken.
13:36It uh pretty clearly documents that you are supposed to uh drop the database here but no agent should be able to drop a database.
13:47So 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.
14:05So 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.
14:17Um it just doesn't exist.
14:19So there's nothing to leak, there's nothing to replay, and there's nothing to steal.
14:27So this one was the one where it wants to restart prod.
14:32So 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?
14:41So it's going to ask me as the user for my approval as human in the loop.
14:46I 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.
14:55And I actually do not have that role.
14:57So it's going to prevent me from being able to allow the agent to do this.
15:02uh even though I approved it.
15:04So we can prevent kind of people from just consent fatigue clicking over and over just to get things done.
15:14And then this is the scaling one, right?
15:17So this is something that maybe the user does have permission to do.
15:23So 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.
15:52So 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.
16:00The agent also has task scoped short-lived ephemeral access and human in the loop actually has access control that is backed by real policy.
16:11So an exhausted person can't just accept everything that happens.
16:17Now another benefit of using open standards like token exchange is the ability to continue to support emerging technologies.
16:24So this works with off-the-shelf agents.
16:26It also works with custom agents that you might build yourself.
16:29It works with the CLI.
16:30It works with thirdparty as well as proprietary MCP servers, MCP gateways, agent to agent, uh any OOTH identity provider.
16:38It works with OpenClaw and basically anything that might come out next week.
16:45So, 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.
16:58So my name is Kim Maida.
17:00I 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.
17:10I'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.
17:20You can scan this QR code to connect with me and I really appreciate your time today.
17:25So, thank you very much.
17:27[applause]
17:31We do have time for a couple questions.
17:34Uh, so if anyone has some questions for Kim, um, we can answer those right now and then we got about five five minutes.
17:40So, we can probably do about five short questions if anyone has them.
17:55Um, 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?
18:14I'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.
18:22Uh yeah so the the authorization server is sitting in between let me find the slide actually.
18:44So the runtime authenticates to the security token service and identifies itself.
18:49And this is the point at which we have the request that the agent generated.
18:53Um and we also have the the scopes that it's asking for to get the token to call the next thing in line, right?
19:01And the next thing in line in this particular case is the MCP server.
19:06So the downstream resource is like one step farther down.
19:10But if you think about like an OOTH token for a user, right?
19:14So 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.
19:25But an agent, you don't want an agent to be using any of those grants that it wants on every single tool call.
19:33So 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
19:49right 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.
20:27Uh there may be some resistance to actually adopt this new uh protocol, new openspec.
20:35Have you encountered that?
20:36and what are the ways to uh get past that?
20:40So, 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.
20:54Um, we don't necessarily need a new spec for this.
20:57This spec has actually existed for a little while already.
21:00Um, so there's not kind of that fear of, oh my gosh, we're introducing something completely new.
21:07There are new specs that are coming out almost daily right now.
21:12Um, but they can be combined essentially with this uh with token exchange.
21:19I think we have time for one more question.
21:27I might be asking a big question.
21:29So if you tell me to go look at the thing, that's fine.
21:32Um, 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.
21:40And 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
21:48that will have a certain number of these things and someone has to do the authorization check somewhere.
21:52What'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?
22:05Well, 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?
22:18Because it's the user's access to the resource.
22:21So 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
22:37just pass them through.
22:39Yeah.
22:39Okay.
22:39Thanks.
22:41All right.
22:42Thank you Kim.