Sponsored: Authentik is rethinking PAM for AI agents

0:03James Wilson: Hey everyone, I'm James Wilson and welcome to this Risky Business sponsored interview with Authentic Security CEO Fletcher Heisler. Authentic's open source IDP just recently got a pretty major update and when I scanned down the release notes, the first two new features really caught my eye and that was privileged access management and agent accounts. Now, they caught my eye because to me, they kind of seem at odds with each other. You know, PAM is the more traditional humans approving humans access requests just in time for a specific, you know, time limited period or whatever the controls might be.

0:39James Wilson: And look, it's an important feature to have in your IDP and authorization stack, but we know it has problems. It suffers from not least of which things like authorization fatigue. And, you know, to me, the problem only gets worse when you're then adding in agent accounts because, well, an agent will just relentlessly request permission and access for seemingly anything and everything all the time. And so with this sort of cognitive dissonance in mind, I wanted to chat with Fletcher about, you know, why these two features and why now? How do they intersect? Do they intersect? What's the strategy here and the decision-making process that went into delivering these features?

1:20James Wilson: And it turns out there is a lot more to this than just what the release notes convey. And so I'll drop you here into the conversation where Fletcher talks about their high-level approach to this and the problems they were seeking to solve. If you do want to know more about Authentic, check them out at goauthentic.io. That's Authentic with a K. Enjoy. The way that we see us as an IDP, we want to make things as automatable and as flexible for users and administrators as possible. And I think what we've found with the use of agents is everything you should have been doing before already is even more important.

1:58So you can think of an API for everything, infrastructure as code, token-based access, no hard credentials. And the list goes on, but it's even more important when you have this proliferation of agent users. There's this sort of old-school access requests and sort of request fatigue. and that's a little bit of an unsolved problem and it's it's rearing its head even more so when it comes again to agents because now you have another order of magnitude or two of users

2:31James Wilson: requesting access right and this is exactly where i sort of that that is the key point that i thought of when i thought i'm not sure how these two coexist and let me just give you my lived experience with you know a pam system now given this was a couple of years ago so i'm sure things have improve. But, you know, I've seen privilege escalation rolled out the best of intentions. It makes a lot of sense on paper, right? You should have least privileges. You should have a way to escalate that up. But the number of times that an authentication request is approved because you had the right hallway conversation with someone or worse, you know, a request gets approved because we're just like, I'm sick of approving these damn things.

3:05James Wilson: I'll just do it. That fundamentally erodes how those systems work. And exactly as you just sort of touched on there, agents only make this problem worse because your agent is relentless at at wanting to request access for doing all manner of things so maybe just start with the human aspect of this how did you think through how to build pam that wouldn't immediately have those those human-based um fatigue problems sure and i won't say we've magically solved that uh request fatigue problem entirely um but you know we we aim to be as flexible as possible and so if your organization is one in which users are clicking through a dashboard, requesting access to individual applications.

3:47They are being given individual grants, expirations, and notifications to go along with that and so forth. You can do all of that. However, I think where things are heading with users and especially with agents is around blanket policies, is around time-based access, is around getting as close to zero trust as possible so that by default no one has access to anything they don't have to have at that moment but you make it as as seamless as possible whether that's you know a slack integration or just an api or simply for you know maybe something that's less critical this can be something that i request access it's get it gets auto granted but also logged and so people can look back on that and verify later on.

4:36Why did that happen? Should that have happened? As opposed to other policies, other types of applications, other types of access where you might have more stringent requirements in place.

4:49James Wilson: I guess that touches a little bit on the other question I wanted to ask you here around this, which is why do PAM now? Why this? Why now? And I think you just give me a little bit of insight there and I want to test if I'm hearing correctly. is it that you see that this is a fundamental way to enable an even lower level of least privilege whereby if you can make it flexible enough to do approvals either automatic granting policy-based or only at a human when it absolutely has to that puts customers in a position of having the flexibility to be even more restrictive of the base level permissions did i hear that right it's exactly that and it's aiming to cut down on on manual work and manual reviews and so forth where you need to be as locked down as possible but not create more work by doing so.

5:37Now on the agent side and why this was overlapping with a lot of our, we've supported service accounts as we've called them for many years and they have kind of a sexy new name now. And obviously in terms of token-based accounts.

5:50James Wilson: Service accounts might have a sexy new name, but Fletcher, they never really had a very good reputation in terms of security. For sure. And we're seeing many more use cases now. Yeah. And so the way I see it, it's a bit wild to me that there are so many companies and products springing up in the non-human identity space from scratch, trying to solve this problem of agents' identity access. And what they're all eventually finding is, well, now we need to build a full IDP on top of that. It's kind of all the same problems again. and it's taken us seven, eight years to build a full IDP. There's a lot there to do.

6:32So it makes much more sense to us to say, if you want these agents to do all the same work that a human does, you need to give them the same kinds of ideally very locked down and restricted access and abilities within the platform. And so we see it as agents being owned by human accounts or at least tied to some responsible human account but being scoped to those permissions at a maximum. And then similarly, agents being able to request access. Now again, this is an unsolved and messy problem in terms of how much do I want my agent to be requesting and do I want to be approving. I think we've pretty quickly gone from we must have a human in the loop to, well, I don't really need to be in the loop all the time for everything as we scale up this agent work.

7:24So really what we're trying to do is provide that flexibility where an agent similarly can request access or you can set up policies to say these sorts of applications, give them access, but don't just give them unfettered, untimed boxed access. Only when it's required, only for clear reasons there. And include logging, include notifications, etc. make sure that you can go back later and analyze what's happened as well to make sure that you're making sane decisions along the way.

7:57James Wilson: But in terms of even just getting down to the basics of understanding how you've established the paradigm for agent identity, in my mind, there is kind of three different flavors of agent identity. There is an agent identity that is entirely separate from the human. There is an agent identity that is tied to, as you say, the responsible human. And then there is an agent identity that for all intents and purposes is the human. And it's not that the identity is separate, but there's some other metadata or indicator that these actions were taken by an agent. Take me back to, I guess, the philosophy behind this.

8:31James Wilson: How did you guys wrestle with, you know, trying to work out how do we even navigate this from just that base sort of paradigm perspective? Yeah. So we worked with Cloudflare. They've been a customer for a couple of years on the workforce side. and they had a recent blog post on sort of their take on agent identity that I'm very aligned with as well. I think one of the things that they've enforced is that every agent needs to be tied to some human user or human user's internal, I don't know if it's username or email address or whatever, but we've taken a similar approach to say, you know, you shouldn't just have an agent running amok.

9:10Some human decided that this was a good idea. and even if it's an agent of an agent of a human there is someone at the end of the line who decided to enable this or turn this on that might be just a general admin user that might be an employee and scoping to the maximum of what that person can do as well so that you don't have a sandbox that you can easily escape from using your agent who's also run a buck So I think, yes, there are many different flavors, but at the end of the day, how we currently see it, the humans are still in charge of the overarching decision, even if they allow their agent to have as full access as possible and make decisions autonomously.

10:00James Wilson: which i can see how that works in sort of a day one environment of you just establishing these agent identities they're going to be owned by the user that has requested that identity they are the you know i guess the the buck stops with that human the in in regard um but what about the life cycle of this you know people move on people change jobs you know the last thing i want to have happen is when john down the hallway leaves all of his agents suddenly stopped that were you know driving the call center i don't know like what what's what how do you how do you manage this overall? Yeah, that's kind of a solved problem.

10:31It can get hairy with the sort of UI UX side of things. And you certainly don't want to accidentally stop a job just because some account has turned over. But as an example, I don't want necessarily everything that was tied to John's email to go away either. But you can forward and redirect and have an email inbox owned by the manager by default. And so similarly, we can set up rules over time to say, this agent account, James is deprovisioning his account, but by default now rolls over to the manager and they get to decide, along with notifications, what to do about that. But intentionally raising that early on so that folks are not caught unawares that it gets trickier when potentially, and we haven't seen as yet but you have agents who are provisioning other agents who are then you know down the line uh getting work done on behalf of on behalf of yeah well that's a good point is there a is there

11:35James Wilson: a limit in force either a hard limit or a soft limit on just the number of delegations that can be configured to avoid that on behalf of on behalf of n squared uh it's a good question that i don't think we've seen in practice just yet um but uh yeah at some point you get so granular that you You have to question what your agent is up to if you're getting too many cooks in the kitchen. A couple of times there you've mentioned the concept of the agent account being scoped to the maximum of the human's account. Wouldn't that create a bit of a, almost like a permission inversion problem where your most permissioned users are probably also the people that are configuring, creating and building these agents?

12:18James Wilson: wouldn't you almost want kind of, I don't know, something that sort of decoubles that a little bit so that the agent can't by design get to the maximum of your most senior developer set of permissions? Like I just found that a little bit odd when you said a few times there that it's scoped to the maximum of that user. What's the thinking behind that? Yeah, I guess what I meant by that was not that it is by default capable of all the things that you are as well, that that is the hard limit that we are putting there, but it's by default capable of nothing whatsoever. And so you have to decide for your agent what grants will I give it in terms of entitlements there.

12:59And I only mention it because in general we try to make as few decisions as possible within reasonable bounds to say what you can and can't do with the system. But that's one where we will enforce a policy upon the system because nothing else outside of those bounds makes sense.

13:18James Wilson: Okay. So it's more of a case of, you know, if, again, we're using John down the hall here as the example, John's account, you can just sort of rest assured that there's a base level of safety here where the authorization scope can't extend beyond what John had by design. But of course, that's not the default you'd start with. It's just more of like a operational maximum, as you say, that you can sort of, I guess, take some comfort with or default knowledge. Yeah, and even beyond that, there's a lot that we're putting thought into how to push administrators and users toward saner and more secure decisions.

13:56so saying you know by default this should be as time box as possible and you know how can you essentially make sure that you've given the the least possible permissions uh necessary for the task at hand uh rather than making it as easy as possible to say i'll just uh apply all and

14:15James Wilson: and best of luck yeah again that comes back to the uh that apply all and and best of luck is the kind of output of that alert fatigue and approval fatigue but also you know when you said they're time bound time bound also feels like something that's a bit of a concept that made sense when this was humans approving human scale actions now when you've got humans approving machine speed actions in the form of agents how relevant is that time boxing really going to be and how do you manage i guess an ever shrinking time window when an agent can just get things done faster if it's got more tokens per second.

14:50Yeah, I don't think we're there yet, practically speaking, just in the time I've spent waiting on agents.

14:56James Wilson: But how long? How long is sort of the question? Fair enough. I think that's the practical concern there is, you know, an agent misscoped and misaligned can do a lot of damage very quickly, which is maybe the part you're getting to there that, you know, it doesn't matter if I only give it a minute, that might be a really long and painful minutes depending. So I think it solves one problem of did I forget that I gave these permissions earlier or did I give them for a particular task and then move on to another task and didn't remember in time that it had additional access that I was not expecting.

15:37So it's really for solving that sort of problem. But there's a second trickier problem of how do I make sure my agent doesn't go off the rails when it's going to get even faster and faster doing that and we might might not be the best place to solve that one so that is really fair pushback i i hear what

15:56James Wilson: you're saying there that it's not about preventing or controlling what an agent can do in that minute it's making sure that a minute is a very important control that gets connected to and ultimately governs that access whether it's an agent or a human because if you don't set that you know therefore you know don't worry about the messy minute the agent might run it could turn into 24 48 hours so i so i get it you've got to have that time-based control yeah another thing that i've been playing around with thinking about we're not currently implementing i haven't seen this in practice elsewhere is task-based access so once you have accomplished the goal you should be deprovisioned from being able to accomplish that goal again that might be you know that's inherently a little less easily technically bound.

16:46But I could see the world moving toward that sort of direction to say, hey, agent, accomplish this task for me. And once you have, I don't want you to be able to have the access I gave you specifically for that end, regardless of whether that took you an hour or 20 microseconds. Right.

17:06James Wilson: I mean, that could be an interesting extension of the goal mode or the Wiggum loops and other sort of things that are emerging in terms of give the agent a very bounded task and let it iterate on that until it gets it done. And then at the end of the loop say, hey, release my claim on those permissions. Right, and then take that token away. And then take that token away, exactly. All right, so listen, we've covered a bunch of ground here. What I have taken away from this is that it's not that privileged access management, the old humans approving humans access, is at odds with the idea of agent's identity and them moving at machine speed.

17:41but rather you've taken a very considered approach here and said,

17:45James Wilson: we've got to have the basics of a very flexible privilege access management system in order to build the right workflows that allow minimum privilege for humans and flexible workflows for stepping up authentication. Because if that works for the humans, we can likely also translate it to work well in the agent space. And you've made some hard rules there around your view is that the agent identity is always tied to that responsible human. But as we wrap this up, Fletcher, I'm just curious as to, you know, what was the path that, you know, were there paths that you explored that, you know, didn't work out so well?

18:16James Wilson: Like, were there other ideas that you looked into and explored and just went, no, actually, this is going to be a problem? Like, what led you to this path that you got to in terms of other things you might have explored that maybe didn't work out as well? Well, there were many, and many of them are publicly documented. Since we are open source and everything is source available, you can see a few fits and starts when we were figuring out agent users and what that should look like and how PAM should work. We build a lot of this with not just our customers in mind, but our customers and end users directly involved in the process as well.

18:53and so it's been an ongoing dialogue where we test things out and whether that's actually live in a staging environment see how this works out or just sort of the on paper now that we've written this, does this approach make sense so I don't think I can I could probably go off on the next 10 minutes of the various flavors that we'd considered and discarded but this seems the most sensible approach for now.

19:25James Wilson: But thankfully we don't need to because it's all out there on the open and people can look through the history of this which is one of the many beautiful benefits of being an open source project and particularly an open source IDP which I think is if there was an area where you could benefit greatly from all the transparency that comes from open source IDP is certainly a space where it makes a lot of sense I think. But Fletcher, thanks so much for dropping by for a chat mate. It was great to meet you and I've really appreciated the time that you've spent with me today. Likewise. Thanks so much.