#368 - Sponsor Spotlight - P0 Security

This is identity at the center. Welcome to the Identity at the Center podcast. I'm Jeff, and that's Jim. Hey, Jim. Hey, Jeff, how are you? Oh, not so bad yourself. I'm good live from South Dakota. Jim McDonald. Yeah, you've been making a cross country move the last couple weeks here, so hopefully things are going well. Going well enough, we'll see you for one of our banter episodes and I'll get into it.

Yeah, people love the banter, but that is not today. Today is all about P0. So we've got a sponsored episode and so we are going to invite our guests on here in a second. But just to make it clear, right, this is a sponsored episode. We do these from time to time. Let's just get a little more, you know, product specific. I would say most of our episodes are more vendor neutral and we we generally don't have vendors on those episodes, but this gives an opportunity to learn more.

And this is 1 I think a lot of people will want to hear about. So let me go ahead and introduce P0 Security. You can find them on the web at P0 dot dev slash IDAC And we've got their CEO and founder, Sheshwat Sagal. So welcome to the show, Sheshwat. Thanks chef. How are you? I'm good. It's a little bit warm here, but I'm inside and as as we're chatting before we hit record, I

am very much an indoor cat. So I am totally fine in my, you know, air conditioned, you know, home studio, office, things like that. So hopefully things are going well for you as well. Yeah, no complaints. It's right at the start of the California, some of the best time to, to, to be living out here. Not that other times are any different, but my definitely my personal favorite time of the year. Yeah, it's tough to beat California weather.

It's it's it's generally pretty darn good. So yeah, congratulations and thank you for making me envious. And I'm sure a lot of people listening who are either sweltering in the heat that has been gripping, you know, a lot of the the US or around the world or whatever. Maybe. But let's find out about your identity background. So the first time we have people on, we just like to find out where they came from, you know,

from an identity perspective. So we're going to put you on the hot seat here and say, how did you get an identity? Is it something that you chose or did it choose you? Oh, great question. I'd say a bit of the latter. So I have been in engineering and R&D and product roles for the vast majority of my career and the the mid 2000, mid tier 2000 tens were a very interesting time to be building products out in the Bay Area. Why do I say that?

It's, it was a time where as you all know, cloud native development was, was going mainstream. Everyone was, was either moving to the cloud or if they started on to the within the cloud, if they were cloud native, they were experimenting with cloud native technologies and infrastructure like Kubernetes and various databases and such, right? And I built a variety of products across different spaces.

And the commonality in every one of those roles was that as development, as application development, as engineering became more and more cloud native, the, the problem of securing who has access to the, to the privileged resources became kept getting more and more complex until it hit, you know, what I believe as a breaking point.

And, and, and what I mean by that is that the old tools, the, the, the tools that are managing privileged access, which all of us are familiar with, you know, the, the, the, the legacy tools, which I like to believe used to manage walls and secrets, right? They were not built for an environment where privileged access meant access in the cloud.

And we saw this gap and we saw it becoming worse, you know, the the problem becoming bigger and bigger and bigger. And that's when I decided to start P0 with S my colleagues. And Fast forward three years, here we are. So you had kind of a personal investment here, right, of seeing this problem first hand with some of the roles you had before. How do you solve that?

So let's let's talk about P0 kind of upfront is tell us about P0 and then what are some of the capabilities that you bring to address those problems that you've just talked about? Great question. So let me back up a little bit and talk about the broader space that we play in and how that has evolved over the years. And then maybe that'll be a good segue for me to talk about the capabilities that we bring to

the table, right? If you think about the space itself, people call it in various different names, but at its core, it's really just managing privileged access or privileged access management, right? And 2025 years ago, the space was, as I mentioned, synonymous with creating words and secrets. And the, the, the definition of the space at the time was depended on what privileged resources were. So for people who've been like, like you and I, who've been in the industry for decades, right,

if we wind down the clock, wind back the clock. 20 years ago, privileged resources meant servers in the data centre or databases that were physically located on boxes within the data centre, right? And access to them basically meant create a root, a root account or a Linux administrator account or a database admin account, create a credential to those accounts, put them in a vault and then rotate those and then issue issue those credentials to people on demand,

right. I call this version of Pam as the vault LED Pam or the secrets LED Pam. Then you know, let's call it early 2000 tens. This was the early cloud era. And instead of servers and

databases being physically located within a data centre, they began to be located in a WSGCP Azure, right? And the very first use cases that people had was just lift and shift your workloads as they are from the data centre to the cloud, right? So then the the use cases for Pam translated to hey, give me access to databases and and and the virtual machines in the cloud, right?

Easy peasy, right? So in those very early days, the legacy or the vault LED Pams attempted to solve the same problem by checking in, checking out credentials to these databases and virtual virtual machines. The problem was there were too many of them, right? As, as, as is, you know, anyone who's familiar with cloud, native cloud development will know that infrastructure spins up, up and down on demand. And there's a lot of

infrastructure, right? So the old strategy of securing credentials didn't quite work as well as people would have liked it. It left SSH keys for virtual machines all over the place. It left database credentials all over the place and rotating those manually became a bit of a, you know, pain in the neck, right.

So, so the second fail evolution of Pam was what I call as a bastion LED Pam. And, and what I mean by bastion LED Pam Well, instead of giving and managing access to each and every one of these servers individually, people saw that it was much easier to just put a bastion in front of your network or a proxy or a jump host. The the bastions come in various different names, right? And and, and and just control the access to your network through this one server called

the Bastion, right. So, So what I'll call this the the pans of this era as the bastion LED time, they worked,

except they were also a giant, giant pain in the neck in, in, in ways in, in different ways than than than than the the older Pam solutions. The problem with spinning up infrastructure was that, hey, as, as when I know, every time you, you, you start deploying an infrastructure for anything you're on the hook for to maintain it, right? So maintenance and usability and developer experience was a major challenge in in using the Pam solutions of this era.

And and and secondly, the other big problem was once you were in the network, you still had access to everything. In other words, you had standing access as a developer to a lot of your privileged infrastructure, right? And hence to solve these problems is, you know, we believe we are in the third evolution of of Pam, which I'd

call as the API LED Pam, right? And that is ultimately the problem we are solving, which is that as P0, we want to provide a, a, a solution that can secure access to all of your sensitive assets in the cloud from identities of all sort use, whether it's users, whether it's service accounts, whether it's machine identities or whether it's AI agents, right.

And what's changed in the past few years is that we, you know, now the cloud IMAPIS are, are robust enough that we can use an architecture that's based on using those IMAPIS to, to secure privileged access on demand for, for any, for any identity of any sort. And, and, and that is what we call as the API LED Pam, right? It's, it's, it's a natural evolution of Pam from Bastian LED Pam or sorry, word LED Pam or secret LED Pam to Bastian LED Pam to ultimately to API LED

Pam, right. And it's, it's, it's meant for organizations who've been using cloud, cloud native technologies or hybrid environments. And, and, and what they have witnessed is that there are so many identities in the cloud, so many resources in the cloud users, you know, people call them non non human identities or service accounts or IM roles. And all of these can access the cloud in so many different ways that you really need a, a, a different solution that can work

at the scale of the cloud. That is, that is the ultimate problem we are looking to solve. So you, you talked about sort of the history there of Pam and, you know, the, the vault era, the bastion era, the API era. And I'm sure there'll be future errors that we are, you know, thinking about. How do, how do analysts think about this is when you have this conversation with folks like that, who are looking at the markets, like how do they, how do they see P0?

And do they, do they slot you in as a, as a privileged access management vendor or some other spot? Like how does that typically that that that conversation go no? It's a it's a great question That is, you know, like most spaces in cybersecurity, right, there are various overlaps with various different spaces. In particular, you know, there is a reasonable overlap between Pam and IGA, right? We do solve some IGA related use

cases as well. And, and for the most part, when people, when analysts look at us though, it's, it's, it's, you know, we, they, they've recognized that most of the capabilities that we bring to the table are, are the domain, are within the domain of a next Gen. Pam vendor. And that's what people tend to recognize us as as. OK, makes sense.

You know, nobody likes to be put into a box I think, but I think that's it probably helps people kind of understand like where things fit sort of together in a market. I got to ask, P0 is such a a unique name. Where does the name P0 come from? So the story here is that in my last, in one of the companies that I worked at before I joined, before I started P0, there was an acquisition of a company.

And as we were trying to merge the company's assets into the wider code base, what we realized was that, you know, the, the company which was acquiring the, the, the, the acquisition had obviously had a very high bar for security and they expected the acquiring the acquisition to be at a similar high bar. So they had to make sure that they pause any development of any new features for one entire year in order to, to, to get the, the, the security story to

get right. And as we were implementing the, the, the features and functionalities to make sure the, the combined solution had a watertight security posture. By far the biggest challenge that we faced as an R&D team was answering the simple question, who has access to production? Or rather who or what has access to production, right? And, and how do we make sure that access is secure, that access is least privileged. It conforms to all the best

practices. No static credentials, no long standing keys, heavy roll is just the right sized. And it turned out to be a ginormous problem, right? Just operationally, how do you make sure that these best practices get implemented? And that was the motivation for, for calling the name of the company is P0AS. As as I'm sure you know and as as I'm sure many of your listeners are also aware, P0 is the highest level of severity of any incident. So our our tagline is access is

always AP0 problem. Yeah, that, you know, I, I wanted to go back because I think the explanation you gave on the history of privilege management, a lot, it made so much sense. I just never heard anybody put it in those different eras. And it kind of leads me to the question that I wanted to ask, which was, you know, when I talked to practitioners about how they're solving the very problem of, OK, now your company's moving more and more of its IT operations out to the cloud.

How are you managing privilege? How are you managing all these new accounts? And I know that kind of the starting point of the preference is, well, I've got IGA, I've got privileged access management, maybe I've Kim, can I just use these tools? I, I get the sense that obviously that falls short, right? You started this company, P0 dot dev, and by the way, that's P with the #0 dot dev and P0 dot dev slash idac if you want to

learn more. But you started this company, you had a vision that if you're just to take kind of the existing tools and try to approach this problem, it falls short. My question to you is, what is

that shortcoming? The solutions that you mentioned in particular like things like IGA, things like Kim, right? They, they talk it at least as far as Kim and related spaces like CSPM and CNAP etcetera are concerned, they are concerned primarily with offering visibility to an environment, right. In other words, it's an after the fact at a station of sorts. Hey, these are all the things that exist in your environment. Let us just make sure somebody's

reviewing that. And most often than more often than not, it's, it's either the SoC team or the cloud security team. They, they'll do a, a, a review based on the limited context they have and they'll say, OK, it passes all the checks or hey, it does not pass the checks, right? This is very much a compliance driven problem or a compliance driven use case, right?

When it comes to actually managing the privileged access, who are the people who are using access, creating access, destroying access on a day in, day out basis? It's not the people who are reviewing access after the fact, three months later, six months later, on a quarterly schedule or, or what have you, right? The people who are using access tend to be the developers, the dev OPS teams, the platform

engineering teams. These are people who need to maintain production, need to make sure access to production is secure. Then they are the ones who need to go and make sure databases are being spun up, data data jobs are being executed. You know, clusters are healthy, cluster health has healthy, etcetera, etcetera, right? They and and and and and what we, because there's a distinction in the persona. It's not a SoC use case. It's more of a practitioner driven use case.

The the use case becomes, hey, I don't want to merely review who has access. I want to give people access safely. I want to make sure that whatever they do behind the scenes is audited. And once their work is done, I want to destroy that access, right. In other words, the goal of Pam is not to ensure after the fact that, hey, somebody's reviewing access. That's the goal.

That's a compliancy compliance related use case relevant for IGA and Kim. But for Pam the use case is every access to any privileged system should be a short lived B it should not be it should be least privileged and C it should use. It should not use static credentials or or long lived keys or long lived tokens. It should as much as possible be based on, on short lived credentials and add a fourth one in there.

Any activity that is going on under the hood should be auditable logged for any kind of compliance related audit requirements, right? So I'd say that that is really the job of a Pam solution to make sure I reiterate any access

to short lived least privileged does not use static credentials and is, you know, auditable by design. And that's that's that's how we differ from an IGA solution or a

chem solution. Yeah, I was kind of so you jump me to mode one of the other questions that I wanted to to ask or maybe a topic that I wanted to pose because I think there's at least this is the the goal state that I've come down to where you you want your privilege access management program to be. Is that at least your privilege access? Maybe it's not the credentials, maybe it's more the entitlements that it's where the rubber hits

the road. You want that to be just in time 0 standing privileges because if some account gets compromised, it won't just lead to inappropriate access or downright dangerous access. Is that kind of where you're going with what you're talking about earlier? And then I mean, the reason that organizations aren't doing that I, I don't think it's because they don't agree with that or that they're lazy. It's just, it's hard to do.

Maybe it's hard to do because the tools that existed up until today don't really make it easy to do. I don't know. Absolutely. Absolutely. So you hit the name on the head, right? Entitlements are something you worry about when a system is very complex, like the cloud, right? During the vault LED pan era, there's no such thing as entitlements, right? Once you had root privileges to to a box, you could go in there and do whatever it is that you wanted to right?

The entitlements were fairly easy to to control because you they were only a handful of systems. This started breaking down completely in the cloud native era, especially as IMABI has became more sophisticated because instead of the front door access via username password, the the attack surface became entitlements.

Right? So a big portion of what we call as the API LED Pam is as I said, the problems it looks to solve are how do you make every every access short lived and least privileged and auditable by design. You know what that means? Just in time access for users. That means 0 standing access for users as well as non human identities, right? It's how do you implement and operationalize these concepts that is really the heart of what this next Gen. pad panel is all about.

So I'm wondering when you get called into, OK, let's see demo P0, is that usually when an organization saying that we kind of hit our limits with privileged access management or

we don't have privileged access management, or, you know, I've seen a lot of privileged access management organizations buying to privileged access management and it flops, right? Or maybe they own a whole lot of licenses and are just doing vaulting and things like that. It's because there's so much resistance from the developer. And one thing I'm getting the sense of is that the developers want to use this product. It makes their job easier. So, you know, one, I wanted to

to validate that. But two, I'm more interested to know when is it that practitioners are calling you in? Is it because their wholesale need to, you know, they've, they've recognized that they need a new platform or is it that there's certain use cases that are coming up and they're looking to, you know, add on to what they have to kind of just address those use cases?

Yeah, no, great question. So I'd say people fall along the spectrum of of of their of how much bought into the concept of pan. They are right on one extreme of the spectrum are people who are already bought in, they know they need pan and most likely they're already using some version or older version of a Pam product. Let's call let's say that they are using the bastion LED Pam, right They'll security team, in fact one of our largest customers falls in this category.

They were using a, a, you know, a bastion LED Pam with, let's go, let's say a 15 year old technology, right? And, and they realized that A, the user experience of maintaining infrastructure and deploying infrastructure is not the best in the world. And, and B, this, this product gives developers standing access to critical infrastructure, which does not fly with most sophisticated customers anymore,

right? Every, every customer wants their data sensitive data in the hands of their vendors to be secure, right. So this this company was a vendor to their own customers. They want to make sure that their developers do not have standing access or standing privileges to do to any of their customer data. So they came in and they decided, hey, yes, we would like a solution in which our, our developers are, their experience is, is, is not affected. If anything, it's enhanced.

And yet they do not have standing access to, to, to any infrastructure anymore. They can elevate their privileges on demand in a just in time fashion. And when their work is done, they can revoke those. You can revoke that access, right. So that is 1 extreme of customers who are completely bought into the idea. They need Pam and if anything, they might need a refresh of the, the, the, the Lexi Pam

vendors that they already have. On the other extreme, they might be customers as you, as you, as you said, right, who where the security team knows that they need Pam, right, But they may not have the buy in from the developer teams just yet. Developers are a little hesitant to give up their standing access. They are a little hesitant to, to make sure that these service accounts, IM roles, etcetera, they, they conform to the best practices, right?

And for, for such customers, the idea of Pam is more of a journey, right, which starts by giving them visibility into every access path to their production stack, right? So that's the step one. Step 2 is identifying which of those access paths or access patterns are potentially risky and, and giving them workflows to, to implement some governance or remove those, those standing privileges.

And step three, once that is done, how do you transition them over to a just in time access model, right. So these three steps don't happen overnight. It becomes more of a journey to, to educate the, the, the broader

teams that, hey, this is, there's a better way to do this. And, and, and, and, and that's how those, those conversations go. And, and, and most customers are not, are somewhere on the spectrum between these two extremes, as you can imagine, right? And, and, and, and that's it. It. It really comes down to understanding what specific problem they're looking to solve and working with them to make sure we operationalize that. Yeah, great answer.

You know, I'm kind of sitting here thinking like the identity industry follows what's happening in IT, the tools and identity need to solve the problems that or challenges that the IT infrastructure applications, etcetera throw at it. I'm also kind of thinking with that question that it does seem to me, you know, it goes all the way back to that timeline that you payment, you know, going from 20 year old where it was the vault, then it was Bastion

or Jump Box, now it's API driven that really there is legacy Pam and modern Pam. I feel like when I talk to organizations and this has always been true, OK, so this has been true since my very first days in IT is that organizations have one foot in the past and 1 foot in the future, right? One foot in the past is always going to be there. But if you look five years down the road, more is going to be what you call the future today,

right? And so if you're starting out today and you say we got 1 foot in the future, if you say we need to solve for both, bottom line is we need to follow solve for both. That you're going to probably need legacy Pam and modern Pam at the same time. But if you start, if you're at the point where you have nothing and you have to pick between the two, I'd say where are you going to 1st off, you're not just going to snap your fingers. Then a Pam's going to be rolled out.

So you're looking at a couple years and you have to look at like, where are you going to be in the future? You're going to be mostly in the future or mostly in the past. You're going to be mostly in the past. Maybe you do need legacy Pam as your answer. But if where you're going is going to be in the cloud, it's going to be using much more automation, maybe AI agents in the future, like that's where you put your investment. Thoughts. Yeah, no, absolutely.

So you you hit the name on the head right, given the implementation times involved with with with with digital

transformations of most of the size that most respectable organizations undertake right. It's the, the, the calculus in front of most security leaders is not just what they need now. But hey, given our organizations current investments, given our organizations planned investments, where are we likely to be in the next 5 years, right? What is my stack on a look like? Is it going to be more cloud native? Is it going to be less cloud

native? Is it completely irrelevant based on some of the AI investments we are making? And given that reality or given that projection five years out, what is the best solution that fits the needs and will future proof us so that we don't have to worry about this damn problem for the next 10 years, right? That's, that's the, that's the, the calculus in front of, of, of most security leaders out there.

What is the the maximum we can solve that would make this this investment moot for the next 10 years? Yeah, absolutely. So I wanted to ask you another question based on something you said earlier. We were talking about we need to, I think you're taking a story from your past. You're talking about protecting people, but also the non people, right? So you're getting into this whole non human identity

question. And I guess in my mind they're different, but I'm not, you know, and having talked to you in the past, I kind of get the sense you don't treat them differently or you don't think about them differently when it comes to management of the access that they have. And I'm wondering if you can explain that a little bit. Great question. So I think I want to distinguish between what's a use case and what's a company, right or or rather what's a use case and what's a platform.

Absolutely securing service accounts, non human identities etcetera is a very legitimate use case, right. Absolutely. This thing is becoming more relevant now that we are in a in a cloud native error, we are in moving towards an agentic error. There the number of entities that can access your sensitive infrastructure and data is is increasing and only going to explode even more rapidly from

here on, right. But I would argue that is a use case and not a company defining feature in and of itself because I define the space privileged access management as hey, I need a platform that helps secure privileged access to my sensitive infrastructure. Period. No way do I say that it has to only come from users, or it has to come from machines or it has to come from agents, right?

I mean, at the end of the day, if I'm a security leader, I care about securing access because that is my most important perimeter, for the lack of a better word. I hate the word perimeter. It gets used and abused so much. But but it's true, right? It's identity and access is is the foot is the most important line of defence, right? But it almost sounds a little too narrow to think about access for only certain categories of identities, right?

Particularly when it's the same product or the same framework of thinking can solve both those problems, right? At the end of the day, our belief is that any kind of access, whether it's from users or from non human identities, any kind of access should be least privileged.

It should be short lived and it should conform to the best practices of of not using static credentials, no matter whether it's for users, EI agents or non human identities, right? So. Yeah, Yeah, it's absolutely. So the business drivers that you just mentioned I'm 100% on board with. I mean you are spot on. My question, I guess my follow up question to that is talked about the word in this API era. I think I know what that means.

Is that what enables you to more or less treat them the same? Or is it just the the business philosophy? Is the technology in the background, this API era that you know, if you can script it to go out to an API, then you can you can make it work? Absolutely, Absolutely. I mean, you, you hit the, you hit the name on the head, right? So it's not just the business drivers that I was talking about, it's also the technical drivers.

In a nutshell, the way our product works is that we create a graph of of every identity in the system, who's the consumer of that identity, what credentials they're using, what roles, permissions they have and what insensitive resources they have access to, right. So think of it as a graph and it does not make a huge amount of sense, in my opinion, to treat this graph differently for users versus non human identities versus versus agents. What not right?

So technically we have under the hood, a common engine that treats all of these different kinds of identities as one, right? And all of this graph is just built by hooking together the the APIs of different systems, such as your cloud providers, your identity providers, your

HRMS systems, right? And and and we don't really need to to to slice and dice it further based on the the the kind of identity when when when one common framework can is good enough for treating both of them as first class citizens. And so I think that's going to be a lead into my, the, the, my next question or my last question, which was really I'm, I'm thinking from the practitioner perspective.

So some tools you buy them because they've got great features and functionality other tools bring to the table, like wide visibility, like you can connect to a lot of things and get the visibility. And I'm wondering from the P0 perspective, which of those two camps do you fall into? So ultimately we want to be the, the tool that helps in the operationalization of, of police privilege, right?

And visibility is a necessary first step on that journey. So again, it goes back to what I was saying, customers fall on a spectrum. They'll be the ones that they'll be ones that are more advanced who will come in and say, you know what, we don't need visibility. Just help me implement least privilege because I already have the basic building blocks in place, right? For them. We are first and foremost an operationalization of least privilege company, right?

Then there'll be others who are bought into the idea, but they may face developer resistance to begin with. For them, in the beginning, we'll land by providing them visibility. But ultimately, even for them, if we are so successful, we want to move them towards a model of operationalizing lease privilege, right? So to answer your question, Jim, for all customers, we are ultimately a company that wants to operationalize lease privilege. For some of those.

The way to do so is by giving them visibility and hand holding them. On the journey so all this talk of identity and you're you're preaching to the choir here, right you're on the identity at the center podcast, right so we kind of get it but there's a lot of people who listen to this who maybe don't consider themselves an identity they might be an engineering or insecurity or, you know somewhere around there.

What's something that you wish, like engineering, people would understand about access and, and identities and, and how to manage it? Because I hate to say it, but people keep saying identity is the new perimeter. It's been around forever. It's not a new perimeter. So I feel like this is an area where we could probably do some education for for people who maybe aren't as familiar with it or haven't traditionally looked at identity as as part of their their role. Yeah, no, absolutely.

I think the biggest learning for anyone who's not in a core security function, who's not thinking about identity on a day in, day out basis, is that expediency in technical decisions ultimately always creates headaches further down the line. And in many areas, this is truer than others. And identity happens to be 1. And what I mean by that is if you're an engineer, it's very easy to be expedient and say that, hey, no, I need standing access all the time because I need it for my work.

Or hey, I, I need to hard code this credential into my, into the service that I'm building because you know what? Yellow right? But, but, but, but those things are never the security best practice. They always snowball over time. They almost always compound and and in time become a much bigger problem than if they're addressed directly at the source. And if you have the right tools that addressing those at the source is actually much easier than it than it sounds right.

So, so that is that is something that I wish you know the the the people who are in touch with identity, but from a user perspective, but not thinking about it day in, day out. That is something that I would wish that they would stand, stop for a minute and appreciate. So let me challenge a little bit because what happens if you've inherited a mess, right?

This happens a lot, right? As you know, someone comes into a new role or you know, decisions that were made in the past maybe aren't the best decisions, and we have to pick up the pieces of whatever that looks like. What's some advice if you're in that scenario where you know what you should do, but it might be difficult either financially or politically? Absolutely, absolutely. Look, some amount of technical debt is is.

Is to be expected, right? People go to do things which they have to do. Everyone is making trade-offs based on the time, the budget they have, the resources they have, the OK Rs they need to hit. That's, that's that's just the world we live in, right? But at the same time, many of these decisions need not be made the way they are, especially for Greenfield projects or even if

for brownfield projects, right? If you have to fix something right, just make sure you are tackling the most important big rocks in your in the mess that you inherit, right? And it just so happens identity is usually one of the biggest rock, if not the biggest rock. Here, here you're, you're, like I said, you're, you're, you're talking to the right people about this. I guess I kind of want to wrap up the conversation with where do you see this going?

Because you've talked about the different eras and being in the API era. What do you see as like the next era and like the next challenges that we need to be thinking about? And how do you see P0 kind of staying with it, right? Because you don't want to get left behind, as we've seen with some of the other eras. Yeah, look, we're, it's, this is an easy one, right? We are in the age of AI agents, right? Or we are very soon, depending on who you ask.

We are at the doorstep of the the age of AI agents. And, and what this means is that very soon, once a lot of these agents are in production, you know, 9099% of the organizations that I've spoken to, they're still playing around with agents. They haven't been productionized just yet, but it's only a matter of time, right? So I think the next evolution of Pam would be the agent LED Pam for the lack of a better word, where the same problems.

By the way. Again, the core focus of Pam hasn't really changed for the last 30 years. It's still make sure every acts, I, I. I hate to sound like a broken record but that is what it is. Every access needs to be least privileged, every access needs to be short lived, every access needs to be auditable and every access needs to be not using static keys and credentials. Right. The same 4 problems need to be

solved for agents, right? And and it will just make for a product with slightly different form factor, slightly different assumptions based on how agents get operationalized in practice. But again, the Gen. 4 I'm pretty sure would be the agent LED Pam

solving. The same for, you know, 3 or 4 problems for an entirely new class of of of identities. It sounds a little bit kind of like The Matrix where we've got a bunch of agents talking to each other and figuring out what they should and shouldn't be doing. And, you know, I've kind of sent us a four in previous episodes. It's like, all right, you agents, you figure it out and let me know what you decide. Just kind of take care of for me. Yeah, absolutely.

I mean, that's, that's, that's a, that's a good way of putting it, right? I mean, it's and, and, and the use cases, the tangible use cases are actually very easy to think about. So like for example, right, if you, if you're using a coding agent, you, you want to make sure that whatever agent you're using cursor or or or broad or, or something else, you want to make sure that a they have access. If they're talking to GitHub,

for example, right? You want to make sure that these agentic identities are not using personal access tokens or they're using some, if they are authenticated via Oauth using an MCP in the middle, you want to make sure that you know the, the, the, the tokens that they're using are, are going they are, they are not static. They are not long lived. They are not hard coded into the MCP, right.

You want to make sure that their scopes to the repos that they are are, are accessing our least privilege. Nobody, no agent has, you know, write or delete access to just about every repo in your in your code base, right? So again, the the the the precise problems might sound different, but it's all it it all. Rhymes with what has happened in the best. I feel like it's a speed problem more than anything in an automation thing because the use cases are the same.

It's still even if it's not a human versus a human, it's still onboarding, offboarding, you know, join your mover reliever. It just so happens that they're not humans, but the speed with which it has to take place with and the ephemeral nature of some of these, you know, micro services or API calls or agents that might only live for milliseconds. You still need the traceability and the audit logs to show that,

Oh yeah, this agent did exist. It did these things and these three milliseconds, and then it went away. Right? All that kind of stuff. Yeah. So this has been a really fun conversation. I'm glad you were able to join us. I have to say, I'm going to assume you do more than just, you know, solving identity challenges. What do you do like outside of, you know, being in the nerdery, you know, with us talking MCP and Pam and agents and all that other stuff, like what do you do

for fun to unwind? I spent time with the family first and foremost. I have an 8 year old. I played tennis with him. Earlier, I used to play tennis by myself. These days, increasingly I played tennis with him. I like to stay fit as much as I can, by going to the gym, by swimming, by playing tennis, whenever, whenever time allows. And I'm trying to get back into a reading habit which I've not been so good at, especially

since I started a company. Is there a specific genre of of reading that you like to do as a fiction? Non fiction? Like what are you into? Increasingly it's history, historical narratives. OK, so now you're starting to talk about Jim's language because he's always interested in like documentaries about history, working out, stuff like that. I I guess I'll let you 2 talk right recommendations for each

other. Maybe, maybe, maybe the next time we talk, I'm I'm on the road to, to South Dakota for all you know. I would love it. You'd be welcome here. Well, that's been a lot of fun, Jim. Like what would you give like some suggestion for Shashwat to read? I know you're big into like documentaries and stuff like that. I don't read, so I, you know, I have YouTube Premium because they can't stand the commercials and it's just unbelievable with the amount of historical

documentaries. And now what I'm seeing is a new genre is that there are content creators who take a period in time and build a day in the life of story and they'll pick a a

fictitious figure who lived in that place at that time, like New York City in 1882. And you just watch like, and I'm talking like an hour long documentary. I watch. I love those, I love those. I can't believe like there are people out there and I know it's when I say it's like an independent creator. I don't know what his whole corporate structure is, but there's one guy, because I saw several videos where he's the fictitious character, he's the actor in all these different

videos. And I'm like, this is the future. It's people kind of saying, hey, this is what I want to create. I can be an artist now and put together something because all of the materials that are neither commercially available, there's AI to help me create backgrounds and create videos, etcetera, etcetera, and put that up and then other people can enjoy it. That's what I love about technology. We talk about like the bad parts of technology.

Yeah, they're there, but there's so much good that can come from it. Just what do you know what Jim's talking about with this day? And I think because I've never heard of this, it sounds, it sounds kind of interesting, but I'm, I don't know what to think about it. No, it sounds, it sounds interesting. I'm not too big into into YouTube videos. I do not have YouTube Premium, just for the record, but it's it's, it definitely sounds very interesting.

Well, you're, you're in the minority here. I think Jim and I are both YouTube Premium. I, it's on quite a bit for me and I think it's such an interesting thing. I think, you know, if I'm going to lay a, a, a day in the life gym, I want to like, have some fantasy around it, like Game of Thrones, right? Or I don't know, the Matrix, right?

Things like that. I want to like have a good story, you know, and, and 'cause I, I mean, you're going to have to fill me in on this at some point because I can't imagine that there are that many interesting lives of like normal, like people. If that makes. Sense these are fictitious lives, the person's making them up and then they make a video, right? I'll, I'll send you a few of them, OK?

I mean, 'cause I'm, I'm thinking of like the most dry video ever where it's like, oh, I woke up today and then I went and did laundry. Then I, you know, sat at my computer all day and did nothing. Or, you know, I went and farmed or something like that. I'm like, I'm sure there's a market for it, but I I'm. Just so there's a day in the life of this guy in 1882. He was in New York City. He was a German immigrant, and his girlfriend came over and some pickpocket, like, dropped

something in her bag. And then she pulls it out of the bag. The police see her, they arrest her. Now he's like, trying to figure out how to get her out of jail. Like, there's a whole little drama behind it. So it's kind of a good story. Will acted and I mean, it seems like there's a little more to it than a one person, you know thing, but it's pretty incredible that it's out there. It's just free content.

I'll have to check it out. I think you know every, my position is everybody at this point is a content creator. It's just do people want to consume that content? That's right. We're on camera somewhere. So all right. Well, this has been a just a really fun conversation. Joshua, thank you so much for being with us. Any final thoughts that you want to get out there for the the folks who are listening and or

watching? Access is our probably 0, so if you have any any challenges managing privileged access to cloud, native or hybrid environments, please come talk to us. We'll be happy to help.

I love that tackling access is our priority Zero that that's something that resonates with a lot of IT people around the world. So good one there. So be sure to visit the website P0 dot dev slash IDAC. There'll be a bunch of information that you can kind of check out and learn more about what you guys are doing. So thank you again for being with us. For those listening, keep on a liking, subscribing, sharing with friends, enemies doesn't matter.

As long as they're listening, that's all that matters. So check us out on the web idacpodcast.com. And with that, we'll leave it for this week. Thanks everybody for watching and or listening and we'll talk with you all in the next one. You've been listening to Identity at the Center. We hope you've enjoyed the show. Make sure to like, rate and review, and we'll be back soon. But in the meantime, hit the website at identity@thecenter.com. See you next time on Identity at the Center.