Who Is Making This Request? Agent Auth 101 - Kamil Potrec, Keycard

AI Engineer · 18 min · 221 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:12Uh hi everybody.
00:13My name is Kamil.
00:14I work at Key Card in a product team.
00:17I'll be talking to you today about agent authentication authorization requirements.
00:21We have around 18 minutes ish.
00:23That's nowhere close to be able to cover this topic.
00:25So, my goal today is to give you kind of high-level overview of what's required to do this, how to kind of solve these problems, and give you context to come and ask us questions at the booth.
00:35We downstairs.
00:36So, just whatever questions you have, feel free to grab me at the end or go find Peter.
00:41He has all the answers.
00:43We're going to start with this fairly simple diagram.
00:46You're probably familiar with this in any of the talks you have about agents and how they communicate with MCP servers and other agents around.
00:53But, what usually people don't talk about is how are these agents and users communicate with each other, how do they authorize and make requests.
01:01So, what we come across and what we see often is that users obtain some sort of access credential.
01:08They they might be called personal access tokens or just tokens.
01:12And they kind of represent opaque credential identifying these users and letting the agent decide if they're going to perform this action or not.
01:19If your agent is running locally, sometimes this step is skipped and nothing else happens.
01:24When a request comes to the agents, they need to credentials of their own to even perform the actions, right?
01:28Like the common thing that they need is an API key to talk to the model provider that allows them to kind of do the reasoning.
01:33So, whenever the kind of LLM model decides to do some actions, they often call tools.
01:41When we need to do those tool calls, often we use remote MCP servers to perform them.
01:46And in order to communicate with them, hopefully, we need another credentials to do that.
01:50And we have couple of options that we've seen in the industry.
01:54Sometimes the agents will just use Alice's or like users PAT tokens and pass them through.
01:59Sometimes they will have their own static keys and luckily enough uh uh we see more and more use of all of kind of dynamic credentialing that happens there.
02:06But whenever MCP server receives that token they usually just kind of see the user as the identity that acts with it.
02:12So MCP server doesn't really know if it's like an agent running it, is it like Alice's CLI or is it like any other tool that does it?
02:20MCP servers are often used to kind of enclose existing infrastructure.
02:24So if you have like internal APIs, databases, even external systems that are not kind of agent friendly, we can use MCP servers to represent that communication and optimize that interaction.
02:35But in order to do that these MCP servers often need to have access to these back-end services and act kind of act for multiple users.
02:43So they cannot just use one user's bot token because that will be limited to that scope.
02:48They they often use service accounts and those service accounts kind of become aggregator of permissions so that these servers can communicate.
02:56Um And this is nothing new.
02:58We've seen this pattern in the past in kind of service-to-service communication in your traditional SaaS software.
03:03However, what's what's different about agents?
03:06They're not deterministic software, right?
03:08So whenever the request comes back to the agent and it sees them some data, it will send it back to the model and it will decide to to do what it wants to do to do with it next.
03:17In this case we're using an abstract example of invoicing service.
03:21So imagine the agent receives a request to go and look at the recent invoice.
03:26It gets it back an invoice says I'm pending, it should be sent to the user.
03:29An agent either maliciously or is just too helpful decides to go and send this invoice to a user.
03:36Now the question becomes who is making this request?
03:38Was this Alice or was this the agent?
03:41We don't know.
03:41There's nothing to determine that in reality.
03:44Um So what else is wrong with this picture?
03:49there's a lot of issues with having all of these credentials laying around.
03:53So whenever users use these access tokens, they're not really attributed to anything.
03:58So Alice can quite easily take this uh token and put it on her own personal machine uh and then you kind of lose all of that uh corporate infrastructure that might protect it from abuse.
04:09Um there is no easy way to revoke these credentials, so they kind of lay there and can be abused.
04:13Um agents as uh they want to do more things, we give them more credentials and they start aggregating them.
04:18And again, because they kind of non-deterministic, we don't really know what they're going to do with those access keys.
04:22And finally, we arrive at the old problem of service accounts.
04:25Again, they're just over-privileged bucket of permissions um and uh re- reality is like we've been okay with the status quo uh in the industry before agents because we kind of relied on the software being released in a secure way.
04:39We thought about it as something that developers take care of.
04:41So, we kind of accepted the risk.
04:43Agent changed all of that because now we live in a world where there is this other actor that can behave on behalf of you.
04:48I always use this analogy uh like in almost every company I worked at, uh we have this thing when we would walk around and see if one of your colleagues left the laptop unlocked and we would go to the Slack and be like, "I'm buying donuts for everybody today."
04:59And back then we knew that that is not a good thing.
05:02So, that we we played this game.
05:03We would lock the machine down uh and then we would never do it again.
05:07But agents are basically doing this all the time.
05:09We just let them run rampant with our credentials and do this all the time.
05:12So, um we need a better solution to do this.
05:15And uh funnily enough, technology to solve some of these problems existed for many, many years.
05:20We just didn't have incentive to kind of um spend time how to implement this properly.
05:25Um so, instead of Alice uh going trying to figure out where to get access tokens, uh which is also terrible user experience.
05:32You can kind of think like, "Why why do I need to go and fetch these credentials?"
05:35Um why wouldn't we have agents um that basically can advertise how to get access to them and then embed into the client's ability to go and request that authorization from some external system.
05:46And then we can issue this kind of dynamic uh credentials that are scoped to that specific interactions, that limited to the tool that was using it.
05:53Uh and whenever it's done, it's finished.
05:55And OAuth as a technology allows us to do this.
05:57Um and when you think about this, um we kind of solved authentication for users um a long time ago, but then for software, we decided that that's not really a requirement.
06:07Um but we need to change this and we need to also use technologies that we have available to us to make agents authenticate before we issue them any credentials.
06:14So, we can use things like workload identity federation.
06:17There's other mechanism, you can use private key authentication, you can use certificates, you can you can use URL based authorization.
06:23The mechanism doesn't really matter as long as you use it and make agents authenticate to the systems.
06:28And funnily enough, once you do that, then you can just kind of repeat the same pattern.
06:32Instead of giving these agents kind of service accounts and adding like persistent permissions to the service accounts, why don't they just every single time they want to talk to some remote server kind of determine what authorization is required,
06:46go to this remote service, obtain the token, and go forth.
06:49And
06:50[snorts]
06:50um the only difference between agents and traditional software that we have that I mentioned is that reasoning loop.
06:56If you take that out of equation, both the legacy software and agent is just software.
07:00So, again, you can just reuse the same pattern for the application that you're writing now, and nothing changes, and you can kind of go and re-implement the entire stack this way.
07:10So, that sounds easy.
07:12So, why we didn't do this before?
07:14Well, all of this kind of becomes way way way tricky to do when we think about this problem at scale.
07:20There isn't like one API that we have, there's like hundreds of APIs that we have, and they use different ways to authenticate users.
07:27Behind those APIs, there's always some sort of authorization server that needs to authenticate the user.
07:31So, in a previous picture we had we had like one block that we would have to authorize against.
07:36Now you have clients who need to do this across like hundreds of these services.
07:40And there isn't like one agent type.
07:42We're going to have like uh agents that you buy, so your cloud code, agent that you build.
07:48Sometimes you won't be able to like change that software, so we need to find a way to how we're going to do this.
07:52And and there isn't like one hop.
07:54So, now we need to process this kind of delegation flow and verify how all these agents going to talk to other agents and how many hops there can be in that loop.
08:03And finally, like the biggest problem that we have is the attribution of like who decided to make this action.
08:08So, we now have like thousands of users who need to consent to these arbitrary actions that agents are doing.
08:14So, at scale, now we have to solve all of these problems all together in order to make something useful um for us.
08:21So, in summary, um if we want to have a proper agent authentication system, what do we need to deliver?
08:28So, first of all, we need agent identities.
08:30We need a system that's going to issue these identities per agent.
08:33Uh then that might be even be per session.
08:35Um but that must be separate from whoever launched it.
08:38Then we need to be able to express this delegation uh semantics.
08:41So, we need to be able to say which users are authorized to perform actions with these agents, which agents can act on behalf of other users.
08:47We need to have a system that can uh issue scoped and short-lived credentials for everything that we do.
08:53Um and there cannot be like any master key that allows us to do this.
08:57Um Second, as I mentioned, there's like 100 different systems that we already have.
09:02We cannot magically hope we can rewrite them all.
09:04LM are fast, but not that fast.
09:06Uh so, we need to be able to build a federated trust of identities across them and allow to trust each other when they exchange these systems.
09:14And again, we're going to have legacy software forever.
09:17Um you won't be able to kind of go and hope that they will be supporting OAuth anytime soon.
09:22So, we need to be able to kind of have an adaptive layer, a broker, that allows us to securely exchange those legacy credentials just in time.
09:29Um and finally, you need to be able to express this with policies.
09:33Um someone needs to be able to write which uh actions need human approval, which agents can run automatically.
09:39Um and things will go wrong.
09:41So, um in order for us to learn uh how to improve things, we need audit.
09:45Um we need to be able to say who authorized this request and who made this possible.
09:50Um So, um there's a lot of steps to actually get this right.
09:56So, um what I want to show you here is just like if you take one interaction between agent and MCP server just to get this working, um you will have a client and a server.
10:06Um server needs to be be to publish this information.
10:09Cli- clients need to be able to discover it.
10:11Then the agents need to be able to obtain these credentials.
10:15They need to be able to authenticate themselves to this remote server.
10:18Um then when that happens, uh the MCP server has to be able to validate if those credentials been been correctly signed.
10:25They need to check if the issue is trusted.
10:27They need to verify those tokens.
10:29Um then there is some policy that needs to come into action.
10:32They need to enforce if the latest rules uh are in play.
10:36Um once that happens, and they communicate to external system, uh they might need to obtain additional credentials to talk to it.
10:42Uh and finally, we need to make sure that every single one of these actions is captured in the audit log.
10:46Um Raise of hands, who thinks LLMs can do this uh every single time perfectly?
10:54All right.
10:55Uh I think we're all in agreement.
10:56Um so, this is not simple, but we have solved similar problems before, right?
11:00Like we've written shared libraries, we've written middleware, we've written SDKs in order to kind of write these things once, verify with a larger group of people if those performing
11:10um appropriately, and kind of reuse them all the time.
11:13Um which sounds like a solution to what we want to do here.
11:15Um but what are the problems with SDKs?
11:18So, um it's easy to write them these days, but you need to get them adopted by everybody, right?
11:24Like if you have gaps in your uh adoption, then well, what's good are your SDKs?
11:29Um then you need to write them for every single language that you have.
11:32And LLMs are probably good at writing some of these languages, but probably not the older ones that you have in your system.
11:37Uh and then what do you do about your cloud codes, your code X that you cannot go and modify, right?
11:42Like SDKs won't help you there too much.
11:44Um then if you're going to have bugs because a LLMs make bugs, we write bugs.
11:49Um in order to fix that, you not only have to fix the SDK, but then you need to track where is this SDK used, and which one of the systems consumed it.
11:57Um And then finally, so all of these previous four problems existed before, so that's nothing new.
12:03But agents have additional problem.
12:04As I said, they kind of act um and trying to be too optimistic, or they can be kind of manipulated do things, and they proved to be very persistent in trying to bypass our controls.
12:14So, um do we really trust with using just kind of client-side code to be able to manage these credentials securely?
12:20Of course, they can cache them, they can store them properly, but if they figured out that there is credential that they can use, as long as it's within their own kind of execution environment, we have a problem.
12:29So, SDKs clearly are not going to solve this problem for many reasons, and additionally, they don't solve the problem of hiding credentials from agents.
12:37So, if we take this picture, um the challenge that we want to do is to get all of these tokens out of the reach of the agent.
12:46So, what can we do?
12:48Well, let's try to move all of these credentials out of this execution environment and put them in some sort of secure enclave.
12:54So, we can have our kind of runtime authorization system, vaulting service, that can store and kind of broker all these credentials.
13:02And then the other problem is now how are we going to make use of them?
13:06So, gateways are something we've used in the past, and they can solve this problem for us.
13:10So, agents can communicate to the gateway, can request specific target to talk to GitHub, for example, and a gateway can authenticate who's calling it, talk to our runtime authorization service, validate that policies are in place, and fetch the specific credential.
13:27And then they can simply inject them into the request path and send it forward to GitHub.
13:32And what that gives us is now we have like a physical control layer where there's simply no way for this agent to obtain this credential unless it's going to be very deterministic and go try to hack our gateway, or even worse, our authorization service.
13:46But what most importantly, we get couple more properties out of this.
13:50Even if you use short-lived credentials, they will have some sort of expiry time, right?
13:55And we still haven't figured out how to do revocation probably across distributed systems.
14:00But if you use gateways and you force all of your communication through that point, you can have instantaneous revocation because gateway can check every single request on the fly.
14:09Additionally, agents will do too much.
14:13A lot of these legacy services won't be able to scope access properly.
14:17They will have tokens that allow you either admin, read, or write permissions, but they're not good enough, right?
14:22Like we want to be able to say, "Hey, you can read my email, but you cannot send my email."
14:26With the gateways, because we can intercept and more importantly introspect all of the requests, we can attenuate that request.
14:34We can say, "For this specific request, yes, there is a secure credential we're going to use, but if you're trying to send request, we're just going to block it."
14:44We also get more observability because the gateway is on a network path, we can see exactly what happens for all the requests, and we don't need to change anything in our downstream services.
14:55But, there's nothing for free in life.
14:58So, gateways also come with some challenges.
15:00While you're adding another hop to your call, so if you're really careful about your latencies, that's going to add some to it.
15:08Um Well, you need to force all your agents to talk to your gateway.
15:12If they can go bypass it if you don't have strong network controls, then that's not going to help you.
15:16Additionally, some agents want to have kind of local tool execution, so you're not really guarding against that.
15:22There's nothing gateway does about your identity problem.
15:26Yes, agents still need to get some sort of authentication credentials and present it to the gateway in order to have a correct authenticated requests.
15:35You're also putting a big target on this one thing that you're creating because now what we're saying is like every single credential will go through it.
15:43So, well, some people will go try try to hack it for you.
15:47There's a lot of technical complexities with building gateways.
15:50Some people call them proxies as well.
15:52TLS is one of those things.
15:54If you try to intercept that and try to work with all of these systems, you might run into some problems.
15:59And finally, if you're running distributed system, you have all of these developers building agents, they need to figure it out how they're going to configure the the routes, the policies, the connectors in all of those gateways, right?
16:11That still someone has to say if agent A can talk to agent B via the gateway.
16:17And two, someone has to run it.
16:19Um, so these are all the problems we have with gateways.
16:22Um, so what we do at Keycard, we think about all of these problems all the time.
16:28Um, we don't think uh it's it's sensible for everybody to replicate all of these functionalities.
16:35So, we've built a single control plane um that allows you to both give your agents identities.
16:41We issue tokens uh in and federate with everything that you have going on.
16:45Um, we provide you policies and audit um to all of your requests.
16:50Um, you can get from us all of the client SDKs that allow you to do uh injection and discovery.
16:56We provide you with service SDKs that you don't have to worry about how they're being authenticated.
17:00Um, we also give you gateway uh if you really want to have those controls, but fundamentally um you can bring all of these components to us um and kind of pick and choose which one of these capabilities you need to build your system because you might be building a chat application.
17:14You might be building a complete uh orchestration platform.
17:17Um, we are fairly unopinionated on the problem you're trying to solve with agents.
17:21We're just trying to help you solve these in a secure fashion.
17:25Um, so if you take anything out of this talk uh and want to come talk to us, um agent off isn't an option optional anymore.
17:32Uh yes, we kind of managed to survive without this for decades, but uh agents proved themselves recently that uh they cannot be trusted.
17:40Uh reality is messy.
17:41So, even if you go on a mission of trying to build some of these components, uh make sure that you use open standards uh and to be interoperable with other systems because
17:49um we're not going to win this game uh by playing uh alone.
17:52Uh and then really really don't yellow it uh because LLMs won't be able to implement this for you.
17:58Um, and make sure that whatever you do, check if the code written to implement these uh capabilities is secure.
18:05Um, thank you.
18:07Um, if you want to find out about us, come to the booth.
18:09We're Keycard AI.
18:10Uh also check out agent baseline.org.
18:13We have recently uh kind of released uh a software uh factory reference implementation of all of the capabilities that you've seen here.
18:20So, you can kind of learn and come and work with us on the how to solve this problems.
18:26That's it.
18:27[applause]