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.
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.