[
  {
    "startMs": 12660,
    "text": "Uh, hi, everybody. My name is Kamil. Uh, I work at Keycard in a product team. Uh, I'll be talking to you today about agent authentication and authorization requirements. Uh, we have around 18 minutes-ish. Uh, 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, um, how to kind of solve these problems, and give you context to come and ask us questions at the booth. Uh, we downstairs, so, um, just whatever questions you have, feel free to grab me at the end or go find Peter. He has all the answers."
  },
  {
    "startMs": 42840,
    "text": "Um, we're gonna start with this, uh, fairly simple diagram. Uh, you're probably familiar with this in any other talks you have about agents and, uh, how they communicate with MCP servers and other agents around. But what usually people don't talk about is how are these, uh, uh, agents and users communicate with each other, how do they authorize and make requests. So, um, what we come across and what we see often is that users, uh, obtain some sort of, uh, access credential. They, they might be called, uh, personal access tokens or just, uh, tokens."
  },
  {
    "startMs": 72820,
    "text": "Uh, and they kind of represent opaque credential, uh, identifying these users and letting the agent decide if they're gonna perform this action or not. If your agent is running locally, sometimes this step is skipped and nothing else happens. Um, when request comes to the agents, uh, they need the credentials of their own to even perform their actions, right? Like, the common thing that they need is an API key to talk to the model provider, uh, that allows them to kind of do the reasoning. So whenever the, um, kind of LLM model decides to do, uh, some actions, uh, they often call tools. Um, when we need to do those tool calls,"
  },
  {
    "startMs": 102980,
    "text": "often we use, uh, remote MCP servers to, to perform them. Um, and in order to communicate with them, hopefully, uh, th- we need another credentials to do that. And we have couple of options that, uh, we've seen in, in the industry. Sometimes, um, the agents will just use Alice's or, like, user's PAT tokens and pass them through. Sometimes they will have their own static keys. And luckily enough, uh, we see more and more use of OAuth kind of dynamic credentialing that happens there. Uh, but whenever MCP server receives that token, they usually just kind of see, uh, the, the user as the identity that acts with it. So"
  },
  {
    "startMs": 132760,
    "text": "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? Um, MCP servers are often used to kind of, um, enclose existing infrastructure. So if you have, like, internal APIs, databases, or even external systems that are not kind of agent-friendly, we can use MCP servers to represent that communication and, uh, optimize that interaction. Uh, but in order to do that, these MCP servers often need to have access to these backend services, uh, and ac- kind of act, uh,"
  },
  {
    "startMs": 162660,
    "text": "for multiple users. So they cannot just use one user's PAT token because that will be, uh, limited to that scope. They us- they often use, uh, service accounts, and those service accounts kind of become aggregator of permissions so that these servers can communicate. Um, and this is nothing new. Uh, we've seen this pattern in the past in kind of service-to-service communication in your traditional, uh, SaaS software. However, um, what, what's different about agents, um, they're not deterministic software, right? So whenever the request comes back to the agent and it sees some, some data, uh,"
  },
  {
    "startMs": 192720,
    "text": "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. Um, in this case, we're using an abstract example of a invoicing service. So imagine the, uh, agent receives a request to go and look at the recent invoice. It gets it back, and 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, um, 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"
  },
  {
    "startMs": 222580,
    "text": "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, uh, credentials l- laying around. So, uh, whenever users use these, uh, access tokens, um, they're not really attributed to anything. So, uh, Alice can quite easily take this a- access token and put it on, 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"
  },
  {
    "startMs": 252580,
    "text": "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're kind of non-deterministic, we don't really know what they're gonna do with those access keys. And finally, we arrive at the old problem of service accounts. Again, they just overprivileged 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 building released in a secure way, we thought about it as something that developers take care of, so we kind of"
  },
  {
    "startMs": 282540,
    "text": "accepted the risk. Agents changed all of that because now we live in a world where there's this other actor that can behave on behalf of you. I always use this analogy. 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 their, uh, 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 play this game, we will 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, uh, rampant with our credentials and do this all the"
  },
  {
    "startMs": 312400,
    "text": "time. So, um, we need a better solution to do this. And, uh, funnily enough, technology to solve some of these problems existed for f- 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 u- 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 embedding to the"
  },
  {
    "startMs": 342240,
    "text": "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 are 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, long time ago. But then for software, we decided that that's not really a requirement. Um, but we need to change this, uh, and we need to also use technologies that we have available to us to make agents"
  },
  {
    "startMs": 372272,
    "text": "authenticate before we issue them any credentials. So we can use things like workload identity federation. There's other mechanism. We can use private key authentication, you can use certificates, you can, you can use URL-based, uh, authorization. Uh, 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, uh, kind of service accounts and adding, like, persistent permissions to those service accounts, why don't they just every single time they want to talk to some remote s-"
  },
  {
    "startMs": 402292,
    "text": "uh, server, kind of determine what authorization is required, go to this remote service, obtain the token, and go forth? And, 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, um, and nothing changes, and you can kind of go and, um, re-implement the entire stack this way. So that sounds easy,"
  },
  {
    "startMs": 432392,
    "text": "so why we didn't do this before? Well, all of this kind of becomes way, way, way trickier to do when we think about this problem at scale. Um, there isn't, like, one API that we have. There is, like, hundreds of APIs that we have, and they use different ways to authenticate users. Behind those APIs, there is always some sort of authorization server that needs to authenticate the user. So in a previous picture that we had, we had, like, one block that we would have to authorize against. Now we have clients who need to do this across, like, hundreds of these services. Um, and there isn't, like, one agent type."
  },
  {
    "startMs": 462572,
    "text": "Um, we're gonna have, like, uh, agents that you buy, uh, so your cloud codes; agent that you build. Uh, sometimes you won't be able to, like, change that software, so we need to find a way how we're gonna do this. And, and there isn't, like, one hub. So now we need to persist this kind of delegation flow and verify how are these agents gonna talk to other agents, and how many hubs 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"
  },
  {
    "startMs": 492632,
    "text": "arbitrary actions that agents are doing. So at scale, now we have to solve all of these problems altogether in order to make something useful, uh, 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 gonna issue these identities per agent. Uh, then that might 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"
  },
  {
    "startMs": 522552,
    "text": "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 is, like, hundred different systems that they already have. We cannot magically hope we can rewrite them all. LLMs 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"
  },
  {
    "startMs": 552512,
    "text": "each other when they exchange these systems. And again, we're gonna 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,"
  },
  {
    "startMs": 582592,
    "text": "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 is 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 able to publish this information. Cl- clients need to be able to discover it. Then the agents"
  },
  {
    "startMs": 612572,
    "text": "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 issuer 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,"
  },
  {
    "startMs": 642552,
    "text": "and finally, we need to make sure that every single one of these actions is captured in a audit log. Um, raise of hands, who thinks LLMs can do this, uh, every single time perfectly?"
  },
  {
    "startMs": 654572,
    "text": "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 larger group of people if those performing, um, uh, properly, 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?"
  },
  {
    "startMs": 684632,
    "text": "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 codecs that you cannot go and modify, right? Like, SDKs won't help you there too much. Um, then if you're gonna 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"
  },
  {
    "startMs": 714452,
    "text": "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 additi- additional problem. As I said, they kind of act, um, and trying to be too optimistic, or they can be kind of manipulated to 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"
  },
  {
    "startMs": 744284,
    "text": "that there is credential that they can use, as long as it's within their own kind of execution environment, we have a problem. Um, so SDKs clearly are not gonna solve this problem for many reasons, and additionally, they don't solve the problem of hiding credentials from agents. So i- 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. Um, so, um, 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, um,"
  },
  {
    "startMs": 774144,
    "text": "secure enclave. So, uh, we can have our kind of runtime authorization system, uh, vaulting service that can store and kind of broker all these credentials. Um, and then the other problem is now how are we gonna make use of them? Um, so gateways are something we've used in the past, and they can solve this problem for us. So agents, uh, can communicate through the gateway, uh, can request, um, specific target to talk to GitHub, for example. Uh, and a gateway can authenticate who's calling it, talk to our runtime authorization server, validate that"
  },
  {
    "startMs": 804164,
    "text": "policies are in play, and fetch the specific credential. Uh, 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 gonna be very deterministic and go try to hack our gateway or even worse, our authorization service. Um, but what most importantly, we get couple more properties out of this. Even if we use short-lived credentials, um, they will"
  },
  {
    "startMs": 834104,
    "text": "have some sort of expiry time, right? And we still haven't figured out how to do, uh, revocation probably across distributed systems. But if you use gateways and you force all of your communication through that point, you can, uh, have instantaneous revocation because gateway can check every single request on the fly. Um, additionally, agents will do too much. Uh, a lot of these legacy services won't be able to, um, scope access properly. Uh, they will have tokens that allow you either admin, read, or write permissions, but that isn't good enough, right? Like, we want to be able to say, \"Hey, you can"
  },
  {
    "startMs": 864144,
    "text": "read my email, but you cannot send my email.\" Um, with the gateways, because we can intercept and more, i-importantly introspect all of the requests, um, we can attenuate that request. Um, we can say, \"For this specific request, yes, y- there is a secure credential we're gonna use, but if you're trying to send request, we'll just gonna block it.\" Um, we also get more observability, um, because the gateway is on a network path, we can see exactly what happens, uh, uh, for all the requests. Um, and we don't need to change anything"
  },
  {
    "startMs": 894124,
    "text": "in our downstream services. But there's nothing f- uh, for free in life, um, so gateways also come with some challenges. Um, well, you're adding another hop to your call. Um, so if you, uh, really careful about your latencies, that's gonna add some, uh, to it. Um, well, you need to force all of your agents to talk to your gateway. Um, if they can go bypass it, and if you don't have strong network controls, then that's not gonna help you. Additionally, some agents wants to, um, have kind of local tool execution, so you're not really guarding against that. Um, there is nothing gateway"
  },
  {
    "startMs": 924144,
    "text": "does about your identity problem. Um, yes, agents still need to get some sort of, uh, authentication credentials and present it to the gateway in order to have a correct authenticated requests. Um, you're also putting a big target on this one thing that you're creating, uh, because now w- what are we saying is, like, every single credential will go through it. So, well, some people will go try, try to hack it for you. Um, there is a lot of technical complexities with building gateways, uh, some people call them proxies as well. Uh, TLS is one of those things. Uh,"
  },
  {
    "startMs": 954364,
    "text": "if you try to intercept that and try to work with all of these systems, um, you might run into some problems. Um, and finally, um, if you're running distributed system, you have all of these developers building, um, agents, they need to figure out how they're gonna configure the, the routes, the policies, the connectors in all, all of those gateways, right? That still someone has to say, uh, if, uh, agent A can talk to agent B via the gateway. Um, and two, someone has to run it. Um, so these are all the problems we have with gateways. Um, so"
  },
  {
    "startMs": 985344,
    "text": "what do we do at Keycard? We think about all of these problems all the time. Um, so we don't think, um, it's, it's sensible for everybody to replicate all of these functionalities, so we've b- 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,"
  },
  {
    "startMs": 1014944,
    "text": "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."
  },
  {
    "startMs": 1045264,
    "text": "Um, so if you take anything out of this talk, uh, and want to come talk to us, um, agent auth isn't 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 gonna win this game, uh, by playing, uh, alone. Uh, and then really, really don't YOLO it,"
  },
  {
    "startMs": 1075284,
    "text": "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 agentbaseline.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 how to solve these, uh,"
  },
  {
    "startMs": 1105084,
    "text": "problems. That's"
  },
  {
    "startMs": 1114184,
    "text": "it."
  }
]