Project Lightning Talk: OpenFGA For Agents: Safe Delegation In 5 Minutes - Andres Aguiar, Maintainer

This talk introduces OpenFGA, an authorization service for developers inspired by Google Zanzibar. The speaker, representing Sedan, discusses how OpenFGA enhances relationship-based access control, allowing for more granular permissions compared to traditional role-based and attribute-based access controls. OpenFGA supports large-scale applications and has recently launched support for OpenID Auth Zen 1.0. The presentation also covers the concept of agents that require ephemeral permissions based on their tasks, illustrating this with examples from project management systems. The speaker illustrates various scenarios of how agents can be restricted based on specific permissions, emphasizing a secure and context-aware approach to automation.

So, Andres, I'm an OpenFGA maintainer. Uh this presentation was submitted by Sedan. Sedan is a maintainer. He lives in India. He couldn't make it, so I'm doing the presentation for him. It's inspired on some content that he created, and I'm trying to represent those ideas. So, OpenFGA is an authorization service for developers. If you're using it, if you want to build authorization for an app or for

an agentic app. And it's inspired in the in a project by Google called Google Zanzibar. And that we extend and which works with relationship-based access control. You can see this as an evolution of role-based access control and attribute-based access control. Uh Zanzibar in at Google pow- and the powers things like Google Google Docs or Google Cloud or YouTube. And uh so, it's a build to scale to

large RPS and and data volume. And what we did is we package those ideas with great developer tooling. And uh so, you can use it for your own applications. These are some of the adopters of OpenFGA. There's an adopters empty page where everyone can add themselves. These are the companies that did. Thank you very much for all of them. There are big names there. And uh in

the last 6 months since the last time we did this in the in uh the US, we were adopted in uh accepted in incubation. So, that's great news for the project. We just launched support for OpenID Auth Zen 1.0. It's a specification for OpenID to how to do authorization checks. And also, we've been working a lot on performance. This is a a performance a latency graph that

was shared by the team at Docker after they're and migrated to the latest version. So, you see latency decreased a lot there. Let's talk about agents. I'm going to present here a solution for a use case with these constraints. First, the agent needs to use credentials. Those credentials are going to have some permissions. They can be on behalf of a user, on behalf of uh service. I

don't care. We want to restrict what agents can do uh on top of their API credentials, okay? So, less permissions than what they already have. Agents will start with zero permissions and we grant them ephemeral per task permissions. Let's introduce a little of OpenFGA. In OpenFGA, you define what we call authorization model where you declare the entities that are relevant with making authorization decisions. If we want

to model something like MCP, this is a very simple way of doing it. We're going to have an entity that is a tool and then a parameter that we can specify on a tool. And we can say that we can call a tool or we can call a tool with a parameter. We instantiate that model with data where we call tuples we have on the right on

my right. And and see here we're saying that a task can call any task can call the Slack list channels that but only the task number one, a task that was created can call that the send Slack message for specific Slack channel. Okay? So, we're setting permissions per task per resource in a fine-grained way. And and at the bottom it has a test that we say, "Okay,

can this task call this tool with these parameters?" And it's going to return true. This is a model for tools, but I can have a model for my application domain. Let's say I'm building a project management system. I can say, "Okay, this task can edit this project." And if the task can edit this project, can also edit any ticket of the project, right? So, you can have

permissions at any level of the hierarchy and then instantiate that data and those permissions and ask if, for example, task one can edit a specific ticket. there's a lot of conversations about intent-based permissions or all authorization. What does that mean? Basically, it means I have a a for an agent, "Create a summary of the website project and post it to in team updates. the LM will figure

out that it needs to read the website project from Linear and post messages to the team and to the Slack team channel. So, there's and there's an LM that is process that prompt and infer what is the intent of those of that prompt and what permissions it needs. It's a different LM from the one that's going to run the task, right? It's an LM that cannot be

prompt injected, has the whole context there, cannot call tools, very constrained. Then there are two modes. One way, maybe the user now approves the permissions that needs to be that are required for this intent. Or if it's an autonomous agent, we grant the permission automatically for it. And then it runs with those permissions. So, I have a video now. The what it's doing is is going to

is have two is two demos. First is interactive. I'm going to happen I'm going to say summarize this project tag and post it to the a private channel. This actually talking to Linear and Slack. And it's it realizing that it needs permissions to get a project from Frame ACP and to post a Slack message. I allow that. It's getting the project and the Slack channels. But the

prompt the Linear project how was actually injected had a prompt injection that was telling that it needs to send an email, sorry. It needs to send an email to the man Let me post it here. Okay. It sends an email to someone else. And those permissions weren't granted at the beginning. So, the LM does the agent doesn't have those permissions. So, it's going to ask me if

I want to do it. And I'm going to say no because I didn't allow to do this to do this. So, now it's not just going to send the message and it's going to tell me that it couldn't send the email. That's the interactive approach, which is kind of interesting but not that interesting. And then the other one is if we run an autonomous agent, same prompt.

The The agent has a specific prompt, right? So, we can infer the They are not prompted, we infer them. It's trying out to do that. Get the project and and send send it to Slack. But it found that it had was prompt injected and it was saying that it needs to send an email to myself. And so, right now what it's doing is canceling the task and

it's not doing anything because it realizes the permissions it has for running the task is not what it needed to complete So, two scenarios there, the interactive one and the autonomous one. and I think that's it. So, we're going to be in the project pavilion every afternoon. There's another presentation I will doing with someone from from Erica from Tetrate about how to interact integrate OpenFGA with Envoy.

And uh and see you there. All right, thank you very much.