Allie Howe Welcome to today's episode of the Insecure Agents Podcast. I'm your host Allie Howe, and today we have Pavan Kulkarni, who is on the engineering leadership team at WorkOS and Aaron Tainter, who recently led the FGA product launch. Aaron and Pavan are with us today to talk about agent identity, what exists today and what's missing, and how their FGA product launch can help. Aaron and Pavan, would you like to introduce yourselves?

Aaron Tainter Sure. Maybe I can go first. Yeah, my name is Aaron. I work on the engineering team at WorkOS. I do primarily OAuth, but I still work on the enterprise side of things, so do some work with SCIM and directory sync. I've been working at WorkOS for about a year and a half. Before this, I was at Carta and I built out the FGA system at Carta, but I've just been on like a bunch of different platform teams over the last several years and been in the Identity IAM space for like maybe six or seven years.

Pavan Kulkarni Cool. And I'm Pavan. I'm an engineering manager on the enterprise team at WorkOS and I've been here for almost 3 1/2 years now. And our enterprise team kind of owns SSO, directory sync, audit logs and pretty much everything authorization like RBAC and FGA that we've been working on for quite a while now and before. WorkOS I was. At Lyft, the ride sharing company, where I did a lot of similar work, but we were just solving all those problems. For Lyft. But at WorkOS we are trying to do that for pretty much any B2. B SaaS application.

Allie Howe Amazing. Very cool. Yeah, I'm very excited to talk about the FGA launch that you all just had. But first, I'd like to set the stage for why we even need new solutions like FGA, which is fine grained auth for those that don't know. And I'm really excited to have this conversation about agent identity because it's not the first time we've had a conversation around agent identity on the Insecure Agents podcast. I think the last time we had this conversation, which was like, I don't know, 3-4, five months ago, it was a little bit theoretical in terms of what we were expecting to sort of like run into.

We knew that the infrastructure for identity wasn't really there for agents, and we needed to fix it or add a lot more to it. But the difference now I feel like is developers and users of agents are starting to really feel the pain of not having those solutions in place today. So the urgency around this conversation seems increased, and I think that's for a few reasons. One, I think it's because people are starting to manage an exponential amount of static permissions for agents and security teams that are managing all these different roles and having to recreate them for the same agent to do an exponential amount of different tasks, which becomes impossible.

And also developers trying to figure out auth around things like agent memory, which is a huge conversation right now. And how do you create permissions around what you can store and what different recollections from the memory you can pull out depending on what user you are. Not only that, but also integrations with new tools, skills, and MCP servers that you know may be unexpected at design time. We didn't expect this agent to need to use this resource, but it does need to complete this task. So how do we provide authorization and that kind of a landscape? These are things that developers and builders are running into day over day.

And so This is why I feel like we need new solutions like FGA. And I just wanted to ask you all what inspired the FGA launch? Was it that or was there other problems that you were seeing in the market?

Aaron Tainter Yeah, I think like the industry as a whole, like not just for agents, but like for apps that we use today, but are lacking in like a lot of this fine grained access. Like if you think about how users grant access on their behalf today with like OAuth, it's very coarse grain scopes. It's not like you have access to this specific resource within the system and much less so like what's the hierarchy of access? So if you give access to a top level feature, that probably implicitly implies that there's like a bunch of lower level things that you can access as well. And so like, that is the primary reason we're looking into FGA and it fits really well within like the enterprise ecosystem of products too.

Like when you're building out a very simple like single user app, you, there's not that many resources, so you don't really need FGA. But once you have like whole teams of users working on projects and collaborating, you definitely need like finer grain access so that you don't just like give every user access to everything. I don't know if you want to add anything for long.

Pavan Kulkarni Yeah, I think. You kind of. Covered most of it, but what we've kind of seen is that like around 50% of SaaS applications are pretty simple. Like you have. A simple organization tenant model. You have a bunch of roles, but as soon as these applications evolve into their next stage where they add like more complicated hierarchical resources, you start evolving into. I need a role that can only manage this workspace. Or. Specific project, you might have seen this on linear where they have like a bunch of hierarchical resources and the annoying thing is that like pretty much every app developer has to figure it out localized way like they are building this feature, they end up like coming up with their own authz model for it.

And when you zoom out after a few years, it's like everything seems like a mess. So the thing that we are trying to do with FGA, we'll try to nudge you in a more opinionated way to structure your authz hierarchy so that not only it allows your application to evolve, but also sets you up for success when you eventually start selling to enterprises who will bring in their own set of needs on, like syncing these roles from. IdPs through like. SCIM or SSO and we have a pretty opinionated way to like solve these problems. So yeah, pretty excited with FGA.

Allie Howe Yeah, that's really interesting to think about. And do you think that FGA is future proof too, as different protocols and different papers come out and evolve for the like what the landscape looks like in the future?

Pavan Kulkarni As a core FGA, I would say, I mean like Google came up with Zanzibar like I think 10 years ago. But if you kind of dig deeper, that solution only makes sense for products that are kind of building the next Google Docs or Notion because there's like too many high cardinality resources or there's like too many hard to predict relationships forming between different resources, which I think Zanzibar is like pretty good solution for it. But the reality is that 95% of the applications out there. Are. They can mostly work with basic RBAC roles and permissions are like WorkOS opinionated like FGA, where we kind of introduced this resource types and scopes.

It's much easier for a developer to grok because they're coming from an RBAC model and you don't want to throw them into hey, go learn this white. Paper. And try to model your entire schema into this like complex hierarchy instead of that you like WorkOS FGA was a bit more of like extension of RBAC. That's how it should feel. So we're trying to nail the DX as their app. Evolves.

Aaron Tainter Yeah, I was just gonna say like, I've built like 3 different FGA systems now. And the big problem it with like the Zanzibar style solution is that you have this like complicated schema that's usually managed by one team. And then like everybody else at the organization doesn't understand it because it's so complicated. But everybody understands the roles, like roles and permissions are baked into like every app. And so, yeah, we're just trying to figure out ways to make it easy for the developer to understand like this complicated thing, which is this hierarchical based access and with familiar concepts. And yeah, I think I think we kind of like nailed it with this.

So I'm super excited for the launch.

Allie Howe Yes, definitely. And I read something in your blog around how FGA is like well positioned to become the logic layer for MCP as well as MCP begins to roll out support for rich authorization requests. I think that's another good example too of how you know this could be future proved and easy for developers to use.

Aaron Tainter Right. Yeah. Like going back to what I was saying earlier, MCP is like an OAuth 2. 1 spec. And so you can like grant access based on scopes. But like by nature, scopes are pretty coarse grained. It's like you can read all messages that the user can read or you can edit all whatever documents that a user can edit. And but like this like rich authorization request is like something that's being added to OAuth and it's but it's just a data container. It's just a way to specify like only grant access to this one thing or maybe a few different things, but it doesn't tell the agent like what's available or what you should like it should be able to have access to from the application side.

And so we're thinking about more of like the access control structure and what are the things that the user has, what are the subtrees or the related entities under those entities that a user has access to that the agent should also have access to. This is what I'm calling like resource discovery and something that we're like really focused on right now.

Allie Howe Gotcha. Yeah, no, that's, that's super exciting. And I feel like to people are starting to discover these problems more, especially with the rise of open claw, because there's users now that want to use open claw to, I don't know, book a flight for them or to make an appointment on their calendar. But you probably only want your open claw to access certain tasks within the scope of. I don't want to give my open claw access to my entire calendar, but maybe it can only make invitations with like this one user or this one guest for example. I only wanted to book this flight, but only if it's within this price range to this destination.

So then you run into task based like authorization and not just like full scope authorization. And that's just a super difficult problem to solve. And when I was reading your blog post about FGA, you seem like the way that you all are starting to solve that is to sort of like just do a diff between the user's permissions and the agent's permissions and make sure that the agent has the correct subset of permissions be able to go and carry out that task. Is that correct?

Aaron Tainter Yeah, for sure. Like so we're kind of thinking it thinking about agents in two, two different ways. There's like, we think there's like two different types of the agents and there might be more going forward. But like based on what we see today, one type is called on behalf of. And so you can think of like Cursor or Claude Code or something that's like you launch a task and then it goes and does stuff on your behalf using like an OAuth flow and you just sit there approving requests as it like asks you can I do this thing? And so I think there's like some gaps there.

And one of the gaps is like it has the same access as you, right? And so like the short term fix is you just have like a bunch of approvals and you just keep hitting yes, or you just grant access to everything. And then there's like the autonomous agent, which is something that you might provision in your application as like it's own identity and that might have a scope of permissions that it has, right? But the problem with these like autonomous agents is that they might have more permissions than the users that are interfacing with them. And so you might accidentally expose some data to a user through an agent when that user shouldn't have the access to it.

The example is like, say you have a agent that does like financial reporting or something. And maybe that agent has access to a bunch of reports that a user doesn't access to. They ask the agent to do something and then it leaks information from one of these reports. And so that's really where we want to take. We want to look at the access that like a user has that's interfacing with the agent as well as the agent and figure out where those permissions intersect so that we can kind of limit this like the response of what the agent produces to whatever permissions it's scope like that intersection gives us.

Pavan Kulkarni Yeah, few points to add there. I think like currently the ecosystem is extremely binary like either you dangerously skip permissions or you keep hitting allow on every single permission escalation, right? So I think the the the long term things will probably. Evolve somewhere in the middle. Where? The authorization system has to truly understand the intent of the agent or the goal, or the task it's trying. To do. And then dynamically figure out like what are what's the boundary resource boundary of resources that it should have access to it. So anything within that should probably be auto approved so that it's not annoying because all the resource accesses kind of make sense and anything outside of that should probably be escalated.

I think that feels, it looks like that's where probably things are evolving now, but obviously nothing is set set in stone that things are evolving on the protocol side like applications are tinkering to figure out what the right user experience is. So. But we feel like somewhere in the middle probably is the right answer.

Aaron Tainter Yeah, like you shouldn't have to just sit there and like, approve everything, right? Like it should have some basic access and like maybe at some point it might need to do something that's like slightly outside the bounds of its access, right? And like, that's where we should, we should like launch approvals, right? But yeah, it's definitely like annoying to have to like sit in cursor and just approve everything. But you also don't want to give access to everything too. So it's like a trade off there and.

Pavan Kulkarni The thing that makes FGA relevant in this context is FGA kind of allows you to structure your entire resource hierarchy so you exactly know which subtree of resources to kind of scope for that task. If you have a pretty bad resource hierarchy, then you pretty much have to are forced to give access to everything. So that's where we think like WorkOS can do a bit of like opinionated FGA structure to our customers and kind of push on the standard.

Allie Howe Amazing. Yeah. I'd love to chat more about the user experience there, because I think compared to not having FGA today, managing a ton of static permissions for agents is very painful. You can't predict everything the agent is going to need to do or have access to. So one, it's kind of impossible from the start, but even if it was, you'd have to create so many different permissions for it that that would feel like too much work as well. How easy is it to get set up with FGA in terms of like discovering these hierarchies, creating them, labeling them, entering different governance policies or like, what does that look like?

Aaron Tainter Yeah. So we built, well, for at least for our FGA system, we built it to be built it to be like an extension of RBAC. So like most companies start with RBAC. We have this like concept of your authorization journey where it's like you start with login and then you add like basic permissions roles. Eventually you get to like FGA and like identity mapping and stuff like more complex stuff like that. But yeah, the idea is that you like, as you add these features, it shouldn't be, it should be really streamlined. Like there should be no like rewrites that happen. And so that's why we're developing FGA to be kind of like an extension of RBAC.

So you can use all of your existing RBAC roles, but then you just add like resource scoped roles for the things that you want to grant explicit access to. Like say I have a engineering group that should only have access to like an engineering project or maybe a set of like engineering documents or something like that. You should be able to create a role that's scoped to one of those resource types and then grant access to it. Now, if you have a project, maybe that has like resources beneath it. Like if I have access to a project, maybe within projects I have the apps. That's naturally like something that you would put into your resource hierarchy and naturally something where the permissions from the higher roles should flow down into those resources.

So for instance, if I had view access on a project, I should probably be able to view all of the apps that are within that project. And it's kind of the same thing with agents too, right? It's like if I want an agent to go and look at some resources in my system, I don't want to have to grant access to every single app. I just want to grant access to a workspace as like a viewer and then just have it like iterate through everything within that workspace to find something. So that's kind of like how we're thinking it applies to the agent use case.

But yeah, the goal is just like make it as easy as possible for developers to ramp up on this thing and extend their existing system.

Allie Howe Amazing. Yeah. I feel like WorkOS is very well positioned to cater towards developers since you have tons of developer customers already that go to you all for authorization and identity solutions. Is there anything in particular from your customers that you were seeing or they were asking for that helped you iterate or decide to launch certain features within FGA?

Pavan Kulkarni Yeah, I think the biggest friction we kind of saw in the, we didn't do like 1 iteration of this before, which was more on like the Zanzibar inspired version of it. I'll give you an example like maybe I'll zoom out a bit and explain like you probably would have used more different applications where one application it has beautiful intuitive information architecture. So it's you just kind of understand you don't have access to something, you know who to escalate it to or kind of intuitively understand that I don't have this permission, that's why I can't operate on something. Now there are some apps where you have.

No idea why something did not work and the permission is somewhere hidden in the docs and you have to kind of escalate it to your IT team who has that permission and then you can go and do something. So this exact same problem will be true for agents who will have to like understand your resource structure. The problem with like not being opinionated in how this should be structured is that like the app developers have limited idea on what structure would make it easier for agents and humans and like enterprise adoption. So they kind of are making localized decisions. So the new iteration of WorkOS FGA is trying to come up with.

Hey, like RBAC. Is something that everyone understands, the developers, IT admins, hopefully the agents and and extending it in a more structure like tree or graph. Level. And kind of clearly separating between principals, resource types, scopes and user groups, it becomes much intuitive for pretty much everyone involved in there. And WorkOS like we not only our API, but we have a lot of like dashboard user experience, which is, which makes it extremely simple for people to just it. It feels very intuitive when you try to set it up rather than reading a very long like schema language or custom DSL. That's where we saw a lot of friction, so we tried to address that gap.

Aaron Tainter Yeah. I also want to just like add on to this too, that like this is especially relevant for agents because there are a lot of new apps that are spinning up and like the going zero to 1 like 0 to enterprise, I guess is like happening much faster. Because in the past, like a lot of these apps were built for single user. And like over time they might get more traction, build more features out and then eventually sell to a bigger company. But now and, and, but if you think about like agents, agents are similar to humans where now we might have one person that's spinning up a whole team of agents instead of the managers spinning up a team of humans that might be using the app.

But like the concepts are similar. You still need all of this stuff that you needed for the human teams for agents. Like you need auditing, you need provisioning for the agents, you need approvals or access controls. And so like, if you know, if the end goal for enterprise software was like FGA, it's like you need to start thinking about that a lot sooner so that your app works with your customers that want to use agents.

Allie Howe That makes sense. And for those that might not be completely familiar, I like how you focused on RBAC as something that everyone understands. But why does traditional RBAC fail for agents today?

Aaron Tainter Yeah. So I mean, I think it's goes along the lines of what I was talking about earlier. Like agents are have an intent. Like you give it, you give it a goal. Like I want it to be able, I want you to go and do something right. And. You might not know what steps along the way it's going to take to get to that goal. And if you just go and give it granted, really coarse grain access, it might hallucinate and then do something that you really don't want it to do, like maybe send money to a random bank account or whatever it may be.

So like as a user, I want to be able to specify like, I want you to go do this and I want you to have this minimal access. Don't go outside the bounds of this access. But in like the current case with like OAuth, it's the scopes are just too coarse. So we need, we need FGA in order to kind of like scope the tasks for for these agents.

Pavan Kulkarni And you kind of look at it, you already have goal based authorization today, but it's just that it's socially evolved where imagine like there's a financial manager role. You, you, there's usually a person that you hired for that role who has a set of intent and responsibilities that they carry with that role. So that already exists. Now the problem with agents is that they are more general purpose. They are probably your financial manager as well as marketing manager. Or. Like some brand campaign, he tries to do everything in the in the same application. And it it's. Continuous. It doesn't sleep, which means it's constantly changing it's task and access to resources.

So how do you kind of capture all this into a role that's too constraining, right? Like you can't predict every single permutation of what exactly is needed for this goal and create a predefined role for it. That's that's what we, I mean, it's generally known as role explosion that it will be like 100X worse with agents. So you don't want to end up in that place. So you end up needing FGA to solve like the agent access problem.

Allie Howe That makes sense. One of the interesting conversations I've had recently at a CISO dinner that I held here in San Francisco was asking them which of the new OWASP top 10 for agentic applications entries keeps you up at night the most. And of course, there's ten of them. And the last one on that list is rogue agents. And that was what they cited as the scariest thing for an agent that's maybe, you know, misaligned is now no longer, you know, following whatever rules or permissions that it was set out to have or is trying to complete tasks that maybe it shouldn't be. Could FGA help with revoking an agent where, like, trust is broken and we no longer want this agent to have access to certain resources?

Aaron Tainter Yeah, I mean, I think so. I mean, I think a lot of this stuff like is like draws parallels with humans, you know, like we've kind of like already solved these problems for a lot of cases. Like if you have a malicious employee, like you want to be auditing, like employee actions. If somebody, somebody does something that they're probably not supposed to do, should be notified of it. Or maybe if somebody is requesting access to something that's like beyond the scope of their job, like that should throw some red flags. It's just like the life cycle of agents is different and like they operate much like as Pavan was saying, much faster than humans.

So I think like as a like a infrastructure provider like WorkOS, we need to be thinking about how can we automate this stuff so that we can catch it much faster than like just having a human in the loop. But I don't like, I don't know if that you kind of think the same way Pavan, but.

Pavan Kulkarni I think you perfectly captured it. So I guess it's you just need to translate like what you did for humans and what's relevant for agents. Like for example, you probably have an allow list of tool calls that are allowed, which you probably did for humans too. Like kind of have some kind of filters on what kind of websites can be visited or not. So it's the same same kind of filters and sandboxing. Environmental context needs to be kind of captured and like set some for agents. So that's one thing. And the other thing for FGA is like stuff like ephemeral privileges. This concept does exist for humans too, but it's not that prevalent where you don't get a permanent access.

You kind of get on the fly when you, when you, when you let your intent know, you kind of get whatever like newly resourced token minted just for that subset, subset of resources. And then you go perform that action and then it's active only for a few minutes. And after that, you pretty much get that privilege revoked. So there are a bunch of things that you should probably use within FGA, but FGA won't solve all your problems. There's like a whole ecosystem around FGA, like policies and like sandboxing that you probably need to like implement to guard it yourself.

Aaron Tainter Yeah. But I guess like going back to your original question, like because we understand the access control hierarchy, we can easily like flag when an agent tries to go outside the bounds of the access that they were granted, which should be scoped to like a resource. It shouldn't be organization wide or tenant wide or whatever. So, yeah, I think there's like, levers there that we can pull to kind of, like, flag these things and understand what's happening before a human can see it.

Allie Howe Yeah, that makes sense. Having that logging in there is is critical, especially for things like agent memory where we're trying to understand like, how did this even get in there or why did this user perform like this action with the agent also helps create some sort of like, blame, I feel like, because I don't know if we've solved this as industry yet, but like, what happens if an agent becomes compromised and you were the user that kicked it off? Like, are you the user at fault or is it the agent? I don't know who, like, you know, gets the blame there, but I feel like these are all problems that enterprises would want to have solved for them.

So that's really cool. And then in terms of what comes next for FGA, and then also just think the agent identity infrastructure landscape in general, you ended the blog with thinking about user groups as authorization subjects, FGA role assignments. Do you want to talk through what, in your opinion, you think comes next?

Pavan Kulkarni Yeah, there's a ton of things that we are kind of working on, the stuff that we build the first iteration of FGA. Is for. Like the human use cases. Like, hey, everyone who was on RBAC, you're trying to evolve this into FGA. OK, here's a great solution for you. And there's like two things we are trying to optimize for One, like what do developers need to evolve their application both for agents and humans? Like how can we evolve FGA so that it fits their needs? And the second interesting thing that a lot of applications don't immediately worry about is how does this plug into enterprise ecosystem?

For example, there's an entire authorization model around syncing roles and permissions from IdP like Okta or Entra through SSO and SCIM, and these need to be mapped to granular resources. For example, let's say there's an extremely sensitive project that's deeply nested from the organization and the workspace, and you have to sync the set of users who have access to this project or the set of permissions they have access to. Now there is no protocol out there that can do this well neither can SCIM and SSO like very coarse grained. So we can only map them to tenant level roles. So like the stuff that we are we have on the road map is to like once for all solve like bridge this gap.

Where? App developers have to never worry about what the enterprise side of automation looks like. We can map it to pretty much anything in the resource hierarchy. And this kind of extends to agents as well. Agents. You can think of it as just another. Use. Like principal type, it used to be user, now you have agents. We just have to stay close to the protocols and standards that are evolving and see how we can plug that into the FGA system and so that developers can continue working on their product differentiating features and not worry about keeping up to date with all the evolving standards. But yeah, there's, but there's so much stuff evolving.

I would it would be hard for me to say this is exactly what's the next thing that we're working. There are a few things that we have with the idea. On the other stuff, we are kind of actively monitoring.

Aaron Tainter Yeah, like, as I mentioned at the start of this, I've been working on platform teams for a while and like, it's not what I've learned is it's not good enough to just like make something that works. You have to make something that people want to use that also solves all their problems. And that's kind of like our design ethos here is like make something that just like works really well with all the other stuff that we have. So like once you're on the platform, it's like, oh, I can just like enable this with one click. Let's do it, you know, so I, I think like all the stuff that we want to build for like agent identity and FGA, we'll all have that kind of like interconnectivity and just like work really well for the the customers.

Allie Howe Yes, that's key for sure, because developers don't have time to be keeping up with all these different standards. They just need to be able to quickly build and ship agents that enterprises can look at and say, yeah, this is secure, I can trust it and I'm ready to take this on. Super cool. But yeah, very excited to continue to follow where FGA goes. Have you had any like feedback from developers? Like so far, I know it's been out for like a couple weeks.

Pavan Kulkarni Yeah, we, me and Aaron have been talking to. Like I think at this. Point, we have talked to more than 50 customers like we talked to them kind of shaping the problem itself. We got a ton of feedback on the early designs like before we even implemented it, we wanted to kind of shape the problem and solution with them. So it's been, we've heard great feedback so far. Where? Customers kind of feel it's intuitive, like everyone comes from the RBAC world. They like. The FGA concepts kind of felt way more intuitive than like the generic, like here's a extremely flexible schema, go figure out the schema language.

So that's like being one of the biggest feedback that we've heard that it's much easier to adopt, but the usage is still trickling in. It's too early to like kind of holistically get a solid feedback from customers, but the reception has been based so far.

Allie Howe I mean, yeah, I would expect it to be. That's fantastic. Well, super goal. I'm excited to continue to follow FGA. If people listening want to join in on the conversation, where can they find you on LinkedIn or social media and how can they try FGA?

Aaron Tainter Yeah, Aaron Tainter on LinkedIn and you can just reach out to us on, you know, through the channels on on our WorkOS website.

Pavan Kulkarni And I'm Pavan Kulkarni, you can find me on LinkedIn. And to check out WorkOS FGA, just like go to workos. com/docs/FGA, you'll see all the documentation, API reference, and you can just sign up to WorkOS, you don't require a credit card to just test it out and staging every single feature that's available on production is available on our sandbox. So you can bring in your application hierarchy and test out anything that you want. So check it out.

Allie Howe Amazing. Super cool. Thank you so much for making the time and we'll see you all next time.

Aaron Tainter Thank you.