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

[music] >> Uh hi everybody. My name is Kamil. I work at Key Card in a product team. I'll be talking to you today about agent authentication authorization requirements. We have around 18 minutes ish. That's nowhere close to be able to cover this topic. So, 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. We downstairs. So, just whatever questions you have, feel free to grab me at the end or go find Peter. He has all the answers. We're going to start with this fairly simple diagram. You'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. But, 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. So, what we come across and what we see often is that users obtain some sort of access credential. They they might be called personal access tokens or just tokens. And they kind of represent opaque credential identifying these users and letting the agent decide if they're going to perform this action or not. If your agent is running locally, sometimes this step is skipped and nothing else happens.

When a request comes to the agents, they need to credentials of their own to even perform the actions, right? Like 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. So, whenever the kind of LLM model decides to do some actions, they often call tools. When we need to do those tool calls, often we use remote MCP servers to perform them. And in order to communicate with them, hopefully, we need another credentials to do that. And we have couple of options that we've seen in the industry. Sometimes the agents will just use Alice's or like users PAT tokens and pass them through. Sometimes 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. But whenever MCP server receives that token they usually just kind of see the user as the identity that acts with it. So 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? MCP servers are often used to kind of enclose existing infrastructure. So 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. But 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.

So they cannot just use one user's bot token because that will be limited to that scope. They they often use service accounts and those service accounts kind of become aggregator of permissions so that these servers can communicate. Um And this is nothing new. We've seen this pattern in the past in kind of service-to-service communication in your traditional SaaS software. However, what's what's different about agents? They're not deterministic software, right? So 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. In this case we're using an abstract example of invoicing service. So imagine the agent receives a request to go and look at the recent invoice. It gets it back an invoice says I'm pending, it should be sent to the user. An agent either maliciously or is just too helpful decides to go and send this invoice to a user. Now the question becomes who is making this request? Was this Alice or was this the agent? We don't know. There's nothing to determine that in reality.

Um So what else is wrong with this picture? Um there's a lot of issues with having all of these credentials laying around. So whenever users use these access tokens, they're not really attributed to anything. So 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. Um there is no easy way to revoke these credentials, so they kind of lay there and can be abused. Um agents as uh they want to do more things, we give them more credentials and they start aggregating them. And again, because they kind of non-deterministic, we don't really know what they're going to do with those access keys. And finally, we arrive at the old problem of service accounts. Again, 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. We thought about it as something that developers take care of. So, we kind of accepted the risk. Agent changed all of that because now we live in a world where there is this other actor that can behave on behalf of you. I 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." And back then we knew that that is not a good thing. So, that we we played this game. We would lock the machine down uh and then we would never do it again. But agents are basically doing this all the time. We just let them run rampant with our credentials and do this all the time.

So um we need a better solution to do this. And uh funnily enough, technology to solve some of these problems existed for many, many years. We just didn't have incentive to kind of um spend time how to implement this properly. Um so, instead of Alice uh going trying to figure out where to get access tokens, uh which is also terrible user experience. You can kind of think like, "Why why do I need to go and fetch these credentials?" Um 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. And 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. Uh and whenever it's done, it's finished. And OAuth as a technology allows us to do this. Um 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. Um 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. So, we can use things like workload identity federation. There's other mechanism, you can use private key authentication, you can use certificates, you can you can use URL based authorization. The mechanism doesn't really matter as long as you use it and make agents authenticate to the systems. And funnily enough, once you do that, then you can just kind of repeat the same pattern.

Instead 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, go to this remote service, obtain the token, and go forth. And [snorts] um the only difference between agents and traditional software that we have that I mentioned is that reasoning loop. If you take that out of equation, both the legacy software and agent is just software. So, 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. So, that sounds easy. So, why we didn't do this before? Well, all of this kind of becomes way way way tricky to do when we think about this problem at scale. There 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. Behind those APIs, there's always some sort of authorization server that needs to authenticate the user. So, in a previous picture we had we had like one block that we would have to authorize against.

Now you have clients who need to do this across like hundreds of these services. And there isn't like one agent type. We're going to have like uh agents that you buy, so your cloud code, agent that you build. Sometimes 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. And and there isn't like one hop. So, 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. And finally, like the biggest problem that we have is the attribution of like who decided to make this action. So, we now have like thousands of users who need to consent to these arbitrary actions that agents are doing. So, at scale, now we have to solve all of these problems all together in order to make something useful um for us. So, in summary, um if we want to have a proper agent authentication system, what do we need to deliver? So, first of all, we need agent identities. We need a system that's going to issue these identities per agent. Uh then that might be even be per session. Um but that must be separate from whoever launched it. Then we need to be able to express this delegation uh semantics. So, 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. We need to have a system that can uh issue scoped and short-lived credentials for everything that we do.

Um and there cannot be like any master key that allows us to do this. Um Second, as I mentioned, there's like 100 different systems that we already have. We cannot magically hope we can rewrite them all. LM are fast, but not that fast. Uh 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. And again, we're going to have legacy software forever. Um you won't be able to kind of go and hope that they will be supporting OAuth anytime soon. So, 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. Um and finally, you need to be able to express this with policies. Um someone needs to be able to write which uh actions need human approval, which agents can run automatically. Um and things will go wrong. So, um in order for us to learn uh how to improve things, we need audit. Um we need to be able to say who authorized this request and who made this possible. Um So, um there's a lot of steps to actually get this right. So, 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. Um server needs to be be to publish this information. Cli- clients need to be able to discover it. Then the agents need to be able to obtain these credentials. They need to be able to authenticate themselves to this remote server.

Um then when that happens, uh the MCP server has to be able to validate if those credentials been been correctly signed. They need to check if the issue is trusted. They need to verify those tokens. Um then there is some policy that needs to come into action. They need to enforce if the latest rules uh are in play. Um once that happens, and they communicate to external system, uh they might need to obtain additional credentials to talk to it. Uh and finally, we need to make sure that every single one of these actions is captured in the audit log. Um Raise of hands, who thinks LLMs can do this uh every single time perfectly? All right. Uh I think we're all in agreement. Um so, this is not simple, but we have solved similar problems before, right? Like 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 um appropriately, and kind of reuse them all the time. Um which sounds like a solution to what we want to do here. Um but what are the problems with SDKs? So, um it's easy to write them these days, but you need to get them adopted by everybody, right? Like if you have gaps in your uh adoption, then well, what's good are your SDKs? Um then you need to write them for every single language that you have. And LLMs are probably good at writing some of these languages, but probably not the older ones that you have in your system. Uh and then what do you do about your cloud codes, your code X that you cannot go and modify, right?

Like SDKs won't help you there too much. Um then if you're going to have bugs because a LLMs make bugs, we write bugs. Um 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. Um And then finally, so all of these previous four problems existed before, so that's nothing new. But agents have additional problem. As 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. So, um do we really trust with using just kind of client-side code to be able to manage these credentials securely? Of 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. So, 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. So, 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.

So, what can we do? Well, let's try to move all of these credentials out of this execution environment and put them in some sort of secure enclave. So, we can have our kind of runtime authorization system, vaulting service, that can store and kind of broker all these credentials. And then the other problem is now how are we going to make use of them? So, gateways are something we've used in the past, and they can solve this problem for us. So, 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. And then they can simply inject them into the request path and send it forward to GitHub. And 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.

But what most importantly, we get couple more properties out of this. Even if you use short-lived credentials, they will have some sort of expiry time, right? And we still haven't figured out how to do revocation probably across distributed systems. But 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. Additionally, agents will do too much. A lot of these legacy services won't be able to scope access properly. They will have tokens that allow you either admin, read, or write permissions, but they're not good enough, right? Like we want to be able to say, "Hey, you can read my email, but you cannot send my email." With the gateways, because we can intercept and more importantly introspect all of the requests, we can attenuate that request. We 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." We 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. But, there's nothing for free in life. So, gateways also come with some challenges.

While 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. Um Well, you need to force all your agents to talk to your gateway. If they can go bypass it if you don't have strong network controls, then that's not going to help you. Additionally, some agents want to have kind of local tool execution, so you're not really guarding against that. There's nothing gateway does about your identity problem. Yes, agents still need to get some sort of authentication credentials and present it to the gateway in order to have a correct authenticated requests. You'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. So, well, some people will go try try to hack it for you. There's a lot of technical complexities with building gateways. Some people call them proxies as well. TLS is one of those things. If you try to intercept that and try to work with all of these systems, you might run into some problems.

And 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? That still someone has to say if agent A can talk to agent B via the gateway. And two, someone has to run it. Um, so these are all the problems we have with gateways. Um, so what we do at Keycard, we think about all of these problems all the time. Um, so we don't think uh it's it's sensible for everybody to replicate all of these functionalities. So, we've built a single control plane um that allows you to both give your agents identities. We issue tokens uh in and federate with everything that you have going on. Um, we provide you policies and audit um to all of your requests. Um, you can get from us all of the client SDKs that allow you to do uh injection and discovery. We provide you with service SDKs that you don't have to worry about how they're being authenticated. Um, 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. You might be building a complete uh orchestration platform. Um, we are fairly unopinionated on the problem you're trying to solve with agents. We're just trying to help you solve these in a secure fashion. Um, 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. Uh yes, we kind of managed to survive without this for decades, but uh agents proved themselves recently that uh they cannot be trusted. Uh reality is messy. So, 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 um we're not going to win this game uh by playing uh alone. Uh and then really really don't yellow it uh because LLMs won't be able to implement this for you. Um, and make sure that whatever you do, check if the code written to implement these uh capabilities is secure. Um, thank you. Um, if you want to find out about us, come to the booth. We're Keycard AI. Uh also check out agent baseline.org. We have recently uh kind of released uh a software uh factory reference implementation of all of the capabilities that you've seen here. So, you can kind of learn and come and work with us on the how to solve this problems. That's it.

>> [applause]