#401 - Sponsor Spotlight - PlainID

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? I'm pretty good yourself. Good. So many ways I thought that we could start this Episode 1 was Happy New Year, but I think I'd be far in violation of saying Happy New Year since this episode goes live in February. But I thought I'd start with a pun because it's been so cold on the East Coast of the US. But you know what?

It's hot right now. Authorization. So hot right now. I think we need like the was it the oh, what's the movie? It's I'm blanking on it now. Zoolander, right? It's so hot right now. Author is authorization. Well, I think we should dive right into it because we've got a fantastic guest today. Yeah, we've got a sponsor spotlight today. So these are the folks that helped make this podcast available for so many people around the world and definitely

appreciate that. So it's a fully sponsored episode. We're going to get into it today with Plain ID and really learn more about their solution. I've known Gal, our guests here for at least a couple years now, kind of way back 20/15/2016. I feel like maybe it was somewhere around that time frame, but a kind of a routine mainstay on the identity circuit. So if people want to learn more about Plane ID, you can go to the website planeid.com/I DAC. That's PLAIN id.com/I DAC.

So welcome to the show Gal Holimsky, the Co founder and CTO of Plane ID. Thank you and it's very nice to be here again. Yeah, the last time you're with us was way back in episode 218. I thought it was last year, but you corrected me in your toy, right? It was a couple years ago. We recorded live from Ideniverse in one of the many conference rooms. And I think I don't know if that was like Mandalay or if it was one of the other, you know, one of the hotels that we were kind

of out there. But we had a great conversation around back BAC something based access control, I think I called it like star back. So thank you for being part of this as well and coming back. So I got to ask your first questions like, all right, so why are you back? Why are we doing this episode? OK, excellent question to start with. So first of all, because I want

to say that today authorization is a security decision. If in the past we struggled with which method to implement and even to even if to implement at all, that's no longer the case. Today, authorization is a security decision. Either you're secured or not and we'll see why is that. I mean, that's a pretty simple, simple statement, but it carries so many repercussions, right? It's like, OK, authorization is really the crux of what identity and access management is built

around. You got to get it right. So tell me a little more about plane ID. For people who aren't familiar out there and the, you know, billions of listeners and watchers that we have, what is plane ID? OK, sure. So Plain ID is the authorization company. We are focused primarily on authorization, controlling authorization, managing authorization, providing

authorizations. We have been focused in the space for quite some time and we work with large enterprises that trust our technology to manage and control their authorization solution. That is, that's Plain ID. And yeah, we'll learn more as we speak. We're definitely going to learn more about it, especially sort of like how does look in in sort of the real world and how it works like architecturally right within an environment. I got to ask though, how'd you come up with the name Plane ID?

OK, so you know how in identity and access management there are so many aspects and it starts with maybe something simpler and get so complicated. Authorization traditionally is considered the most complicated area. We wanted to simplify that and therefore plain IDAYID. That's a different question, but still we wanted to resonate something which is simpler, solving a complex problem in a

simpler way. Hello, it's a noble 'cause it's a hard one to address because I think authorizations get super complex sometimes, especially some applications. What is it that you think makes plain ID separate itself from others that are in the market? Because I know there's a lot of different kind of vendors right in the authorization space. You guys have been around for a long time at this point. What is it that makes your solution unique?

As I put my jaded see so hat on like all right, create another tool in the stack that I have to think about. Yeah. So I believe it's the completeness of the solution and I'll explain again. Authorization, like I said, is the security decision, which means it's not a developer's decision, it's eventually a CSO

decision. The authorization is meant to represent what can be done within our technology space, which basically translate into what data can be accessed, what tools, what APIs, what services can be used, who's making those decisions. Someone needs to make them, someone needs to govern them, and that's typically

responsibility of the security. Plain ID places a lot of focus on managing and providing visibility into those authorization policies as well as enforcing them, providing the tools, the means to enforce them across the technology. I would say this is one of our major differentiators, our ability to see, to capture that whole scope of authorizations,

not just one side of that challenge space. So authorization stretches beyond just people, all right? It gets into other things. So I'm curious, this is plain ID addressing both, like customer identity, access management, use cases, is it workforce? Is it both? And then how does it get into non humans or maybe agentic and things like that? Yeah, absolutely. So first of all, the answer is all of them. Why? Because they're all identities that need access. That's the bottom line.

And eventually when you want to walk within your application space, data APIs, it doesn't really matter to the data if it's an end user, a human who's trying to access, or an application user or even an agent user. It's a user, an identity that tries to access the data or tries to consume the API or whatever. So an identity is an identity, by the way. It's the responsibility of, you know, all those Ibps to make sure the identity is there and it's authenticated and all of

that. But then what happens afterwards? Afterwards those identities need the right access for whatever they're doing. And in some cases, maybe the combination of identities like in the identity earlier there's the agent identity and the end user identity. So you know very shortly all identities count, all identities need to be authorized. Hey, gal. I was so intrigued by what you said about authorization having an important role in the

security stack. I was wondering if maybe you could talk a bit little bit more about that and what what it is that you're talking about? Yes, absolutely and thank you for that question. So you know the market has been investing a lot around managing identities whether human, non human authenticating identities. So we have all those controls in

place. So our users are accessing the applications or you know all of our technology stack after they have gone through multiple multi factor authentications. But then what? What? How can we control what they can do, what they can see? That's where authorization comes in. It's like the last line of defence before accessing data and accessing all those tools and services. And why is it such an important topic now? Because the change in the market towards identic flows.

That's when explosion of explosion of data usage, tool usage, API usage happens and no longer traditional controls are sufficient. We cannot rely just on having an identity or having the identity authenticated. Controls must be implemented in the right way. So the need for those controls are tripled even then they were before. That's why I'm saying it's a

security decision. Every organization is evolving, evolving towards newer technologies, more specifically the identic space and authorization is a crucial component to secure that. So, Gal, you brought up an interesting topic there, Just authentication, right? And I realized that maybe we jumped right in because I think this is a topic that, you know, authentication, authorization, people get confounded sometimes or lump them together.

And I think you see it even with some of the protocols where like the authorization data will get lumped in with the passing of the token. You got open ID, you've got Oauth. They're different, but unless you kind of are an expert in those areas, you might get them lumped together. Why is it that you think people are? Maybe you could just kind of start with the separation of the two, and then why do people get them lumped together? Yes, absolutely.

So first of all, they should be lumped together because it's a continuous process, basically authentication, right, Defines who you are. But then authorization comes and says what can you do? Now if we rely just on authentication, it means who I am also carries what I do. So I'm walking around with a bag of privileges, which basically beats the purpose, right? We are now talking about 0 standing privileges, which means who I am is just who I am.

It doesn't mean what I can do. As I walk through in the application, as I try to access data, as I try to consume services, that's when I need to determine if that is is approved for me in the context which I'm working in, right? So there must be a very distinct separation between authentication, who you are, and then the continuous process of authorization. What can you do? But what can you do in a specific context which you're currently operating? It cannot be predefined, cannot

be predetermined. How, if it makes sense? Yeah, perfect, perfect. Thank you. And you know, Jeff and I often say, and not just because you're here, right, is that authorization is having a stay in the sun. You know, you see the Austin Working Group, part of the Open ID Foundation, You see just so many more authorization vendors and focus at the identity conferences. I see you guys are still the lead in terms of kind of like pushing this boundary.

But I guess my question is, why is it that it's so hot right now? And I say that because you guys have been around for decades, right? I mean, we didn't really get into what year you founded the company, but I feel like you guys have been around for most of my 20 years in the space. And why is it that right now it's getting this special attention? Yeah. Well, first of all, maybe not decades, but we do like to speak a lot, so we make a lot of noise. But thank you.

I think the reason for the importance of now, why now is the moment. It's because the shift in technology authorization has always been the challenging part of identity and access management. And when it comes to traditional technology, it's complex, but when we are starting to look at a newer technology, APIs, micro services and now the identic space that when it becomes easier to implement more advanced controls. So that's the reason it's a hot topic now.

Additionally, has the technology progress as we see again, I'm back to AI agents all the time because that's the hot topic now, yes. So as we see AI agent operates, what does it mean from technology perspective? It means a whole lot of little steps that are combined together to make something happen. And that means each and every one of those small steps in the process need to be authorized, not just authenticated, but needs to be authorized.

And static standing permissions cannot address that. That's why the need for a true authorization system dynamic context aware is is very very much relevant for this time, which we are. So I think people are probably pretty familiar with authorization, at least the concept, especially when you start talking about humans. I want to get specifically into like agentic AI because that is the other thing that's so hot right now, right?

It's is there are this explosion of agents that are running around sometimes amok inside of an organization with poorly scoped permissions or whatever it may be. Can you talk about authorization specifically in the context of a Gentek AI and sort of how does plane ID help me address that government, solve for it, things like that? Yes, absolutely. So there are several aspects to consider. First of all, who are we authorizing when it comes to the agentic process?

We need to remember there are several identity types. I would say first of all, there is the agent, of course the agent, the agent identity, but there was also the end user identity always at least, well sometimes just one, but there can be two identities to consider. So when we are authorizing an action or access to something, we need to be able to evaluate both identities. Plain idea of course can do that. Second, when do we need to apply controls?

Looking at the full identic flow, we have multiple control points to consider. It starts with a prompt. So every process starts with a prompt. The first control point is at that point. Exactly. Can whoever is asking the question or whoever is initiating the prompt actually do that? According to the security controls, in many cases people are talking about guardless. Guardless tend to be very operational in nature, but think about security guard. Those would be your

authorization decisions. So again, one the prompt second data, an identic flow retrieves data whether it's via RAG or whatever other means, right data feeds into that flow.

What data can be fed in the context of the end user identity and the agent identity? Then based on the question, the prompt, and the data, at least a process is generated. The LLM is suggesting all of that, and then the LLM might reach out to tools. You've probably heard of MCP, the standard for utilizing tools in the identic space. So again, the question is, can the agent at this point of time use those set of tools or which tools they can use?

So we want to put some controls on tools as well. And the last part of that is the response and response is being generated. Maybe some of that response can expose data it shouldn't. So we want to consider masking the response plane ID today has the capability to control what questions can be asked, filter out the data which is fed into the process, control the usage of MCP tools and mask the response that is sent back to the user.

So end to end control throughout the identic flow, and that's part of what an advanced authorization solution needs to do, cannot be done by just static permissions, needs to be governed by policies. So you mentioned the, the, the word guardrails and I've heard this a lot. And I wonder because is it guardrails or is it more of a

railroad track? Because guardrails is kind of like, all right, it could be a 2 lane highway, it could be a one lane highway, it could be A8 lane highway with a lot of, you know, swerve in between all that. And I wonder do you have, you know, a, a, a different definition or distinction between something maybe that is from an authorization standpoint is OK, Is it guardrails or is it like a railroad track or maybe a roller coaster track, depending on you want to perceive that? Yeah.

I think, I think it's a term is that the market has started using it's, it tends to be a more of a technical thing. It is very common to implement guardrails for prompt control, for output control. So we are, you know, we are aligning ourselves with the way the market is currently speaking. Basically it's a way to place controls. So controls are placed in the form of guardrails and they can be placed on the process that throughout the process input output data and tools.

But I agree with the you know, the the the picture you draw absolutely. Well, I think, you know, when you have guardrails, especially when we're talking about agentic and generative AI, you, you almost need some leeway, right? Otherwise you kind of lose the benefits of having something

that's generating that. So I just kind of brought it up because I was like, OK, well, I can see some people think out there like, OK, well, shouldn't authorization be like a single track or you can only do this one thing? But I, I guess my, my next question is, is there a right way to provide agentic authorization? Because you talked about, you know, the question is, can the person who is invoking the agent do the thing that you're asking it to do? So if I write an agent, does the

agent mirror my permissions? Should it have its own set of permissions? What happens if the agent creates its own agent? And now you've got like this domino effect of agents creating agents, creating agents. How do you track permissions throughout that? And is there a right way in your mind of kind of how to control that? Yeah. So yeah, I think you asked me just, I don't know, four or five questions, but I'll try to answer. I'm great at that. Yeah, absolutely.

OK. So first of all, you need to consider all identities involved in the context of the operation. So if there is an end user identity and an agent identity that is currently doing whatever operation in the decisioning process, both should be considered. You can't consider just one of them. Yes, an agent identity has authorization tied to it.

Yes, an end user identity has different set of authorization tied to it. You need to consider that they both have more than just what is needed for that specific operation. And you know what that leads me to? What is the right method to control it all all and to manage it all? You know how the IEM market likes to create new acronyms every year, So we have a new one. It's called Intent Based access control.

No, truly, this is a good. This is an important one to remember eventually to do the right authorization in process. You need to understand intent, and that means there is a specific agent designed for a specific purpose. Now, there might be a human who's using that agent or another agent who's initiating that agent. That's part of the intent. The second part is what are they trying to do? And then the last part is why

are they doing that now? So in order to truly enforce is 0 standing privileges, truly enforce security controls in the identic flow, you need to consider all of those facts, the aspects you need and to understand the intent of the operation and enforce accordingly. So gal, you, I want to come back to intent based access control because I think it's a fascinating topic, but I want to key on something you said to, you know, to Jeff's question.

So first kind of the basis of my thought is a year ago we were talking about I am for AI and essentially what it boiled down to was like authentication to your AI. And I was like, that's not very exciting. But what you just said there was like, I was like, that's the hard part. I mean, that is the really hard part where you start talking about controlling what questions people can ask. And maybe this kind of blurs

into the intent. But I figured the way I'd ask the question is this is because you've talked about addressing it with policy. And I'm wondering, you know, as you talk about the solution with customers or potential customers, are they presenting the same use cases? Are you seeing the same use cases or are people each client giving you kind of a a different set of use cases that hey, they

need to solve and policy solves that? Yeah, So really excellent question. First of all, I want to say this is across the board, every customer I'm speaking with same challenges, they all want to adopt agents. They want to enable the organization to adopt agents. But then they need to do that in a secured way and they need a way to govern all those agents. I would even say many considered agent as a new type of

employees. Remember how I don't know how many years ago we had to take care of our human employees? And I am struggled around that and we build a lot of technologies to solve that. And the, the thing about human employees, they do follow some, you know, rebuild controls, right? If we see a locked room, we are part of an organization. We wouldn't just walk in there. That's not the case with agents. That's that's really important

to understand. Agents are your new type of employees, but they're very excited. They are like junior excited and employees that are meant to please. They are designed to provide you with a solution. They will do whatever they can, whatever is available to them, they would utilize in order to provide a solution. And that means if they have, they have more privileges they they should use, they can access more data than they should use. They will do that.

And that would lead to either misuse of capabilities or data explosion exposure. Eventually that's that would be the reality. So that's why you need to treat those AI agent as a new type of employees and apply controls on top of them. But also understand that your traditional solutions are not sufficient. You need to apply the right controls here.

And back to your question, yes, this is something I'm hearing across the board and speaking with a lot of organization, both from current customers and potential new customers. And they all have the same challenge. How do I control all those AI agents? How do I control what they do? How do I control what they expose? Because data exposure is certainly one of the biggest risk in this space.

Can you, I, I don't want to put you on the spot here, but could you give me kind of a, a real world use case where you know, people are finding like, oh, you know, applying these policies or something I can really do to enhance the security of my AI agents? Yeah, absolutely. So, you know, let's start with very simple policy. First of all, let's prevent exposure of PII data. Just start with that. Any, I don't know, Social Security number or numbers you don't want to be exposed or

whatever. Just start with applying that as a general rule, mask all PII data from your AI agents. Simple. OK, but other controls that I see I see being implemented controls such as cross-border controls. You want your AI agents to to serve your all of your employees in your companies or your partners or your customers, right? But you want to restrict access to data from different locations. Again, cross-border control. This is one of the top compliance requirements in many

organizations. There's so much relevant here as well because the same data exposure that you could have gotten with previous technologies without a gentic are still very much relevant to you. If you have like, I don't know, MNPI data, again, exposure of data. Don't expose data. Take your most critical compliance policies. Apply them at the beginning of your identic journey. So you mentioned the intent based access control.

I'm not. I mean it kind of sounded a little bit like it could be what you're talking about now or that it could be something different. Which is it? Yeah. So I think intent eventually is a way to achieve that that target. It's a way to achieve 0 standing privileges. So we I spoke before about 0 standing privileges. It basically means you enter the operation with nothing and then at each step it is determined what you can do right?

That's zero standing privileges. How do you apply to 0 standing privileges? With intent based access control? Which is basically a nice name of saying consider everything when you give an access permission or reject that access permission. Which means they consider the identity, both end user identity, agent identity, consider what? What they're trying to do, what they're trying to access. Why are they doing that Now in this context, that's intent

based access control. So achieving 0 standing privileges with intent based access control. Yeah, and it feels like everybody is trying to achieve 0 standing privileges, right? Because when you have standing privileges, if accounts get compromised, it could be very destructive in your environment. My concern was your standing privileges has always been how scalable is it?

Do you just kind of go after 0 standing privileges for your key applications, maybe for your most critical apps or your most critical accounts within those apps? What? What do you have to say about that? Yeah, I think that's a very true question as the, you know, every organization considers because I mean, you wouldn't want to change everything. So yes, prioritize what you want to start with and then implement a call, you know, implement accordingly.

That's why new technologies are a good place to start. I mean, if you, we know we have done in the past bad implementations, we didn't implement the sufficient controls well, they needed to be right.

But now we have a chance with new technologies to do that, right. So consider implementing as part of the development process, as part of the adoption of new technologies, meaning identity AI. Deploy that with the right controls in place. Don't do the mistakes, don't repeat the mistakes we have been doing over and over and over again, which means let's deploy our identic AI and then let's go back to security and figure out how to fix it. Now let's not do that.

We know what we need to do. We have the market has a lot of experience. We know we need authentication. We know we need authorization. Going back to it is a security decision. Let's make those decisions now and start from scratch the right way. Yeah, I think you made a great point there. So if I was to put it into my own words, it would essentially be you might the scalability part really or it's the effort to go and do it for everything you've done the wrong way.

And not because we're we're dumb or anything, but sometimes the technology wasn't there. Look, it's evolving quickly and we all are under. But if we get that infrastructure, if we get it right now and build it in bacon as part of the deployment process and our our standard security footprint, at least we'll get it right going

forward. So I think that's a great way to look at it. You know, the other conversation that often kind of accompanies 0 standing privileges was around continuous identity, continuous authentication. I wanted to get your thoughts on that. Yeah. So I think the way I see that and the way the market typically speaks about that continuous authentication, continuous identity represents the process,

the identity. Any identity goes through a in its digital journey, which means it always starts with a defined identity, authentication and then authorization, right? That's continuous because it doesn't end with authentication. It's not sufficient to know who you are. You also need to know what can you do? Can you see this piece of data? Can you access that tool of API right? Those are questions being asked throughout the process and that's what makes the process

continuous. It starts with authentication, it proceeds with authorization and and you know, that's eventually what makes the full process secured. I'd like to take this from theory to reality. What does it look like when I set up plane ID in my environment? Like what does this look like architecturally? Is this an app that I run? Is it SAS? Is it something on Prem? How does this connect to my other stuff? Like let's start with OK you've got me hooked gal, let's try

this out. Like what's next? Well, first of all, I'm happy to speak with you. Next step, we are a full SAS solution. We do have hybrid components. Many of our customers prefer the decisioning engine and you know access to data to be localized. So those would typically be implemented as hybrid component micro services, the design to scale design to for performance and security. So setting up the tenant, getting all those hybrid components in place and then you

go for a process of discovery. Once you have discovery done, you can see all your ready to use policy elements. What would those be? Well, maybe your database tables. If it's vector databases, then it's all the categories that define the documents. If it's MCP or the MCP tools already categorized by the way, so it would be easy to authorize them all your identities, of course. And then it's just a matter of connecting between the two, which are the policies.

Eventually policies connection between identities to what identities can access and adding some conditions on top. So you talked about this being a hybrid approach. The let's start with the on Prem stuff. You mentioned some things that that I have to install in my environment to connect. Pretty common, I think for most identity tools to have like some sort of proxy tool or connectivity sort of server that they can use. How does that work? Is it a virtual appliance?

I set it up and then it's scanning my internal environment or permissions. Do I connect it to things like SAP? Like how does that work? Can't even learn more behind the scenes. Yeah. So it's a containerized by the way, it's an optional component, right? You can do full sauce and it works perfectly, but you can also choose that localized component. It's a container basically micro service deployed however you want, wherever you want, how many you want, by the way.

And it has the function of a discovery. So it kind of scans whatever you want it to scan to fetch the elements. We call them assets. So those would be all protected assets, feeds them into the policy platform and then it supports enforcement and enforces data that would typically, and again, this is a bit of a technical jargon, so excuse me, but it includes APDP policy decision point, VIP policy information point that that's the component that connects to the data sources.

And in the enforcement components, we call them again in the regular jargon, PEP policy enforcement point, but we like to call them authorizers. And those are components per technology. So for API gateways, the cycle for your service mesh, whatever library for your development platform and so on, we have many of those available. So how does this work from like a real time scanning or you know, set up right permissions change all the time.

Are you detecting changes at the of permissions within applications and then pulling those into plane ID and then the PDP or PEP? And now you're speaking language, right? Policy based access controls, right? Those different terms. We've got a technical audience, right? They're probably flying along, but how do you stay on top of things that might be changing an environment?

Is this scanning at real time or is it like once a day, once a week? Or is it like on demand? It's, it's on request actually. So we have the PIP component I mentioned before. It has the ability to connect to data sources. So let's say it connects to your IGA platform or maybe to your HR repository or maybe to certification system or to all, all of the above, right. It pulls data in the real time at the time of access. So let's say you're trying to access an application or

database or whatever, right? So we can see that now you are defined as an employee in this department and you know in this region and make the decision accordingly. So it's true real time decisioning process according to a set of attributes which are out there. We are not replicating any data, not only for caching purposes, but that's on the technical discussion. So we are just pulling data when the data is needed to make the

decision. So if I think about this from like a, a UML diagram, right, with things bouncing back and forth, I'm doing the authentication against my IDP and then I pull it back and it's like, OK, now where does the policy based authorization component come in? Is it as soon as I try to authenticate or is it when I try to reach reach a specific application? How does that chain of events occur? OK, so there are multiple patterns to to follow the first

pattern. I'll try to quickly review some of them. So the first pattern is yes during authentication process. So when the IDP creates the authentication token, it is possible to reach out to the policy decision point to get a list of authorization values like claim keys, claim values and so on. This would be enriching the token. That is typically called a token enrichment pattern and it is part of login time authorization.

So one pattern. Second pattern would be at your let's say API Gateway. So whenever there is a transaction through the API Gateway, the transaction is been is been evaluated against the policy with the addition of attributes as much as needed and then the transaction is either allowed to proceed or blocked. Another pattern would be an application trying to access a database. So the application sends a query, let's say it sends select all form table, no boundaries at all, no controls.

We capture that and we add those controls according to the policy. So select all from table, but where location equals user location or whatever you see that's an example. Dynamic authorization can be positioned in all of those different locations. And there are other patterns as well. Didn't mention mention all of them, but we start with very coarse grained plug in time to be governed by policy to provide decisions dynamically and we go all the way to very fine grained

at the data level. So low level filtering and column masking. I was reading your body language there, gal, when when Jeff was asking that question and you're like, oh, you want to go deep? And that was a great question. I'm sitting here enjoying the whole thing. My question is a little less technical, which is kind of from what you see with a typical customer approach.

Is it they want to start off with one application or kind of how do they look at like I want to kind of test this and proof of concept or you know, I want to get my feet wet before I dive completely And so how do people start? Yes. So yes, typically with one application, maybe 2, but you want to start, you know, small because you want to see value as quick as possible. Let's say you want to start with an API use case.

So just get your Swagger file, open API spec, whatever, send it over, it automatically maps to the policy elements and start enforcing policies. This is, by the way, with no change of code. It's so simple to implement. And there you go, you have your final. Controls at the business logic level, not just at the API level. Let's say you want to do the

same with the data control. So it's a matter of discovering data structure, leading that into the policy, what we call policy building blocks and start building your policies. Obviously some implementation processes are more complex than other. No magic in technology. I wish they were, but no, that's not the case. But we are trying to make it as simple as possible. So back to our company name, plain ID.

We are trying to make authorization as simple as possible so they will truly be implemented where they needed to be. So can can plain ID replace or centralized authorizations similar to how a lot of a lot of organizations might use like Active Directory groups, right as how they authenticate or I'm sorry, authorize into applications. Can plain ID act as that role? Or is it more on the policy side and relies on authorizations

existing within an app? Can I shortcut essentially and say, OK people stop building your own authorization and let me centralized that and manage that for you as part of my IM program? Does that make sense? It actually makes sense. And yes, I do want to repeat that people, stop building your own authorizations. There are authorization solutions such as plane ID, Start using them. You don't need to build it by

yourselves. However, it's not an Active Directory on it. And try the replacement, because what you, the example which you gave is providing users with roles or with group that is always still needed. Policies, authorization. In general, they do not replace roles. They do reduce the need the amount of them, but they do not replace them. Think of the role as an addition attribute on the identity, more

information. Typically the information which identity holds is limited to, I don't know, job title, department, location and that's it. It's not sufficient when it comes to making decisions on which data you can access or whatever, right?

So that's where roles would come in or other ways of enriching user data. So those would be all fits to the policy. So how do your customers typically measure that they're getting what they paid for out of this right? How do they measure success with the solution? I would assume faster, more streamlined, more secure authenticate authorizations. But are there other RO is that people look for when they say, OK, we've got plenty of D? Here's how we justified the spend. Yes, absolutely.

So there are multiple metrics we can share. But you know I want to show one example. We have a customer which is a global bank and they implemented the whole like online back banking controls with plain ID. They used us at the API Gateway level, several API gateways and initially, you know, like every new technology, there is some resistance, don't know if that's the right solution and so on.

Today they're at the point where the developer team, the application team, they are excited to, you know, send the APIs to the security team. Here you go. We want to deploy this API just logging to your policy and that's it. So it really reduced time to market for them. Every new API doesn't need to consider who the identity is. Does this identity can see this data? Whatever.

No, they will focus on business logic they had to develop and all the enforcement was done by plane ID together with their API gateway in a very simplified way and it really helps them in provide faster value to their business. Well, actually kind of let off the episode, right? Authorization is so hot right now. So I feel like we need the Zoolander memes, you know, in

full force here. This has been a great conversation and I would definitely encourage people go check out planeid.com/IDC, right? And check out what is going on there. I think you wrote a blog on the intent based access control. And so I think that'll be on that page of people check out. You know, there's, there's so much to unpack here, but hopefully this gives people kind of a sense of what they should be thinking about. So I want to end the episode on

a little bit of a lighter note. We actually started to nerd out very, very slightly before we hit record when you mentioned that you're into science fiction and reading and things like that. And I am as well more on the listening side, the reading side. And so I want to ask you for either a recommendation for me or other people. I know there's a lot of sci-fi

readers out there. What's the best sci-fi book that you've read within the last year or so that people should be checking out if they haven't already? OK, we'll continue that discussions for sure. So I want to recommend an old book, Isaac Asimov. So years ago I really enjoyed reading those books. I read them in cycle and everything that's happening now with the identic stuff made me go back to this to those books. The the one I just completed is Cave Caves of Steel, the first

in the Robert series, I believe. I really recommend reading it again and the full series by the way, because it's really nice. You know, he saw something that's happening now. He saw that years ago. A lot of the stuff that he was writing about, I mean, people that are not familiar with us in all would probably say this is not sci-fi, what are you talking about? But it is, it's truly is. It was written like, I don't know, 40 years ago, something

like that, maybe more. So it's really interesting to see the way he thought and how he thought technology would evolve, and especially what truly happened. And maybe, well, things did not happen as he predicted. And by the way, you know what's so intriguing about Tasimov? When he wrote the robot series, he actually placed the the free robot robot robot rules, right? So he actually defined robots with guardrails. By definition, that cannot be overcome. Obviously, as it evolved,

another rule was added. But still, it's really nice to to go back to those books. So you mentioned Asimov and I and I feel like anything can be science fiction if you put your mind to it. But the Foundation series is one that I've always enjoyed and and now Apple TV has a series on it which I think is great. Not sure if you've checked that out yet, but Foundation is is definitely a good one too. Have you ever read the Bob Averse series of books? Not sure. OK.

So this is one of my favorite series I think of of all time in science fiction. And it kind of follows the story of essentially an agentic AI and space exploration and humanity and all kinds of stuff. So if you like that sort of thing, I'm going to recommend the Bob verse. Shout out to my friend Aspen. I know he he's read it as well and I think there's like 6-6 books in the series and it's really kind of a really cool, I don't know, interesting

approach. I just really like, I know I've talked about before on this show and other episodes, but Bob Averse, BOBIVERSE, Bob Averse are the ones that that I would check out. Jim, how into sci-fi are you? Because I don't I, I feel like you're not so much into the

sci-fi side of things. Not really I, I feel like I'm, I feel like I live in sci-fi or that, you know, in the next few years with everything that's happening with AI, how quickly it's going, moving toward AGI, everything that's happening with robots and self driving cars. Think about it. I mean, we're of the generation where we grew up and we actually would watch black and white TV sometimes or we had color TV, but most people didn't have like color TV's in every room with a

flat screen. And you know, so I already kind of feel like we're living a sci-fi a little bit. Now. I do want to send a shout out to one thing. So it's not a book that I've been reading, but are you guys familiar with Simulation Theory? That the fact that we might be living in a simulation. Yeah, exactly. I mean, that, like, makes me wonder, like, OK, well, things can't be that bad if we're just living in a simulation. Well, I mean, it depends on

simulation. The entire story of the Matrix is essentially about living in a simulation. And if you follow the Matrix closely, which I do right, there were many versions of the Matrix. The first was, you know, ideally a utopia, and everyone was supposed to get along and the human mind rejected it, so they went the other way. So who knows?

Are we there? I went out for a walk last night and there's somebody who has like a bunch of jeeps and stuff and they have all these Star Wars stickers and one says Sith security. I'm like, I know that Star Wars, but I have no idea what it is. And I kind of thought at the time it might come up in the podcast today. So I just wanted to let you know, like, I'm not into sci-fi. I've never seen a Harry Potter movie. I've never seen any any of those things.

Well, first, we're only. Only a SIF deals and absolutes. So that's your first mistake right there. But shout out to that that bumper sticker.

I think that's a great one is I'm getting the sense, Jim, that like us recording this podcast virtually is about as sci-fi as you get that fair. I mean, that's pretty sci-fi, right? I mean, could you imagine having done that when you were, like, a kid? We used to, like, record into tapes and splice it. Or you'd sit there and you'd listen to the radio station and hit record. When a new song was coming on. If it was one that you wanted, you keep recording.

If it wasn't wasn't, you'd rewind and try to get right to the point on the tape. I mean, think about that to where we are today. I mean, yeah, we're living in sci-fi. Demure and old man, you're talking about black and white TV's. You're talking about making mixtapes on the stereo. Gal, I don't even know where to take like the rest of this conversation. Any comments for you gal before we close out? No, it's, it was an excellent discussion. I'm happy to catch up on that

sci-fi book recommendation. You know, next time we'll meet. But thank you for hosting me in this episode. Absolutely enjoyable. Well, we appreciate, Yeah, thank you so much for sponsoring and definitely get the get out on the website show support for Plane ID, who's showing support for us here, planeid.com/IDAC. We'll have links in our show notes for that as well as gal to your LinkedIn profile.

So people who can reach out either with sci-fi book recommendations or questions around anything BAC or maybe even AC access control at this point. Certainly appreciate it. So for that, we'll go ahead and meet it for this week. Thanks everyone for watching or listening. You can find us on the web idacpodcast.com 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.