The right way to look at this problem is that identity is a data problem. What I mean by that is because we have so much fragmented data, there is so much context out there. If you can put all of that together in a single data lake. And that's what Andromeda does, ingest all data from all the data sources, IDPHR systems, cloud providers, most importantly activity logs.
And then once you have everything in a single space, you can run models on top of it. So we done machine learning models around risk scoring or behavioural analysis, peer behaviour, your past behaviour and so on. And then all the use cases really come out of that data and the models. So what does Andromeda do? Well to start with, it gives you visibility.
So it discovers all identities, human and non human, and builds a risk model, a score across posture, behavior and permissions and tells you which identities to focus on, which are your high risk identities, and gives you built in remediation steps. This is identity at the center. If it has anything to do with IAM, this is the go to podcast now your hosts Jim McDonald and Jeff Steadman. Welcome to the Identity at the Center podcast. I'm Jeff, and that's Jim. Hey, Jim.
Hey, Jeff, how are you? Not so bad yourself. Happy 2025 is our first Sponsor Spotlight episodes of of the year. It is, and we're starting off with a bang. Like you mentioned, this is a sponsored episode, so we're very fortunate to have one of the key members of the Andromeda Security team here with us. They are. So it's Andromeda Security. You saw that in title as we were as we're rolling this out. They're an AI powered identity security platform.
You can find out more about them at andromedasecurity.com/idac. And I mentioned it, we've got one of the Co founders here, Co founder and chief product officer of Andromeda, Ashish Shah. Welcome to the show, Ashish. Thanks, Jeff and Jim, really excited to be participating in that. Thank you. Well, thanks for joining us. We definitely appreciate it.
You know, we have a lot of stuff going on in the identity space and I always love to hear origin stories of where did people come from when it comes to their digital identity journey. So why don't you tell us about yourself? How did you get into the digital identity or IM space? Is it something that you chose or did it choose you? Great question. So most of the founding team at Andromeda came from a company called Avi Networks.
Avi was a software load balancer web application firewall company founded in 2013, acquired by VM Red in 2019. And we saw the journey of our customers at Avi into cloud and SAS and we saw identity, especially permissions management was a key problem that our customers were facing as they moved to cloud. It's very different than what's on Prem versus cloud. So that's where the the genesis
of the company started. And then as we started looking into the problem space, we saw that a lot of unsolved problems out there. There are lots of vendors there of course, but there are lots of problems out there that are unsolved. And so if you just when we started and Ramadan, we started looking at, OK, what are the top challenges that we have to that are still unsolved.
I think the biggest one that I think all we know about is identity is at the center of attack, no pun intended, but it's it's a primary attack vector today. It's not if it's when it'll get compromised. And so the attack surface really is determined by the over privileges of the permissions that any identity has, human and non human. So that was the biggest problem we want to solve this. Can we get to a state where even if you have a compromise that is 0 or minimal business impact?
So that was the first problem we wanted to solve. But there are other day-to-day problems such as even today, the access management is manual. When somebody joins or leaves or moves, the manual work flows and and especially in cloud, people don't have patience to wait for hours to get that accesses compliance is a pain today. Frankly, there's a lot of rubber stamping going on. And all of these issues are relevant for both human and non human identity.
And I'll just leave with one last thing, which is NHI, a non human identity has a additional unique problem, especially with the automation and and and and adoption of cloud and DevOps is discovery what's out there. So this was the kind of the landscape with which we saw that. We realized that this is a problem space that we can, it's a hard problem space, but it's a problem space that we can add
value to and differentiate. And so that's where we started Andromeda. Give me some ideas of what the Andromeda platform does, because I'm sure there's a lot of different problem solved. You mentioned NHI or non human identities. You mentioned the human aspect of things like rubber stamping when it comes to, you know, compliance and access reviews and everyone's favorite, you know, IGA activities and things like that. Tell me a lot about the platform.
I know we're going to dig a little bit more detail, but give me just kind of a quick high level to to whet my appetite. Sure, sure. So if you want to see a tagline Andromeda as an identity security platform for both human
and non human identities, right? And the the ultimate goal is that we automate your permissions and life cycles of human and non human based on risk context and behavioral analysis so that even if your identity is compromised, that is minimal to 0 business impact, right? That's what we started with. But but what does that mean? So before I answer the questions, what Andromeda does in detail, let let's understand why it's broken today.
So if you look at the the vendor landscape today, they're very fragmented. They're NHI only vendors. And then there are even within human identities, you hear the buzzwords ITDR or ISPN or Kim Jit and IGAI think the right way to look at this problem is that identity is a data problem. What I mean by that is because you have so much fragmented data, there is so much context out there. If you can put all of that together in a single data lake.
And that's what Andromeda does, ingest all data from all the data sources, IDPHR systems, cloud providers, most importantly activity logs. And then once you have everything in a single space, you can run models on top of it. So we done machine learning models around risk scoring or behavioral analysis, peer behavior, your past behavior and so on. And then all the use cases really come out of that data and the models. So what does Andromeda do? Well to start with, it gives you
visibility. So it discovers all identities, human and non human, and builds a risk model, A score across posture, behavior and permissions and tells you which identities to focus on, which are your high risk identities and gives you built in remediation steps. So that's step one. Think of it as a journey of your identity security maturity to start with visibility,
recommendations, remediations. The next thing we do is real time visibility into who has access to what roles and permissions and more importantly who's using what so that you can right size the roles based on not just usage, but more importantly risk. Because our theory is that only frequently used permissions that are low risk should be part of somebody standing privilege. Everything else moves to just in
time access. So the least privilege is the second set of use cases that we do that moves us to just in time access. There are lots of JIT vendors out there. The way we differentiate in JIT is use context. Use behavioral analysis. If Jim requests a privilege role and if he's always done it, same location, same devices, why ask Jeff? Who's going to rubber stamp it anyways? Automatically approve it, take the human out of the loop and
the risk is low. But if Jeff is asking for this for the first time or is in a different location, then add friction, ask Jeff and tell Jeff what to look for so you can make a more informed decision. That's how we do intelligent jet. And then the final piece is IGA user access reviews based on activities, past behavior and life cycle management of identity. So it's a platform and we can go into the each of these in detail, but hopefully that gives you an idea on what we do.
I think it's helpful because it, it really kind of, I guess it spans the Galaxy, pardon the pun on that. You know, there's this this concept of being data-driven for an IAM program. When I say program, I mean the, the way the program itself operates, the people, the process, the governance, etcetera.
A lot of organizations are sitting on a treasure trove of data that sits in a system and really never gets used for anything beyond, oh, great, we got a new onboarder, a new joiner, a new believer, things like that. I feel like there's so much more that could be done with that data, especially if you're able to contextualize it, bring it into the system and then combine it with automation and say, oh, OK, because X, here's what's going to happen.
Why, right? And or else Z, right, Whatever that looks, you know what that pseudo logic looks like. So I love this idea of it. I want to let Jim ask some questions instead of me hogging all the time. But I've got one last question before I turn it over to Jim. How do people measure success with Andromeda? Because it feels like there's a lot of different ways it could be done, but I'd love to hear straight from from you.
Excellent question. So customers buy a solution to solve a problem, they don't buy a platform, right? We have a platform doesn't mean we sell a platform, right? We sell use cases. So we meet our customers in whichever step of their journey they are in, right. So we have customers who are in the early stage of the journey where well I don't have visibility into how many identities are there and who are the risky ones especially than
NHI side, right. And the other extreme of the maturity curve is, well, I am implementing JET. I need something that is automated based on intelligence and context and everything in between, from role right sizing to least privilege or access reviews and so on. So we meet our customers based on the current pain points, help them solve those pain points better than anybody else. And once that's done, then expand into a second use case
and 3rd use case. So success is frankly measured by, well, what is the current problem statement that you're trying to solve? How can we help you do that? Let's take an example for just in time access. Well, there's a customer who's do decided to deploy Jet and they look at multiple vendors and decide an Andromeda. So let's operationalize that in a phased manner.
Let's make sure Jet is deployed. Once that hits a certain maturity curve, let's look at let's for example NHI use case and so on. And we have a different customer who says I'll get to JET in future. I want to first solve my NHI use case. Let's start there, right and then go on. So that's how we we measure success based on the specific use case the customers wants to deploy in and then land and expand. So Ashish, you are were
tremendously popular. You're boothless popular at ideniverse at Gardner, which was the most recent one we saw. You and Jeff and I are regulars at this conferences every year. You're hard to get much more than a handshake from, but you had a lot of people. We wanted to hear your story, understand what is it that you guys bring to the table. Here's my perspective is that as customers, we want to put
everyone in a box. It's a, you know, we want to be able to relate that to something we understand. And when we have budget line items as practitioners, we have a budget for IGA replacement or IDP replacement. Where is it? Does Andromeda fit? What's the closest bucket? Is it IGA is a privileged access management? Is it ITDR Keem, you tell me, you know, if somebody's going out and saying I got money for IGA, is the Andromeda on that list?
Great. Question Jim and I, I understand totally how we all like to bucket solutions, right? Because it simplifies how we think about it, right? Because there's so many vendors out there and you need a structured way to bucket these and say, OK, this is this category and this is that category. So it's a fair question. We like to flip the question slightly and say, OK, what is the current problem you're trying to solve? OK, you're trying to solve an
IGA problem. Does Andromeda have a solution in IGA? Yes, it does. You are trying to solve a JIT use case. So I'm looking for a JIT vendor. Does Andromeda fit into that category? The answer is yes and so on. So rather than putting Andromeda in one bucket, we like to think that we had a platform that spans multiple use cases across
multiple of these buckets. And depending on what is the current pin point, as I mentioned earlier, we would be able to, if you're able to address that, then the customers would would buy that. So, so that's why we look at it. The, the reason this is an important distinction is that because because of these bucketed vendors, we have this fragmented landscape and we think that the right way to do that is put everything in a single data lake and build
models on that. Let me give you a specific example. One of the most common thing today you see is lots of NHI vendors, which is great. And I'm sure we'll, we'll talk more about NHI later on this podcast. But our contention is that NHI itself cannot be solved in isolation. I'll give you 2 reasons. The risks of Nhis and the corresponding human users are intertwined and the life cycles
are intertwined. If I left the organization, all the Nhis that I managed or owned or used have to be the deleted if they're no longer in use or re keyed and reassigned to somebody else. Otherwise there is a Latin risk of that NHI by the by the now exited employee.
So the life cycles and intertwine same thing around the the risk right and a risk of a human user is not just identified by the rules and the access to the application that he or she has, but also the relevant roles and permissions all the Nhis that he or she is managing right. And finally, I would say that other than the discovery component of NHI, which is unique because human identities have a directory service and HR systems, Nhis don't.
Other than that, the permissions management, the governance, the privilege access management are common to both human and non human. So why have separated solutions when you're trying to solve the same kind of problems? So, so that's, that's why we don't like to bucket ourselves that we are IGA or PIM or Pam or or Kim or so on. We like to say, what is the use case you're trying to solve? Let me let us show you whether we can address that better than
anybody else. And then if so, you can use Andromeda. OK, that's a really cool perspective. So let me ask the question then, what is the ideal customer type? Because I work with some clients who were mature or were very mature at one time and they kind of reached some of the sticking points with the technology solutions they have. They can't take on some of these newer use cases that are presented from cloud environments or maybe their scale has grown.
I also work with clients who, you know, they've really just haven't invested in IM in the past decade. And so they're more or less a Greenfield. Even if they have an IGA solution, it might not be one that, you know, people commonly talk about it anymore, might be that old, right. So what is the ideal client who comes to? Is it the the savvy client or the client who's just getting their feet wet? Or maybe it's a savvy practitioner who took a job and it's, like I said, Greenfield. Yeah.
That's a great question. So I'll, I'll answer it with two perspectives. What is an ultimate vision? But as a start up, what is their current focus, right? Because the end of the day, it's a matter of physics, right? So as a start up to be successful, you have to make sure that you are addressing the use cases in the right order and
not trying to boil the ocean. So let's start with the with, with what, what, what we support today and what our ideal customer today looks like our ideal customer today is anybody who's trying to solve an identity security problem for
cloud and SAS. And whether and in each of the buckets that we talked about, whether it's around visibility and risk scoring of your identities, human or non human, it's around least privilege, it's around just in time access in cloud or IGA for cloud and SAS. So in any of these buckets, if you're focused on your cloud and SAS environment, that's our ideal customer today. We do not have an on Prem solution today and so that's
that's the current focus. But segwaying into where we are going, well absolutely we will scale into on premises as well and that's a longer term story as we matured our product, our integrations and so on. And so our vision is to be able to be the identity security platform across human and non human based on risk and context and behavioral analysis across all of the use case. We talked about cloud SAS on Prem today it's cloud and SAS you.
Mentioned non human identities said maybe we'll get it. Yeah, we're definitely going to get to that. Your website screams human and non human, but I would say 2024 was the year that we woke up and said, oh, if these non human identities, they're a problem that we should deal with. I've been an identity for over 20 years. It's been there the whole time. The problem has been there. But now everybody's talking about it. Maybe 2025 is going to be the year that you know, you know,
all heck breaks loose. But my question to you, Ashish, is why now? Why is it that everyone's waking up to this problem now? It's, it's a great question. You're right. I think my thesis there is that we hit that, that maturity curve, we hit that inflection point off NHI usage. So if you think about it, Nhi's were there. It's not that the machine identities or Nhi's were not there on premises, right?
It's that the cloud and SAS has increased the a use of automation, DevOps and that has proliferated the use of Nhis. And I think we try to bucket ourselves or we try to bucket Nhis into all Nhis are equal. They are not that different kinds of Nhis from service accounts to API keys, tokens to even AD credentials used for on premises, right. So I think. That's a podcast on Albert's own. We just said that, right? Yes, that's right. That's right.
But the reason I think the NHIS has taken up is because I think we've hit that inflection point where the adoption of dev OPS in cloud and automation has gone to a point where it's become a serious problem. And the one of the biggest challenges with NHIS that I think we referenced earlier is there is no single source of truth that is not directly service or an IDP equivalent for NHIS.
And so I think it's even a harder problem because you can't gate all Nhis through a single funnel like we could do through SSO and MFA for human users and look at HR as a single source of truth. So I think that's the reason why all of these things coming together, we are seeing a lot of focus on NHI, yeah. And you know, I feel like we are now experts in managing it's human identity, right?
I mean, it's, it's kind of boiled down to it's simple, Simon, there's some authoritative stores, normally the HR system for who works here, maybe there's a contractor database. And then we have a IGA system and this fits out Access. It's really these MH is that they're hard to manage and with kind of what you were describing earlier, sounds like you went right after the probably you took on the hard stuff. What makes this so hard to to
manage these? Yeah. I'll answer the questions, but I would also contend to your point that HI is a solved problem, but human identity is a solved problem. I don't think so. It's not a solved problem because it's all manual and not really based on context. I think the Igas today are just mostly rubber stamps. They all the roles are over provision, like 95% of roles are over provision even for human users. So I don't think it's a solved problem. But let's let's let's part that
for a second. Let's come back to an NHI question, which is what makes the NHI hard. So let's start with what are the aspects of NHS security that are relevant? I think we all focus on the first one, which is discovery, credentials management, life cycle management. I like to put all that under the authentication, roughly authentication bucket, which is OK, what are all the Nhis? So do discovery because there is no central place. What are the key rotation or
credential rotation hygiene? How often should we rotate them and how should we cycle them? When somebody with the NHI is deleted or, or the passwords are rotated or keys are rotated and so on? That's what most of the vendors are focused on. It's an important problem, but that's not the only problem. There are two other aspects of Nhis that are often overlooked. The the the the next one being
the permissions management. They're all right sizing because just like human users, NHI has a role and a set of permissions and if they're over privileged you have a large attack surface. In fact, I would argue that there are types of NH is where key management is irrelevant. I'll give an example. Think of AWS EC2A. VMAVM has an inherent EC2 instance profile. It's a temporary credential that
AWS manages on your behalf. You as an enterprise don't have to worry about key rotations for these kind of workload identities. However, you absolutely have to worry about the roles it's assigned. Because if that VM is compromised, the attacker can assume the role that that workload identity is able to take, and if it has additional excessive privileges, all hell
can break loose. So the permissions, the role rightsizing parts of NHI is equally important, in some cases more important than the credential piece for some kinds of identities. That's what makes it hard. The four and final piece I will talk about a third type of security is securing the client. Let me give you an example. Let's say you have, let's focus on AWS. You have a role in my, I'm an enterprise in my enterprise
account, I have an AWS role. I'm trusted a third party, it's a another SAS service, their AWS role in their account and there's a client applications that using the role to access my my, my enterprise role. There is no credential exchange here. It's a role to role trust. What should you protect? Two things, the permissions in the role so that there is Nexus, a privilege and the client application, the third party applications which is using the role, so protecting the client itself.
We often overlook this component, this part of NHS security as well. So I think we're still in our early phases of NHS security. There are multiple aspects, we all focus on one, but there are many things, many hidden dimensions to NHS security and that's what makes it hard, good. Answer and I want to come back for the follow up on #2 but this was a triggered question so bonus question. I asked this one a lot Jeff and I don't agree on the answer.
Is there a nuance between non human identity and non human account or do they basically mean the same thing it? Is a tricky question because account word is so overloaded right? And AWS account is an Azure subscription is AGCP project right where the traditional account means an identity. So we we think of account and identity almost synonymously because the way to think about it is that it doesn't have a set of permissions roles, which
allows it to do something. Then you need to worry about as an identity. And and I think, I think, I think if you if you apply those first principles, then you can think that NHI and the non human account are are equivalent. I was. Kind of thinking of the term account in terms of, you know, the kind of the traditional sense of they username and password kind of thing. Not so much the AWS account, but I, I kind of feel like there's a future and I don't want to think it's too far off track.
A future where you have AI worker robots and they can make security decisions on what they're not account or, you know, accounts. I'm called using the term accounts again should have the permissions that they have. I can basically make decisions like people. So that is a an area where a non human to me would be an identity. I digress. Well, but I, I want to get to this because you, because we definitely don't agree on this one. And that's fine, right? We're, we're exchanging ideas
here. Where does account stop and identity begin and vice versa? I think that's really kind of the crux of the question is you have an identity. I have an identity. We also have accounts. Can a non human also have an identity because it also has accounts or maybe it's its own entity, right? Or whatever we want to call it. You know, Jim, in your example,
a worker bot, right? Or AI bot or chat bot or whatever it may be. There's going to come to the point where you're going to effectively hire AI workers to do things. Do they, do they have their own identity because they have account? I don't know, right? I think that it's, it's an interesting discussion in my mind because it's very semantic and almost kind of like, you know, philosophical. So so we have a perspective one I was.
Just going to say, I think we should have an episode and tap into smart people like Ashish to answer that question in under 3 minutes. And then kind of like we did with I Am versus digital identity, What's the difference and make an episode out of that, yeah. So if I may add one thing, we actually see some of the practical implications on this even today. So for example, I'm Ashish, but I'm logging into AWS through SSO. OK, so that's an identity right?
But I might also have a local break class account within an AWS account. Is it the same Ashish or is it a different account? We, we, what we do is we put all of that under a hierarchical umbrella. We call it in we, we, we call it an I'm looking for the right word here. It's an instance or it's, it's an incarnation. So Ashish is the ultimate identity. Ashish has multiple incarnations. 1 is an SSO incarnation, 1 is a break class
incarnation. That helps us because you can use the incarnation when it's makes sense. Like who logged in, the specific incarnation logged in, Who does it belong to? It belongs to Ashish. So you can answer these questions depending on what you're trying to. You can you can. You can get to the right answers based on what you're looking for. Similarly to AAI bot question, the AI bot can be an NHI itself with its own incarnations, but the ownership is Ashish's because Ashish manages it.
So you can do a combination of human and non human ownership relationship and within the identities incarnation notion where it's just one one identity but has multiple accounts, multiple incarnations depending on which system it's used in. That helps us in general, but it's a larger conversation. It is and it I feel so, so, so semantic around this, right, because you're right, we use accounts, we use identities, we use IAM to mean a whole bunch of different things that probably
shouldn't. And words matter, especially when you're talking to people and make sure you have the, you know, you're using the same language, the same definitions of those types of things. But I'm going to I'm going to lay my, my, my Infinity gauntlet down here and I'm going to I'm going to drop the mic on Jim real quick. We don't call it non human accounts. We we've been calling it this entire conversation, human identities and non human identities.
So there you go, Jim. That's how that's so my my comeback if you. Came to work at my company. You just said man I gave you here's your login for your e-mail, here's your login for the application 123, and here's your login for application ABC. Would you say you have 3
identities or three accounts? I would say I have 3 accounts that map back to my identity, my mastery record, whatever you want to call it, Incarnation as she mentioned, like things like that is you've got an identity, and then if you think about as a tree underneath, if you double click an identity, you'll see three folders for three different accounts there. There's one Jeff Sedman and the world.
Doesn't need any more. And also, I think with with identity, using the term identity when it comes to, you know, hey, Terraform spins up 500 accounts a day. It doesn't have 500 identities, doesn't create 500 Jeff Steadman. So it creates 500, you know, accounts that exemplify Jeff Steadman. We're going off the deep end here and I have a better question. I I think it's better, it's more in target because you talked about this is a data problem.
And I totally agree, especially when it comes to authorization. I mean, that's the the hard problem, right, is understanding what an account or an identity has access to in total, what it should have access to, which is usage patterns. I mean, you think on this hard problem, talk to us about why. I mean, to me it's like it gets down to like exactly what the issue is. It's trying to drive toward some some instantiation of least privilege, right 100.
Percent and and you can also call it zero trust for identity right? What is the definition of least privilege? What is the definition of 0 trust to us to at Andromeda? It means that any identity should only have those set of permissions on it's standing basis, on the standing basis that are frequently used and low risk and why that matters that remember we said it's not if it's when you'll get compromised.
So when you're compromised, if your tax surface is defined by low risk permissions, then you don't have nothing to worry about, right? And and everything else that moves out goes to just in time access, which is again automated based on context. But to achieve this true zero trust or true least privilege, you have to understand two things. You have to understand risk and you have to understand usage. Usage is based on the actual activity that that identity is doing, but not just that
identity, the peers. So that's where some of the machine learning models come in. Well, if Jeff and Jim are part of the same team, is there a peer behavioural model that can also influence what should be part of standing privilege or not? Because the end of the day, remember we are trying to achieve two things at the same time, security and agility or productivity anytime, especially in cloud and SAS, if you slow down your developers and users, they're not going to adopt the tool.
So we always trying to strike the balance and to do that. Coming back to a data problem, Jim, if you can analyse the user behaviour, the peer behaviour, the context, the locations, the devices, the past history and then combine that with the risks of the permissions. So each of AWSGCP Azure have 1520 thousand individual permissions. They're not equal. There are view level permissions and list level permissions to read, write and I am level
permissions. Can you give a different risk levels, combine that the usage models and then derive the zero trust or this least privilege? That's the Holy Grail and that's what we are doing at Andromeda based on the data lake and that's where the machine learning models, the AI models come into play. That's why the hard problem, and that's why it's more exciting. All right, so I smelled an AI
conversation. I knew it was coming and look, I'm, I'm a little bit sceptical because now I start to see a whole bunch of applications and products and vendors, you know, jumping on AI and I guess help me understand, right. You know, we had AI and I think of AI now as generative AI, not machine learning, which is also AI. Yes, but it's sort of like the what I'll call the legacy definition, if you want to call it that. Help me understand where does AI come into the Andromeda
platform? What is it used for? You know, is it, is it really generative AI? Is it ML or some mix of the two? Help frame that for me from a contextual perspective. Definitely short answer, it's a combination and it's not AI for the sake of AI. It's not AI washing right. We we are genuinely trying to figure out what is the best way to solve a problem.
So to give you an example, right, once you have all the data in a single data like it's a graph based database, what are the questions we're trying to answer? So first is a risk scoring. So we have a three-part risk
model based on posture. So posture, risk configurations, MFA, etcetera, key hygiene, behavioural risk, past activity, behaviour, applications, logins, locations, etcetera and privilege risk analysing the riskiness of the permissions and the accesses and so on. So this is where as we use some of the machine learning models to define the risk score in the
best possible way. Mathematical models, some of their machine learning models for assigning risk score to every role, every AWS account, every identity, every application and so on. We also use behavioural machine learning models for looking for anomalies, anomalies of a given user compared to its past behaviour, anomalies of a given user compared to its peers and so on. And these are well defined machine learning models, clustering models, anomaly models and so on.
We use models for so. So one place we do use generative AI is for summarizing session activity locks. So what we do is let's say you got a privilege sessions for two hours. We look at the activity logs, let's say it's AWS. We look at the cloud trade logs of what Jim did in the two hour privilege session, every action Jim performed and then the output of the model is an English language. Somebody saying Jeff logged in for two hours, he did these these, these actions, these were
anomalous, these were expected. And here is everything he did, somethings was successful, something was not successful. That summarization is where we use Gen. AI models, but that's a very specific use case. So again, it's the same data lake with the context, with the behavior, with the activity logs. And depending on what we're trying to do, we use different
ML and AI models. So as a as a customer, can I tune the, you know, the models in a way to say, OK, here is what I'm looking for or here what it here is What's risky? I would imagine it takes time to develop whatever the access patterns might look like, right? How do you know if something's risky unless there is an outlier of data, right, for it to pick up on What is, I guess one first question.
How do I tune some of these, you know, models to look for what I'm looking for or make it more fine-tuned for my application or whatever it may be? And then how long does it take, you know, realistically to establish a baseline of what is normal versus what is not normal? Great question. Let me start with the second question first. So when we onboard a customer, if the customer has the last 90 days of log data, we use that
for baselining. So our, our current training period is about is 90 days worth of data and we can always go longer. And for most cases, customers usually have that 90 days of data in the history. So we can hit the ground running it with that 90 days of history immediately, right. If the customers doesn't have any data, then of course you have to wait for 30, sixty, 90 days for the baseline to be established.
But that's rarely happens. Now how we how we train our models is we don't use customer data to train our models because the good news is that especially in cloud and SAS, these are standard applications and standard behaviour where you know what is what is a risky behaviour of a certain certain permissions and what is not. So we can use genetic synthetic
data to train our models. And similarly for the Gen. AI piece where we send to to the LLM models to translate to an English language, there is no customer data that's being sent because. It's, it's the actions which are generic AWS or Azure actions which are getting translated and the context is getting translated. Nothing that's customer specific, right. So, so that that's a good part in terms of tuning. There are multiple aspects of the model.
So the risk is impacted by the set of permissions as well as the type of assets. Is it a production environment versus a dev environment? Is it does it have PIO data or not Those are tunable by customers today and that impacts the risk score and so on the other aspects we will we are in the process of exploring how we can make some of those models more tunable, but that's again based on customers needs that should be fairly straightforward for us to do.
Now, one of the biggest criteria for us to implement any ML or AI model is explain ability. If we cannot explain what the model did in an English language in a reasonable way, then we do not want to put it in the product. We do not want to offer that, right? So explainability is a very, very important consideration when we develop the product. And then finally, no models are
perfect. If we say I'm with 100% probability, I'm telling you this is what the case is, you're fooling yourself, you're fooling the customers. That's not the right thing to do. So a lot of our recommendations, lot of our summarizations and, and, and analysis, we put up what we call it confidence interval saying look, all confidence interval for this analysis is 60 to 80%. Of course, if it's below a certain threshold, we won't even show it.
But beyond certain threshold you can, you can configure and say start showing me your recommendations and analysis as long as this hits a certain threshold. And then we'll show you what that threshold we have hit so that you can tune that and say no, show me only after it's 80% or show me anything about 50% and so on, right. And then finally, we take input from the customer saying this is not true, it's a false positive. So that goes back into the the
product, right? Because we're trying to strike a balance between false positive and false negative, right? And every customer has a different level of tolerance for that. And that is something you can tune and say, show me even if you're 50% confident, show me or show me only up for 90% and so on. And then take the feedback and tune the model again and so on. Hope that helps. It does. And I think 11 last question for me will be, I guess the security
of the AI models themselves. And I think you kind of mentioned is you don't you don't put customer data right into your model. But what are the what are the guard lines or guard rails for? What stays, I guess on Prem or in my specific cloud versus your cloud versus maybe a third party cloud like an open AI or Anthropic or, you know, Google or whatever it may be. How do you see those three things mixing and how do you make sure that data doesn't
cross boundaries? Because I feel like that's an area that needs to be explained. Anytime someone's saying you know, AI, no. 100% right. So I think you, you, you, you outline that framework very well, right. So first of all, from the customer cloud or customer Prem, we don't pick any data per SE. The only sensitive information we are getting is of course user IDs and the emails because it's
it's, it's an identity product. But none of the data is pulled into Andromeda. All of that, whatever we pull in stays within Andromeda's cloud environment via SAS product. And none of that goes into a third party, whether it's Open AI or Anthropic or any any other model because what we are sending and again, remember we're using the LLM models only for a very specific use case, which is session summarization. And if as a customer says, I don't want that feature, no
problem. It's it's, it's a very modular product. So they're only the actions are going in saying some anonymous user, user X perform these sequence of operations, translate them to an English language summary for me. So there is no data that's going into a third party. But I think at a larger point, this is a very, very important topic to us.
It's very near and dear to us because as I said earlier, if you can't show the safety and security of our data in the model and can't explain our our answers, then we can't build trust in our customers, right, So, so. Ashish, I wanted to say bravo on the explainability point. I mean, I love that I, I've been a voice towards us for a while, which is how can I sit in the witness chair and explain why a decision was made if I can't explain it?
Some black box AI decided is not going to be an acceptable answer in my opinion. So bravo on that. You talked a lot about models and you know, I, I see this trend that's happening in the market, which is you've got a more savvy client. I.
Love the data lake concept. I think the client wants to have a hand in, you know that data lake that their data, they they want to help design it. They want to say, hey, my business is a certain business and to us here's a certain data element that is not important to anybody else in the world. So you haven't figured out this use case. This is specific to me. I want to have my product build that into the risk score, which I'm assuming is part of a model.
So my question to you is like as a customer, do I have any influence over how that model works or is it a black box to me? It's a great question. So I think the answer is in it depends. We are, we do have certain tunable parameters that you can influence to adjust the model. Having said that, we will be looking in future where in your case you know as a customer based on your data, these are the kind of models that might
make sense. And maybe you already have developed the model and you are asking can you use this model for me for example. That is something that we we we were looking at potentially in the future. The way we think about this is the following. We cannot be the be all end all, of all the risk calculations and all threat detection and so on. We build the product with doing some of that on our own and ability to inject external threat signals or external any kind of signals, risk signals
into Andromeda, right. So the product is built with that capability. I'll give you a specific example. Let's take an example of an EDR and XDR solution. We're never going to be, we are not an XDR solution, but XDR solutions have powerful signals on devices and locations. Can that be inserted into Andromeda? Absolutely. That's something we'll do because the ultimate goal, remember what is our core? Our core is permissions, right sizing, automating permissions and life cycle, right?
So for example, if there is an external threat signal that says this identity is compromised, we can near real time bring all its permissions down to 0 and make all the JIT approval, the privilege access go through multiple gates. That is the power of Andromeda. That's the ultimate, which is it's not if it's when you'll get compromised, but when you're compromised, can you eliminate the attack surface as fast as possible? Yes. And that's where we shine and that's where we differentiate.
So I know I answered your question in in in a couple of different ways. But to summarize, we have some tunable parameters for risk models. We will enable some more, but we are open to taking additional signals, external signals into Andromeda to make more intelligent decisions. Yes, that's the goal I love. It I love it. I love your passion. I think what makes identity companies go to that next level is having somebody like yourself who's passionate and very
intelligent and a deep thinker. I wanted to ask two more questions before we take it out. So 1, you mentioned earlier that you set up a landing page. I'm sorry, Jeff may have mentioned it. Andromeda security slash IDAC. That's where people can go to get more information. What, what will they find there? What are you going to have as that landing page? Great question, Jim. So it's it's an offer for a free discovery, risk coding and permissions rightsizing. What does that mean?
We will, as part of this offer, give you full visibility, full discovery of all your human. That's the relatively easy part. But non human identities as well in a single dashboard give you a three-part risk of each of those identities. So you know which identities are high risk and why with built in recommendations and remediation steps and right size the rolls for you for all of those identities based on its activity pattern and risk. That's the offer.
I love it, I love it. Final question to take you out from the the hard part and then we'll do our lighter note. So you're on the identity at this linear podcast and a lot of our guests always wind up and accidentally falls out of people's mouth, you know, because identity is at the center. So when you first heard about our podcast, relate that back to Andromeda security in your platform identity of the center, what does that mean to you? No. It's, it's very relevant.
I think I mentioned in the top of the podcast like identity is at the center of security today because I think depending on which you're 2320, four 2/3 to 3/4 of all attacks are related to identity one way or the other, right. So especially in cloud and SAS then there is no physical perimeter. Identity is the perimeter and your tax surfaces is the list of permissions you have. So it's very, very relevant. So when I heard IDIC for the first time, I said, wow, that's so true.
I, I don't think you started it when identity was the primary attack vector, but that's where we are right now. So we had. Plenty of foresight. Yes, and. Luck. Yeah, No, we knew it. Come on, Let's let's let's. Help ourselves on ships like. We knew it was at the center. We bought the domain name, trademarked it, copyrighted, all that good stuff. So yes, we you're preaching to the choir here. We feel like identity center. That's why we named it show as it is.
All right, Jim mentioned. Like that's the hard part. Now it's the even harder part where we talk about ending on a lighter note, something that is, you know, maybe not identity related or maybe it is, I guess, depending on how you look at it. And we were kind of kind of spawn ideas for on this and I kind of settled on this idea of books on tape. And that's how old I am tape, right, Everything's recorded and
how etcetera. And we were kind of talking about a couple of different sci-fi things that we were into and stuff like that. You had a recommendation. So I want to give you an opportunity to sell your recommendation to everyone else, because you sold me on it. And it's in my Audible queue waiting for me for my next flight. And then I'm going to give a recommendation. And then Jim's going to yell at us, you know, from his porch, you know, saying get off my lawn
or something like that. Yeah, definitely so. Before I give my recommendation, I think I got into listening to books When, when I I love reading books, but I don't have time. But when do you have time? When you're commuting? And so that's when I got into the books and then COVID hit. So when when we started working from home, so I had to find time to commute. So I can listen to the books, right?
But I got into the books a few years ago and I wanted to do something that's not tech related at all. Still intellectually stimulating, but nothing to do with identity, nothing with cloud, nothing with tech. And so I got into sci-fi and the best book I have listened to is the Project Hail Mary by Andy Ware, same author who wrote Martian and a couple other books as well. But I highly recommend that book not to read, but to listen to.
Because if you see the book has not been read by, it's been performed by, they've actually done a full production in a studio with different accents and different dialects and different sound effects. So highly, highly recommend Project Hail Mary. So that's my recommendation. You sold. Me on the performance then, because I've listened to, you know, several audio books and you're right, they're usually someone reading and it's usually one person you know, and hey, more power to them.
They're trying to do different voices maybe sometimes and things like that. It's like, OK, but you know, if it's a full on production, sign me up. I'm in and I'm a big sci-fi guy, so you know, this is kind of right up my ally. I was like, all right, sheesh, you got me downloaded. I'm in. So I had a recommendation for you. Now it's not produced, like you said, it is definitely someone reading, but I think it does a good job.
And I think the story is, you know, at least from my mind, very original at the time I read it several years back, but is becoming, I think a little more relevant. And it is a it is a series called, they call it Baba Verse. And there's five different books and you can certainly listen to them as well. We are legion. We are many and kind of something that, you know, other
things like that. And the whole idea is basically AI is sort of at the center of this conversation, but it's a little more human type approach to it. And I don't want to spoil it because they're really it really does kind of pick up pretty quickly And then sort of like, oh, you know, there's a lot going on here. But I have my recommendation is Bob Averse. It's by Dennis E Taylor, the 1st in the series is We are Legion. It is my go to recommendation for anybody who is a sci-fi
junkie, you know, like myself. So hopefully people will check that out. Jim, how about yourself? Do you have any E audible, you know books on tape or you know other recommendations? So I've had Audible accounts over the years. I am not a sci-fi junkie and I was reminded of that over the holiday break when I admitted to my son that I've never seen any of the Harry Potter movies. I don't. I'll make it a I'll admit to
I've never seen one either. And that might really, but I've never seen one and I just don't have the interest either. Lord of the Rings, give me, give me that. I'm all in. But Harry Potter, not my gym. As you could probably expect, I've never seen any of the Lord of the Rings either. But I mean, this floored my son and I was surprised he was a Harry Potter Potter junkie. But you know, my, my overall recommendation is, and you've heard me use this term a lot, Jeff, you need to sharpen the
saw. And to me, that's all about getting outside of your normal zone. I remember I had a, an Audible subscription to Harvard Business Review and it's dry, it's pretty boring, but it gets you thinking about the way the organization runs and a lot of articles on strategy and you know, heck, now what we do is we help our clients build their identity strategy and be able to align that to the business strategy. I think it's so key.
So if you're not staying sharp, you're using old ideas, then you're not going to be able to remain relevant. You can take breaks year at a time, 2 years at a time. You start taking five year at a time, breaks of continuing your education, continuing to sharpen the saw. You're going to be irrelevant very quickly. You're. Always sharpening the saw I need. I need a break, you know.
Here's the $1,000,000 idea is someone should write an engaging, you know, story style approach that weaves in some of those things. I know there was one. I can't remember it. It's like an IT book that's pretty famous, and it's the. Phoenix project or something
Phoenix? Project I need to see more Phoenix Project style books where it's a story and it's, you know, it's weaving in little parables along the way, you know, that people can kind of get into then you sign me out and then Ashish. We do like a full production of it with like sound effects and, you know, different cast, voice cast and things like that. Like I need to see more of that in my sharpening the saw. You know, I think there's more money in writing a book like Harry Potter.
Who? Knows, I mean, you know, you were right. The identity at the center, audio drama. I mean, that's what we produce basically every week. Yeah. All right, let's go ahead and leave it there for this week. Ashish, thank you so much for joining us. I'm going to have a link in our show notes for people to check out Andromeda. It's Andromeda security.com/idac. Take advantage of the offer that Ashish mentioned that I think that sounds pretty awesome.
And then all the link also to your LinkedIn profile so people can reach out if they have questions and things like that. But thank you so much for joining us. Any parting thoughts before we wrap this up officially? No. Thank you for having me. This was a fun and engaging conversation and I'm glad we are all trying to solve the hard identity security problem in A and and and having some fun doing that. So Yep, looking forward to more fun coming up we.
Try to have fun, sometimes it works, sometimes it doesn't, but we'll leave it there for this week. Thank everybody for watching and listening. You can find us on the web, idacpodcast.com, reach out, ask questions, engage either on YouTube or podcast or LinkedIn or wherever you find us. We always appreciate that. So with that, thanks everyone again for listening or watching, 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.