When an Agent Acts on Your Behalf, Who Holds the Keys? - Mariusz Sabath & Maia Iyer, IBM Research

This talk, presented by Mario Sabat and Maya from IBM Research, explores the complexities of security in agentic applications, particularly when these applications are deployed in enterprise settings. The speakers highlight how traditional API key mechanisms break down as agents work with multiple tools and multi-tenant environments, necessitating better context for security. They introduce OAuth 2.0, Spiffy, and token exchange as modern standards to improve security practices, enabling short-lived tokens and fine-grained authorization. The session details the Kajenti platform, designed to leverage open-source technologies for lifecycle orchestration, security, and observability while addressing interoperability issues. Furthermore, they discuss the development of Obridge, which simplifies the identity management and security processes for agents, aiming for a seamless developer experience.

Yeah, let's start because we have a >> packed >> agenda. Yes, agent. Okay, thank you all for being here. This is such a privilege for us to being able to share uh our work. My name is Mario Sabat IBM research and this is >> and my name is Maya also IBM research and we've been working on security for a long time and today we're going to be

talking about how to instrument security for agentic applications at the platform level. So to start I think it'll be oh this is us okay and then to start I think it'll be easiest to go into a use case right so when GitHub receives a request with an API key GitHub assumes that there is a user behind it right and for the most part that was the case

but recently there is now this new workflow that you may have heard of called the agentic workflow where there are now agents involved and in this workflow users can now talk to agents using natural language and the agent will do some LLM magic and figure out the details of how to actually make the requests to downstream tools. Right? So in this scenario, API keys are also typically

used. And this is perfectly fine because when the agent runs locally, the user is going to be ultimately responsible for the behavior of that agent. So GitHub is not going to care about whether it's a user or an agent. But once we bring an agent to enterprise and try to host it multi-tenants for multiple users, things become more complicated. And the reason for this is because now

that the agent is being run in an organization, the organization is going to be responsible for vetting the behavior of the agent. So this API key pattern is going to kind of break down. And the reason for this is several reasons. For example, there are this is a very very simple use case of like one agent and one tool. In reality, an agent can be talking to

multiple other agents, multiple other tools, talking to other infrastructure, right? And in this case, if everything we're accepting API keys, then the user is going to have to pass all of the API keys to all of the for all upon all requests. And also on top of that, these API keys tend to be long lived credentials, right? So that is going to be a problem for enforcing

zero trust posture in your organization. And on top of that um the the issue here is that every every request to every application is only going to have the information that the user is making that request. It's not clear whether there's an agent in the middle, two agents in the middle. And really if we want to enforce good observability and fine grained authorization, we need more context

at every request. So in this past year, we have been building a set of best practices and putting together the standards of OOTH 2, Spiffy, and OOTH token exchange to get rid of the API keys. And we're just going to summarize what how those all fit together because we also have some future or new work to talk about. So at a high level whenever a user initiates

a request they should they are going to delegate their access to an application to talk to other resources and this the standard for delegation is OOTH and at a high level how that works is a user will log in to an OOTH server think keycloak Microsoft Entra things like that and the OOTH server will authenticate the user and authenticates the workload and it will provide an access

token This access token is the glue that puts together all of the context that we care about. This access token has the information of the subject and the subject claim as well as the authorized party, the calling application and the target application, the audience. So in this case, the access token when it's passed to the agent, the agent will be able to verify because everything trusts this

central authority, the OOTH server. And also this is going to be beneficial towards implementing zero trust because these access tokens have expiry. They they're short-lived. Right? So this is OOTH. It is the glue for putting together all of the context we want. We also have token exchange. Token exchange is going to be for the cases where we have nested transactions. And whenever when in this case the

agent now needs to make another call to a tool or to another agent, the context changes. So we need a new token to reflect that change and Marush will go over some more concrete examples of the token exchange. But finally another piece of the puzzle is spiffy and using workload identity to allow applications to authenticate. Typically in the past agents have authentic or applications have authenticated to

the OOTH server using client secrets. And this is exactly like the API key. It's static. It's longived. It is not proper for zero trust. What Spiffy will do is once it receives a request to provide a workload identity, it will attest to the attributes by interrogating the platform. And once it gets that set of attributes, it will map that set of attributes to a name and provide

a document signing proof signed proof of that identity. And we will get into more details about this later. But the next um but you know this is the set of best practices that we have put together. There are also a couple other pointers like a gateway is going to be useful for centralized control. Vault is going to be important for interoperating with nonOTH applications. And so really

the next question once we put together this list is can we build it right? Can we build all of this using existing open source technologies? And this is where the project Kajenti with an I was born. In this project, what we've done is the idea was to build a platform completely using open source technologies and provide features in these four key pillars of life cycle orchestration, networking,

security and observability and completely implement them using existing open source building blocks. And the benefits of doing this experiment is that we have essentially created a pluggable platform blueprint such that if any organization wants to adopt kajenti the organization can do so without uh using all of the open source building blocks we used because all of these are interfacing via standards. So you can use keycloak you

can use your your own ooth provider like uh Microsoft Entra or Octa what or whatnot and it should work because we are building upon standards. So that's one of the benefits of this and the next the other benefit tangible benefit of doing these experiments is that we have identified gaps in interoperability and been able to upstream for example when we started doing the experiments on whether we

can authenticate to keycloak using spire issued credentials this was actually not possible last year when out of the box but we started this conversations and then by the end of the year last year this became a preview feature in Keycope 2016 is really awesome now. And then the another thing that we did that created a tangible asset is u started the implementation of the model context protocol

gateway because model context protocol was an emerging standard that was the popular way of connecting agents and tools and to provide the centralized control. um implementing this. We we implemented this and now this is a project under the quadrant organization and this is a QR code to check that out. But anyways, what we're going to do for the rest of this presentation is talk about some of

the more recent gaps that we have been identifying and addressing. And the first one is the fact that every time we made a change to the platform and added a new security layer, the application code had to change. And this was incredibly painful, right? Because now the agent developer has to be concerned not just with how to build agents but also how to talk to ooth oath

token exchange how to do spiffy and and uh talk to spiffy and get credentials. This was a huge pain and Marish is going to go over the a more detailed story on >> Okay. So let me first start with this very very old proverb. Generative AI does not bypass traditional engineering disciplines. Okay, so I made that up. It's a bit of hallucination, but the point is real.

The challenge with agents isn't the model capability. It's the infrastructure to deploy them reliably and securely. Agents are just workloads. They need identity authent uh uh authentication, authorization, the same things as any other workload. They they don't get a free pass just because they smart. So in kajenti we built a component to make this easier and it's called obridge. Although obridge should be applicable to all the

workloads our focus is AI So what is obridge? Here are the four capabilities of brbridge provides. First automatic identity. A path gets the spiffy ID auto registers with key lock. No admins no static keys. Everything just happens. Second, inbound JWT validation. Third, outbound token exchange. When the agent makes the call to another service, the sidecar intercepts, exchange the token using correct audience and forwards this to a

target service. Fourth, and this is the really key point, it's all transparent. The agent developers don't have to deal with the authorization authentication code. The platform injects sidecars via web hooks and handles everything. And that gives us the several security properties. No static secrets. Everything is dynamically generated. There are no longive API keys sitting in Kubernetes secrets. Shortlive tokens JWT expire. They must be refreshed. They have

limits time limits. So that reduces the blast radius. Inbound validation happens at the sidecar level. If anything goes wrong, the application doesn't even see the request. Subject preservation and that's critical for agentic use case. When the agent's token gets exchanged for a tool scoped token, the user's identity flows through. uh the tool knows exactly which user initiated the request and even though the agents performed the identity

based authentication that's the spiffy ID it's a keylo client ID it's cryptographic attestable and no one can easily forge it scopebased access control the tools can check what scopes are in the exchange token and grant different level of access and everything is auditable. Every token exchange is logged with original user and the target audience. Token exchange is a cryptographic trail of the actors involved in the exchange

from the initiator all the way to the resources. So you can feed this information into a policy engine to determine whether this is allowed applica allowed transaction or is it safe. So now let's look at the architecture. This diagram shows a workload pad that is the agent and the target uh service for this agent. Uh we also need Aspire to provide spiffy identities and the key log

that's for identity and access management token exchange and access policies. So this diagram shows the workload pod how it looks like with the Obridge sidecars injected. So number one at the top you that's the init container that runs first and configures traffic interception. An incoming request arrives with JWT token. It hits IP tables and then is routed to the inbound envoy. That's number two. a envoy with

the XRA filter on the inbound path, it validates the token and if the token is invalid, the user would get 401 and the token doesn't even get to the application. Three, if the token is valid, then we forwarded to application to the agent and notice the label, no o code needed. The application is completely unmodified. On the on the right you have a spiffy helper and client

registration sidecars. These handle identity and registrations with key log at the path startup. When the application makes the outbound call that's the point five the same IP table rules route uh through the sidecar and the XRO performs a token exchange. It forwards the request with the new token and it has a specific audience for the target service and then finally six the target service receives the exchange

token and validates it. The whole flow is transparent to both the application and the target. So here are the fields called claims of the sample token. First is audience. Who is this token for? First that would be the agent but then after the exchange it's the target service of the uh the direct target service then ACP authorized parties explicitly identifies the specific O client to which the

token was issued to subject that's a unique immutable identifier of the user or service and that requests the agent interaction and finally the preferred username that's the human reader able version of the subject. As the token travels between various components and is being exchanged to comply with the zero trust principles, the subject is preserved so the target can always see who the user was even when the

agent executed on its behalf. That lays the foundation for a full audit chain. Okay, so let's try to do a demo. And for this demo, I have a recording. We tried to do it in real life, but didn't work. How do I >> Maybe you have to stop extending. >> And I'll just mirror it. >> Oh, >> yes. All right. Okay. So, we'll start with the Kajenti

UI interface we log in as admin. And right there you can see the whole capability. We can have agents tools. So, let's look at the tools. We have a weather tool and the other with MCP inspector and the other let's go to agents. Okay. So agents we have a GitHub agent and the weather agent. So let's go to the weather agent. There is a agent card that

shows the details of the agent all the capabilities and then let's chat with the agent. So that's the part which actually timed So I had to have a recording. Uh okay. Let's check what is the weather in Rome. And that was recorded this morning. So it might be slightly different. Okay. Now the GitHub issue agent. So the same agent card shows the information about the agent. But

then if you go to a chat, it actually let's list 10 issues on our Kajenti project in the Kajenti repo. And if you wait a second, it talks to LLM and eventually we should get the results. Okay, so we have this open issues listed. Okay, that's pretty pretty awesome, right? Well, okay, this is not really that interesting because you don't see what's happening behind. So, let us

take you to behind the curtain what just happened. So first let me just list uh all the injected containers for one of these Okay. So this is the list of all the containers running on the system. So we have to issue we have agent we have a weather service. So now let's list the injected containers. So we have envoy envoy a agent itself. We have an envoy

proxy, the spiffy helper, kajenti client registration. That's the one that registers with key log. Okay. Moving on. Now this is the registration of the agent. So we can see that it will get the spiffy client ID. We register with uh key lock. We obtain the proper secrets if needed. So the registration was complete. Successfully retrieved the secret. Right. But this is the agent card. So this transaction

it should be according to A2A specs should be freely open. You can always inspect what agent capabilities are. Now any other transaction would require a token. So let's try to execute one without the token. It should fail. So this is the inbound uh validation. Okay. So I provide no token here. And if it's executed authorization header missing. Okay. So, this is failing. Good. Now, I'm going to

So, for this for this test, I'm going to write my own client so I can connect to the to the service and I can show you a few things inside. So, this is basically like what the UI would be doing, but we just have a pod. So, I'm getting inside of the pod and first I will log in as admin. So, you see the admin privileges. I

can now talk to and obtain my identity for this pod for the pad the agent pad. So it was there. I can now I can obtain the token the actual token that I'm going to be connecting to agent. So we have the token. Now we can issue exactly the same call. just list all the issues using the same token and after a while I should get the

response back. Perfect. So yeah, this is the basically formatted list of all the issues that are available uh for this. So we can stop right here. Let's continue presentation of time. Okay, perfect. Okay, so without the offbridge, there's a lots of code to operate. So, uh we have to do all all the operational efforts, token refresh, token exchange, error handling. Of course, you need to deal with

environment variables and configurations. With outbridge there's only one call. You basically execute the final call with token and then everything happens magically. So this is the example of the amount of code we could remove from one of the agents. Basically I know this hard to read but this is just visually showing you this is from every agent was basically removed. So where we stand today we took

care of the inbound token validation. This is done. Spire JWT tokens are being exchanged for key lock identities done. Route based token exchange. Now we working with MCP gateway in integration. Next dynamic client registration. So we still work uh next vault integration authorization pluggability and few interesting ones human in the loop and ibach which is the intentbased access control which prevents from the drift dete just just

detects the drifts from the uh from the agents operations. Okay and Mike I would cover the rest of activities. >> Yes. So yes, so just to recap, Marush has talked a lot about Obridge, which is just one of the places that we're trying to kind of help fill the gap with how the developer experience is when deploying agents into enterprise. But recently, we've also been looking at

some new features, right? New features of um audits and authorization which are going to be really important for enabling in the cloud. And I think everything we can start with just looking at this very simple example of something we may want to implement, right? An agent talks to a health database, but the health database maybe has a policy uh from compliance saying it needs like PII guardrails,

right? So how can we implement this? It becomes very clear that the agent or whatever is calling it needs to provide some sort of proof that it has PII guardrails, right? So where does this come in? A lot of people following the AI space will probably think about the A2A agent card, right? And and for those who are not familiar, A2A is a protocol for clients to

talk to agents. And the agent card is a piece of that protocol that is this self-describing manifest that an agent provides with information like what is this agent meant for? What are the capabilities? Maybe the guard rails, what are the safety measures around it? And in this case, maybe it makes sense because it seems to have a lot of the agent semantic attributes that we want. However,

there are a couple issues with using this for within our security framework. For example, one thing is that it is the operative word here is self-describing manifest, right? We if if we're going to use the agent card as it stands today, the resource server will be required to just trust the agent implicitly, right? And that's going to get rid of all of the security work that we

have built up. And then on top of that, the ATA standard is also very young and trying to use parts of it like the fact that it um it's about a client talking to an agent. Trying to use parts of it for this um other use case where it's a resource server trying to authenticate the agent. It's probably going to be problematic as the standard evolves. So

really I want to take a look back at the blueprint of identity and delegation that we have built right and here what we really have here is this chain of trust that starts at spiffy right so when an agent comes online in a platform the spiffy instance will provide an identity after attestation so once once the agent asks for an identity spiffy will interrogate in this case

if it's kubernetes the cublet it will interrogate the cublet for a set of attributes and that set of attributes will map to a name. Now that name is going to be signed and included in the SVID and what would be really convenient is if somehow Spiffy were able to attest the agent semantic attributes because then we would be able to wrap that in the identity that would

be the identity that is included as the caller component in the access token. this this um this would be really useful for interoperating with the rest of the blueprint that we have built. Right? So so again everything hinges on the attestation piece. Okay. So what needs to be done and this is where kind of our next some of our future work kind of lies is how can

we get this implemented in Spire and the way Spire works is it is um a pluggable it has pluggable attesters. So we could even though out of the box it only really provides the attestation workload attestation for platform attributes we could write our own attribute attesters for agent semantic attributes right but there are a couple things that we that kind of need to be solved first the

first thing is the fact that while we want new attesters we also don't want to lose the old ones we also still probably want to have some of the platform attributes still wrapped in the identity so very clearly from our first convers conversations with the Spiffy Spire community, shout out to Kevin Fox, is that we really need these attesters to be able to combine and stack. We

need to be able to have multiple workloaded attesters to execute and then combine the attributes, the value attributes into a single identity. This is currently not done today in Spire, but has been opened as a new proposal in the Spire GitHub community in the Spire GitHub. The other thing piece of the puzzle after that is solved is how do we figure what what is the source of

truth for the agent semantic attributes today that is a very very difficult question because all of the agents have different frameworks. There isn't a one unified configuration language for agents and maybe there even shouldn't be. So where should that ground truth lie? Some people may say maybe we need to start looking at the code. And another another way that we might do this is by having a

registry so that maybe the ground truth is good enough to have a a human attest to it or something like that or an organization attest to it. This is future work because we need to see how the space kind of develops, how the space evolves and if there is going to be a new piece of infrastructure that emerges that can serve as that ground truth to anchor

Spire's attestation. Right. So that is uh what we've been currently thinking and before we get to the end I wanted to return to the original question which is who holds the key. Right. And the key to this answer is multiple keys. It is not like any one entity has one key that that can do everything. It's more like the Star Trek self-destruct sequence where every captain or

every Yeah. every uh captain must provide their own authorization code. In this in this case, we have a user holding their credentials and their authorization. We have the workload holding their own credentials. And on top of that, not only are there multiple keys in this blueprint, there are also multiple locks, right? Spiffy is going to hold a policy for how identity is built and OOTH is going

to hold the policy for how delegation is implemented. And finally the resource server will have its own authorization policy. And in this way we can implement defense in depth. And that is the end of our talk. If you are interested please take a look at our project. We are happy to collaborate and otherwise there is a microphone at the front if you have any questions. >> And

I just would like to add that we have a collection of demos on our repo and you can actually check all these demos uh yourselves. There's of course Alice versus Bob. You can have different permissions. Uh we really wanted to show you real real life demo but for some reason this it doesn't work with the network. But yes, please go check the demos is a lot of

cool stuff over there. Okay, questions. >> So this is really awesome for like remote a aentic workflows. >> Yes. One of the things that I'm curious about and I haven't really seen a lot of like uh exploration in this area is like local agentic first workflows where maybe an organization doesn't necessarily want to put such prescriptive guardrails around what agents someone can and can't use because they

might have a different level of access that they might need for or like things that they might need to do with those agents, right? How does this how have you guys thought about how this changes based on like where the agents live and things like that? Um, is there an equivalence to something like this that exists for someone who's has like I have my access token say

to Kubernetes and I want to have whatever agent running locally that's able to access my Kubernetes cluster but I don't want it to have the full keys to the kingdom as because I'm a cluster admin and I don't want it to like be able to read these secrets or like delete these critical workloads. Um, do do you guys see that as like a pattern that is going

to be used in the future? Do you think it's all going to move towards remote first? >> No, not necessarily. If you want to control the data and if you want to use some local models perhaps, then you obviously going you don't want to do the remote calls. You want to stay within the organization. So that actually simplifies a little bit the process, but you still want

to control what's going what the permissions are being obtained and so on. One of the simplest solutions is usually vault because you can assign uh a permission of how do you use your own identity for accessing certain secrets or uh API keys or personal access tokens are stored in vault. So then for once you reach the boundary between those domains you can exch use the vault for

obtaining the uh personal access tokens to go outside and then stick within your old uh trust domain here. Okay, thank you. >> Okay, and I have a question. Uh, do you have an idea how to handle elevated privileges when I need to grant some additional privileges for this particular run of the >> Yeah, this is great question is is called human in the loop. Basically with this

is I I listed this is one of our research topics like when agent it's in a situation where needs to obtain more information that doesn't have it you have to get back to the user and one of the solutions we're looking right now is eventing so you would create an event that actually makes the call back to user says like I cannot proceed further I have to

obtain elevated privileges help me with it right so this is the domain that we exploring right now >> yeah I think if If you're interested, we're working on this now. Um, if you're interested, I would look into elicitation as well as um client initiated back channel authentication >> and just maybe we don't need always get back to the user. Maybe we need to go to >> or

another agent. That's right. Right. That's right. Yes. Thank you. That's a good question. >> Hi, thank you for the presentation. Um, the talk covers the case when the agent is a continuation of the user. basically my second brain my third hand whatever right um we are slowly moving towards direction where agents will become an independent actors where it's not an agent continuing what I'm telling it to

do but an an agent that is sitting there and receiving an extraction from the jur project from an inbound pager detail whatever how would you see evolving identic identity and security when we are shifting the parading from on behalf of two independent detectors. So two things one is the how do you identify the agent and this is when the spiffy spir comes to place because you want

to make sure that the agent is really what you think it is right just because because agent is another workload it's just workload that is capable of accessing LLMs but it's just another workload I can spin it here I can spin it there even using the same image so the critical part is the identity of the agent And then on behalf of this is you know what

we exploring here. Uh this is when the token exchange comes in in place. You can do it on behalf of specific users and so on. >> Yeah. The problem I see with treating agent as a workload. The workload if you look at the simple example of any API server or a business application it it has a deterministic goals and actions it is expected to take. The agent

basically can do anything. it it figures out. So um would you still treat it as a workload that has a prescribed set of instructions it can do or would you see it as a artificial human which can come up with an idea and attempt to do this? I would say that in the context of authentication, authorization and securing all the tools around it, it's very very helpful

to think of it as a workload because uh having it as like having a client's client profile in your OOTH server and having an identity that that can be uh um that can be interpreted. Um I would say that in in the place where we need to define authorization policy or uh be able to observe the transactions that it performs it's useful to start start looking at

it as a workload. Yes, there are ways in which this will evolve. I think one big problem is statefulness and because that's not something that is reflected in identity but starting with starting with um looking it as a workload is going to help make it easier to integrate into existing systems to start. >> Yeah, thank you. >> Thanks. U nice presentation u I'm from mediumak. I think

in your presentation you shared one resource server when during the token exchange if we have multiple resource servers including MCP's uh APIs knowledge base how will the interaction happen in that case? >> Excellent excellent question. So now we can plug something called MCP gateway. So uh the studies were done that agents should not be over overloaded with too many tools because they they actually start hallucinating and

so on. If you have a MCP gateway this actually solves a lot of these problems and then it becomes part of the communication between the agent and the tool then you can do some additional work in a MCP gateway. So you can have a separate rules that are defined in a gateway to help you with routing and so on. In fact, we are doing some testing right

now when we have a high level permissions defined in key log. So this specific user can talk to this specific tool without any details. And then the MCP gateway has a set of another set of permissions which are specific to a specific tool because it knows all about the tools. agent doesn't even know the all the details but MCP gateway does and you can predefine like for

this specific user that's the specific permissions you are allowed to execute on that specific tool and that happens on the gateway is this helping >> y thanks and in terms of MCP gateway are you also thinking about putting guard rails plugins >> yes yes very much so there was actually a talk yesterday and the ladies who did the talk are here they can definitely help you with

this with this question but that's when they that's what they are working on all the putting all the guard rails how you control what what is being executed what agent can and cannot do and things like this. >> Thank you. >> we we have to >> we will take questions >> maybe we should take it off offline >> but thank you. Thank you so much.