#337 - Adaptive Authentication and Fraud Prevention with Ping’s Patrick Harding

Policy enforcement decisioning have to be very local, but the policy itself that's going to be used in the in the policy decision engine, it can be pushed in so it can be administered somewhere else and then pushed in. So that it basically is, you know the policy decisions running locally and that that addresses the performance concerns which a lot of these SAS applications are going to have in in these situations. So I guess that's the benefit of

standard, right? Is that absolutely all the applications can kind of subscribe to the same standard and you get greater adoption of this model? Yep, yes, I mean that. And again, this is this is not available now, this is still early.

This is some of the evolution of all of Zen and where it, you know, where it's sort of going to, but it's to enable some of these use cases where, you know, a policy can be developed, you know, and controlled by a, you know, a customer organization and pushed into lots of different SAS applications. So they all you know, so you all have individually different policy that you can use in those situations. This is identity at the centre if it has anything to do with

IAM. This is the go to podcast now your hosts Jim McDonald and Jeff Stedman.

Welcome to the Identity of Center podcast. I'm Jim McDonald. I am not joined today by Jeff Sedman. Unfortunately, he was not able to make it today due to business travel, but I've got a great show lined up for you today. We're going to talk about adaptive authentication and fraud prevention. So if that's right up your alley, you're on the you tuned into the right episode. You know, before we get started,

it's our tradition to go through our discount codes. I've got only two today, but there are big ones if you're going to the European Identity and Cloud Conference that are known as EIC 2025. It's in Berlin and the dates are May 6th through May 9th. We've got a code, it's IDAC 25 MKO that gets you 25% off the conference rate. The second conference discount code we have is for Identiverse 2025. It's in Las Vegas. It's that's the Mandalay Bay this year.

So if you haven't been to Mandalay Bay, it's going to be exciting for that reason, but it's always one of the best conferences of the year. That's June 3rd through June 6th. We're going to have you use the code IDV 25, dash IDAC 25. That will get you 25% off these two codes. By the way, you're not going to find better out there. So I get the temptation to go out to Google and look for discount codes. I'm just going to let you know ours is the best one available.

So as I mentioned, we're going to talk about adaptive authentication and fraud prevention. Joining me today is Patrick Harding. He's the chief product architect at Ping Identity. Welcome to the show, Patrick. Jim, thank you very much. Thanks for having me back. Appreciate it. Yeah, I'm really glad to have you here. Let me ask you a quick question. Are you going to be at night Danvers this year? I am actually going to be at universe, yes. Also probably going to be at EIC

as well so I'll be at both. Oh good, good. We can. We can share a beer and one or both, or not share a beer. But I have a beer at the same time and the same. Value, Jim. I'll buy. I'll buy you a beer. How's that? Let's do that. All right. All right, And I don't have to share with anyone. That you can do. It's all yours. All yours. I can. Almost Yeah, my my girlfriend might have might argue with that, she might want me to share with her, but. Well, there you go.

So Patrick, you, it's kind of our tradition around here to ask how did you get into identity and did they choose you or did you choose it? Actually, so Jim, I'd say it's a little bit of both. Back in the day, late 90s, I was doing cybersecurity before it was called cybersecurity, actually doing a lot of firewall infrastructure, network security infrastructure, things like that.

In the kind of the early days of the web at a company called actually Fidelity Investments in Boston, I quickly realized at that time that poking hose holes through firewalls kind of wasn't going to be the right approach to secure web interactions and stuff like that. So I ended up looking and thinking about kind of identity and, you know, those sort of

things. And actually coincidentally, at around the same time, Scott Mcneely, the CEO of Sun Microsystems, contacted the CEO at Fidelity and said, hey, Ned, there's this thing called Microsoft Passport that I'm sort of worried about basically. And, you know, think of it as centralizing all authentication on the web, owned and controlled by Microsoft. We don't think that's a good

idea. We'd like you and a bunch of other companies to join us at this thing called Liberty Alliance and you know, come up with approaches to basically deal with that. Obviously back at that point in time, you know, 2000 and one 2002, Microsoft's reputation was very different than it was than it is today. I would say. So if Fidelity joined, I got involved and that work at Liberty Alliance ended up being the foundations of what was what became SAML or SAML 2 to be more

specific. That work I did with SAML 2 led me to Ping Identity where we started to do the first, you know, Federated single sign on capabilities, dedicated Federated single sign on and you know, gives me 20 years later basically, you know, still, still solving identity problems because, you know, we, we, we, we, we never finished it seems basically. It's kind of a cool story.

I kind of feel like you just said something like, so I was sitting there with Thomas Jefferson and John Adams and we were kind of talking about, Hey, what if everybody came to the table and voted for the leaders and, and, you know, like had that level of conversation because you just being dropped some some heavy hits in the beginning of, you know, identity kind of becoming what it is. So I thought that was a pretty cool, pretty cool story. Put you right there in the in

the as a founding father. Yeah. Well, it was early days, definitely. And it's it's kind of come a long way. Obviously we'll talk later about the evolution of Samuel and Open ID Connect and stuff like that. But yeah, there's a there's been a lot going on over the years. Yeah, yeah.

So I wonder every once in a while I like to do a topic that you kind of feel like, all right, we've been talking about this for a decade or more, maybe 2 decades. And it's kind of old hat. But we got to remember new people are coming into the industry and trying to kind of wrap their brains around some of those. And I had a recent conversation with one of my colleagues and he was asking me about authentication and more specifically adaptive authentication.

So he had a SAS application that he had a particular part of this SAS application that this kind of that admin section and he wanted to force users when they access this part of the application to give a multi factor authentication. So it's kind of like the the classic use case for adaptive, I think. And so I was thinking this would be a great topic for a podcast and then you and I started to collaborate about having you on. I thought you'd be the perfect

guess to talk about this. So I'm just starting with, I want to start, Patrick, with, you know, what are some of the questions that you had asked this friend of mine in terms of trying to uncover what he was trying to do? So what what he's trying to do is something we used to be able to do quite easily actually back in the days when we were, you know, when organizations were running these applications

themselves in the data center. We had, we had much more flexibility in terms of being able to apply policy essentially to, to different things. And I would say I, I would point at the, the WAM products, the web access management products back in the day like the site minders, the Oracle access managers, you know, the Sun had a product in that world. Everybody had a product in that world. They, they were actually very good at helping companies

actually do this. We can, we can talk about why, but with the evolution of SAS, you know, SAS really emerged where the, the point of SAS was that it's going to be easier and simpler for you to, you know, to, to use this application, you know, Mr. Enterprise, but we're going to take away a lot of flexibility, all right? We're not going to give you all the bells and whistles you might have had if you were able to run this same application on premise.

And so that if you're going to get what you get and don't get upset, as I used to say to my kids basically. So you know, that's really, you know, the fundamental sort of issue here is that SAS applications have not done a lot over the years to cater to, you know, different enterprise requirements that might emerge on a case by case basis because they don't give you a lot of flexibility.

I, I kind of had the same thought pattern that you just went over there where, you know, when you had what we call legacy authentication or web authentication, web auth and systems, you'd have essentially some sort of filter in front of your web server that would examine every request that you're making. And you can set a policy that it would look at that HTTP and say you're trying to access slash

admin. We're going to kick it back and determine whether or not you're authenticated at the right level. And if not, we're going to step you up. Absolutely. That's where I started as well. And then I started to think, well, you know, there's the legacy piece, but there's also a lot of application now, single page applications. And you can't always just do URL filtering. So it's that too. So I think I so in, in terms of

that really, you know, so where we are today, I think in so we don't see a lot of adaptive authentication being enabled on SAS applications. We are we still seem to see it though on I'll say and when SAS applications are more focused on, you know, for enterprise and for workforce, things like that. But we do do it see it in our customer facing applications where organizations are building and developing and deploying

those applications themselves. Because you know, to me adaptable adaptive authentication is actually a authorization or policy enforcement problem. You, you basically need to apply policy at certain points in the application where you where you want to make a decision on, OK, do I want to essentially reauthenticate, step up the authentication, whatever it might be at this point on this

transaction essentially. And as you said, when we had WAM products, web access management products, we could use a web agent or a, or a proxy as, as a place to do that enforcement. You know, we could check a certain URL, things like that. You can also do that with AP is as well.

API gateways can do the same sort of thing, which is how you might address it with single page apps that might be talking against APIs as opposed to sort of legacy sort of, you know, web interactions and stuff like that. So we can do adaptive auth on applications, SIM applications that are built and deployed by, you know, different, you know, by our customers, but much more difficult now to do it with SAS applications because we don't have the ability to do that

enforcement so easily. Essentially, you're kind of at the mercy of the the provider of that application, right, the service provider. Absolutely. So the one thing they've done is they've enabled, you know, single sign on, all right. So they've basically given you flexibility to control how authentication's done.

And we do that with things like SAML, you know, SAML mostly with SAS applications, but, and that allows you to sort of do adaptive authentication at login time because you control, you know, you, you control the login essentially as an organization. So you can basically make a, you know, a decision at that point based on different factors about what level of authentication you might want at login. But once the once the user is inside is is, you know post authentication interacting with

the SAS application directly. Very few SAS apps give you the controls the policy controls to allow you to make policy decisions at different points in the applications for. Different places, right? Anywhere other than the front door, right? Pretty well, yeah. So there's been, so there's there's been a sort of attempts

and efforts at that. So if you think, if you look at the what was called the Casby market, like the cloud access security brokers, I think they were called, they've acted as proxies in front of SAS applications. So you know, there's an element of, of of attempting to apply policy there. But that tends to be more, you know, sort of risk based where if they think there's this is a risky device now they might automatically push you out to

get you re authenticated. It doesn't allow you to do very easily do policy that says, all right, on this transaction type with this entitlement in this situation, this is, this is high risk. And I want you to

reauthenticate. Think, think of, think of the analogy to a banking application, all right, where like a, you know, we, we have a, we have a banking application and you know, they want to set policy that says, OK, if it's high risk, if it, you know, if I think the user's high risk, then reauthent, reauthenticate them, you know, adapt, you know, adapt the authentication. But they have other policies that says if this is a payment, all right, automatically re

authenticate them. Or if this is a payment and it's over $10,000, re authenticate them. So there's certain, you know, application transaction types that can get quite granular where they look, you know, that are considered a high risk. And and you know, not every organization is the same, not not every bank's the same, not every customer of sales force is the same in in their risk

profile. And that's where we've lost that level of customization on the risk policies that people might want to put in place, I would say. Yeah, yeah. And you're getting into an area that I really want to explore, but you've mentioned the earlier that got me thinking about, OK. So if the depth of authentication, it's hard to do it kind of that that next level which I always call that coarse grained authentication or coarse grained authorization. Right.

And it seems like this, you know, kind of SAML IDT model really works at like the resource being like the front door for the application, like you either have access or you don't have access. Maybe we're going to send some attributes in the payload, but for the most part, based on how you come in and you were talking about the device luxuriacy, but there's more context to it, right?

At least the kind of the way I conceptualize it in my head is you've got the the actor, which has a context. That could be the device, it could be where the person is coming from, it could be, you know, several different attributes about that actor and they're trying to access a resource. And at some level, I mean, and I don't know if it's just marketing buzz or if this is the way it really works is that the actor has a risk score via that score of like, you know, very low or very high.

However, it works and the resource has a risk score and as long as the resource matches or is better than the excuse me, if the actor is less risky than what's required to access the resource, they get right in, but if not they get challenged. Is that kind of the way it's working in like the modern actor or modern description for adaptive authentication? Really. Yes, somewhat.

I mean, I just think that with SAS apps, there's, there's, yeah, from what we see, there's just limited controls right now, I think. And and I don't think we can really apply the agent prop, the agent model or the proxy puddle very well. And it's also very difficult. I mean, we've externalized authentication from these SAS applications, but externalizing authorization is actually much,

much more difficult, All right. And the SAS applications themselves really don't want to do that as much as possible. But one of the one of the things the SAS applications have done is they've exposed APIs to allow you to programmatically control entitlements. All right, things that you're allowed to do. And that's something we never had on traditional on Prem applications like, you know, we never had that level of programmatic control where I can call an API to adjust the entitlements.

It used to be you had to go into the database and change them manually or go through some, you know, weird web console to do it and stuff like that. So what we can actually think about doing now as an alternative to this actually is to think about it as you know, you're standing privileges of what you can do in this SAS application are fairly limited and that you might be granted privileges to do certain things,

you know, for periods of time. So as I mentioned, quite often when you want to do adaptive auth, it might be on higher risk transactions like I want to download the financial data for the company or, you know, I want to approve a, a money transfer

of X, things like that. So you could actually think about this now to say, all right, maybe by default, I, I'm not allowed to do this and I have to request permission basically with a with, with basically just in time access where I rest request permission for this entitlement, it gets approved. And then I'm able to do this for some period of time, maybe 15 minutes, 20 minutes. And then it's then it's taken away from me basically.

So it's another way to think about how to control and limit risk essentially, which is what this is all about limiting risk on what people can do in these applications essentially. So it's just a slightly different approach, but. It works within the constructs of what SAS applications allow you to do right now essentially if they have this API based access to control entitlements. I want to get into the other scenario that you're talking about.

You were giving that banking example and you know, further, I can't really go back to my original example. Talking with this colleague, he actually wanted to do more than just protect this admin application.

You want to say, well, kind of take it to the next level and I'm going to make up an example that there's these workers from France and if somebody goes in and wants to access their account, that within the admin application, actually if they want they want to access their account or change their account, that's when we would kick him in the backroom. So in other words, we would trigger that risk score based on a an action and that action might be based on the data.

So it's kind of like, you know, if you're transferring 10,001 dollars, it gets flagged. If you're transferring 10,000, it doesn't, but it's based on the data and some kind of policy or rule set. Yep, that seems to me like

that's advanced fraud analytics. That's more than your typical IDP is going to achieve for you, right? There's there's some kind of additional system that is kind of examining that process, is that right?

Yeah. I mean, unless the application itself like a sales force, you know, I'm talking about workforce applications now, like a sales force or a service now or a work day, unless they build that in directly into their into their applications, you know it, you know, they're going to have to take those requests from customers and sort of add that

capability basically. And you know, not a lot of them are doing that where just because what, what is considered risk risky for different, you know, different customers is different. Basically the fact is that in this case it was France. France is a big deal. They've got to they won't have different policies because it's a French, it's a French user, non French user. That might not apply for other, you know, for other customers.

What but what I think can be done and what's evolving is standards that allow us to externalize policy from the SAS

applications. The SAS applications might make the policy decisions and, and, and the enforcement themselves, but the policy itself as opposed to actually, you know, creating it inside the admin console of Salesforce based on what they can do. There are opportunities to externalize that and use standards like emerging standards like Author's Ed or ZED or Zen or Zen, I should say.

Also. Zen yes, as a as a, as a mechanism to build those policies externally and then, you know, push them into the applications essentially so that that starts to give you the flexibility of all right, different, you know, different policies can be written by different customers, but they can be enforced by the applications and enforced locally basically in this situation and that gives you more flexibility. So the application winds up reaching out to this external

process. I was wondering if there's actually like some kind of proxy that data would. I would, I would, I would say it's working the other way. One of the things that when you, when you talk about centralizing authorization is that if you think of there's policy enforcement and policy decisioning and you know, basically those things generally need to work very fast. All right, You can't, you can't be calling out over the Internet for every policy decision to be made.

You can't be phoning home like Salesforce can't call back to their customer for every policy decision to be made. Essentially, it's, it's just too slow. So policy enforcement decisioning have to be very local, but the policy itself that's going to be used in the in the policy decision engine, it can be pushed in so it can be administered somewhere else and then pushed in.

So that it basically is, you know the policy decisions running locally and that that addresses the performance concerns which a lot of these SAS applications are going to have in in these situations. So I guess that's the benefit of standard, right? Is that absolutely yes, all the applications can kind of subscribe to the same standard and you get greater adoption of this model. Yep, yes, I mean that. And again, this is this is not available now, this is still early.

This is some of the evolution of all of Zen and where it, you know, where it's sort of going to, but it's to enable some of these use cases where, you know, a policy can be developed, you know, and controlled by a, you know, a customer organization and pushed into lots of different SAS applications. So they all you know, so you all have individually different policy that you can use in those situations.

I'm kind of getting the sense from this conversation that it's really like the the benefit of a SAS application is that it's easy to get integrated with initially. You can provide the services and a pretty good level of security, at least from an authentication standpoint by integrating into your IDP. The downside is that if you want to get real fine grain, you know, there's only so much that you can do. So that's kind of where I

summarize where we are so far. But something that's in the back of my head is also, you've got SAML to as the methodology to integrate, you've got Open ID Connect. And I'm wondering if there is, if the ability to handle authorization is part of the reason why you would choose one

over the other. Is there a major advantage to integrating with Open ID Connect versus SAML when it comes to this whole topic that we're talking about and being able to either Dr. Adaptive authentication or, you know, have more control over authorization? So this, so it's interesting, I think it's, it's, it's interesting how SAML has become sort of the, the de facto default SSO standard for enterprise SAS applications.

And that was originally driven by Google and Salesforce adopting it back in, I don't know, almost 20 years ago. And generally speaking, most SAS vendors now kind of adopt that by default because they know that most of their customers are going to have a SAML IDP capability. But there hasn't really been much innovation happening in SAML for the last 1015 plus years. It kind of works. It does it's thing where where we are starting to see innovation still is in the Oauth

and Open ID Connect world. And even though I'd say today Open ID Connect doesn't offer any major advantages, probably the, the one major one is it's kind of easier to set up and configure and you, you can avoid some of the complexity around certificate management and stuff like that because it can be more dynamic in it's nature that, you know, some of the innovation emerging there. Well, any innovation we do is

going to emerge in those areas. So I, you know, that's why I believe all the Zen is actually part of the is happening within the constructs of the Open ID Foundation. All right, so it's close. It's going to be closer to Open ID Connect than ever. It's going to be the SAML. So definitely as we evolve to some of these newer protocols to address problems, you know existing problems, they're all happening in that open ID connect oriented world.

I don't think there's ever going to be a pre req that you need open ID connect, but it it's all happening there and I think will evolve there over time. And you know, most generally speaking, any customer today that has a IDP that supports SAML, that IDP is also going to support Open ID Connect as well. So it's not like it's it's more the SAS vendors themselves choosing to build something beyond SAML, given that that's

been the default for so long. So it's the advantage that there are today, but it's also where everything is heading, or I shouldn't say where everything is heading, but if you're expecting innovation, especially like things to do with Austin, any kind of let me just make city easily where things are heading. If you have the choice between

Samuel and OIDC, choose OIDCI. Think you made the point earlier though that you know, if you look at a basket of size applications, it's more than likely that the majority supporters, Samuel, they're still, I always find it like amazing and there's an enterprise grade application that doesn't even support SAML or that they they charge the

integrate via SAML. And that I was going to, I was going to mention that there's two things actually. So one thing with we've seen over the last few years is that, you know, a lot of a lot of large organizations still have a lot of, I'll call them on premise applications or applications that might be now deployed in, in their, in their cloud infrastructure, basically as cloud native, like running in that customer's AWS environment or GCP environment or Azure

environment. So, you know, I'll just say it's a, it's a derivative of on Prem. It just happens to be in their cloud. They still want single sign on to those applications. And actually what we've seen there is, you know, 15 years ago, 10-15 years ago, they might have used a web access management product.

They've actually instead now shifted over to support Open ID Connect. So you're seeing Open ID Connect used for those sort of on Prem cloud native applications that the enterprise is using, but it's quite often SAML for the SAS applications. So I could definitely see SAS applications evolving to Open ID Connect as well, just to make it consistent across the organization actually. Do you find? That do.

You find that the level of refer to. Let's say, you know, you had some application that 10-15 years ago you wanted to quote UN quote webify and you had a consulting firm come in. They they filled this app. It's not integrated even with SAML, but now's the time. It's like maybe you have it behind a reverse proxy, but you say it's not going anywhere. You want to get reverse proxy out of your environment and you say OK well I could convert it

to SAML or OIDC. Is there a significant difference in the amount of effort to do one over the other and is that driving developers decisions a lot of times?

Yeah, I think, I mean, traditionally, you know, you know, we learned a lot from SAML. The Open ID connect is definitely a lot simpler. Just you know, because we learn a lot from, you know, you know, there were certain mistakes and things we did in SAML that, you know, we chose to fix an Open ID connect.

And actually now with with open ID connect, there are servers and even, you know, web agent plug insurance and and proxy plug insurance like nginx plug insurance to and you know, open ID connect enable your applications. Like a guy that used to work for me, Hans, you know, built, built the Apache, you know, you know, the Apache and the nginx mod open ID connect as a, as a plug into Apache that you can basically use to open ID connect your applications.

So it's a, it's a lot, you know, it's, it's, it's a lot, lot lower barrier to entry to have your application support those protocols right now. So there's really no reason they shouldn't, essentially. Yeah, absolutely.

I want to go back to your. I want to go back to your point though, about SAS applications now charging for SAML and what, what, what completely freaks, you know, freaks me out here is that I've, I've heard more, yeah, more and more SAS vendors are charging for their enterprise grade features. I'll say that you've got to pay extra for them.

And those enterprise gauge features include SAML single sign on. But now there's, you know, you know, companies emerging that are saying, Hey, we, you know, you can, we'll give you single sign on to your SAS applications, but but do it in a way that you don't have to pay the SAS vendors to support it. And the way they're solving this is actually through password vaulting, all right, which is basically goes back to what we were doing 20 years ago in, in

terms of password vaulting people to get access to these applications. We've now gone back to it because people don't, don't want to have to pay for single sign on anymore through things like SAML and stuff like that. So it's kind of, I don't know, kind of annoying anyway. There's a website called SSO dot tax. It's kind of the single sign on Wall of Shame. OK, I hadn't actually even heard of that. That's interesting. I've got to go check that out.

But yeah, this is like it. You know, you try and do the right thing and, you know, capitalism gets in the way. I'll say that. So, Patrick, in the future, you

know, you keep hearing about these AI agents and they're going to play a pretty heavy role in terms of how we get our work done. And I think adaptive authentication winds up playing a role in that because we wind up delegating work to them, right? So they're authenticating on our part.

They're essentially, you know, pretending they're us or getting work done for us. And obviously, there's the potential that they will be seen as robots, bad code, malicious code, whatever you want to call it. Let's keep the basic and first start with this concept of AI agents. What are AI agents? And then feel free to kind of go off on what I just said, whether I was right or wrong, You know, how does this topic of adaptive authentication fraud prevention play into, you know, this AI

agent future? Sure.

So, but we've been thinking a lot about AI agents over the last probably 12 months and the impact they're going to have and the impact's going to be huge. And I don't think people quite understand yet how big an impact they're going to have. Honestly, the, you know, we kind of didn't touch on it earlier, but you know, one of the key points about adaptive oath is the fact that, you know, it might not be policy based, it

might be risk based. If you get a risk score back from your fraud system, you might choose to adjust how you authenticate. That's a really traditional sort of model. And those frisk and fraud systems quite often are looking to detect bots and stuff like that to prevent ATATO attacks and things like that.

So then, you know, as we evolve into, you know, the notion of AI agents, you know, think of, you know, to me, AI agents are different because they are processes that can actually, you know, reason and dynamically change over time.

So unlike a traditional computer process where you have a certain set of inputs and you, you know, you know, you're going to get the same outputs every time, AI agents evolve and the input, you know, you know, the inputs one day will drive different outputs over time as they, you know, as they dynamically learn, you know, they reason, you know, they, they just, they get smarter over time, stuff like that. So a lot, a lot changes with the way you think about an AI agent.

So AI agents are going to sort of appear in a couple of different ways. Where I think it gets interesting is when AI, an AI agent can actually interact with a gooey, like the gooey that's on your on your laptop and it appears like a human. All right. I mean, this is like what the operator operator tool from open AI does. It'll literally drives the browser and it does that while it actually, you know, basically, you know, tries to complete a, a task or a set of

tasks. So now if you can imagine you've got AAI agent on your desktop that's basically looking to do things automatically add things to your calendar, automatically update Salesforce with certain data that you got thick that that's, that's workforce examples in consumer examples, it could be automatically search across 3 websites looking for a cheap pair of jeans and then buy those jeans, stuff like that.

Whatever it might be. We now have to basically, you know, AI agents are going to see, you know, be used. How do websites differentiate an AI agent from a bot? All right, where traditionally we've thought of bots to be bad. So we have to have ways to basically distinguish an AI agent from a bot. And then we have to have ways for that AI agent to be able to authenticate through that website, all right, such that it can do things on behalf of the

user. One of the, you know, one of the, you know, and obviously adaptive fits into this in many ways because we're going to adapt basically understanding whether this is a bot or, I'm sorry, an agent or a human. And if it's an agent, we want to handle authentication differently, things like that. The in the case where the AI agent now needs to authenticate, the last thing we want to do is have the AI agent essentially impersonate the user.

And by that I mean just use the credentials that the user generally uses. So I don't want the AI agent to basically just take my ID and password and log in as me.

All right, What what we're creating at that point is essentially what's what, you know, what we, what a lot of the in the banking world, the Yodelies and the mints have the world did when they did screen scraping to basically use my banking credentials and log into the bank, screen scrape stuff and return it. The banks hated that.

And you know, there's all sorts of security risks associated with that and AI agents, if we don't fix this or address this and just going to do this, you know, 10 orders of magnitude more, it's going to happen everywhere.

So what we really need to, you know, address or push for is the notion of delegation. All right, by Patrick and going to delegate this AI agent to go do this on my behalf. So that means applications that want to be kind of agent aware need to sort of support this notion of delegation where, you know, I can delegate responsibility to this agent acting on my behalf to do things basically. And you know, the agent still has to authenticate itself, but

it can do that. You know, we, we can start to do that in ways that doesn't require, you know, similar to the ways we might have done this with sort of traditional Oauth and stuff like that where you, you consent to an Oauth client to act on my behalf to do things, things like that basically. So that's what.

We're going to evolve to yes. I mean, you think, think about the way you talked about there with so, so the security problem is systems that are meant to detect bots, while the AI agents are bots if they're doing their job by saying you can't proceed, but they're good bots. So now the question is, how do you tell the good bots from the bad bots?

So we're, we're actually looking at, we're actually looking at ways where a website can advertise and, and, and, and let AAI agent know that, hey, if you're an AI agent, go do this, all right. And it basically, you know, it's kind of lets the AI, it tells the AI agent what to do essentially. And it would be distinct from what a human would be doing if they're interacting with the

website in that way as well. So it, it's, it's challenging and actually it's going to force a lot, a lot of organizations to have to update the way and how they sort of they think about interacting with these things basically to support this if they want to, you know, if they want to take advantage of it. Yeah, I heard one of these quote, you know, quote UN quote

outlandish statements. What will be the first one person company worth a billion dollars, you know, and the idea is you could have agents or bots running your entire company. You can imagine actually the example that you bought or you brought up, which is you go out, look for the cheapest pair of jeans. Now say you're doing that on a wholesale level, you're buying them. Maybe you're warehousing virtually and you're shipping

virtually. So you're taking orders online and you're just moving these items and taking payments and your whole company is basically bots. Yes. Well, the, so the other example here is, you know, I gave an example of where a user is kind of, you know, bringing in their own agent and it's, and it's

going to do work on my behalf. But there are also examples of agents that are being created that are kind of more autonomous and they're acting as kind of digital workers where they're autonomous off basically independently doing things, you know, for an organization. And there might be 10s of thousands, hundreds of thousands of these digital workers that

are going off performing tasks. Those agents likely are going to need identities of their own, because to me, they're no different to a human user, especially if they're interacting with systems that humans interact with. And now the digital worker, that agent is a digital worker is doing it instead. Those applications are going to have to actually know, all right, this digital worker has an identity. It's going to authenticate to me, all right? It's going to be given a set of

entitlements to do things. It's going to, you know, the entitlements and, and it's identity is going to have to be this life cycle of management around that. It's going to have to be, you know, granted and taken away. Access is going to have to be approved.

It it's going to act very similar to the way we think about kind of IGA today for human users and what they can do. But we're going to apply it at massive scale for, for these, you know, you know, digital workers that are, they're essentially just AI agents in these situations. So there's, there's a whole other class of stuff that's happening there sort of inside the organization as well in terms of what's happening too. So, you know, again, it's, it's, it's, it's all coming.

And I know a lot of people are thinking about this and talking about this, but I think it's going to come a lot faster than we than we might imagine actually.

So do people wind up being replaced by the AI agents in the end to do we serve any purpose if the AI agents can do it all themselves? I know it. It almost seems like a silly question, but people brought it up a long time ago. And every once in a while you hear somebody say I'm not going to have a job in two or three years because this does all the you know, you look at like say the copilot assistant or the transcriber in the teams meeting. Now you don't need anybody to

keep notes. In fact, usually the notes that you're going to get from the teams that you are way better than a person could keep anyway. So I, I, I mean, I've been thinking about this a lot and I, I think this boils down to efficiency, all right there that we are going to make people, people are going to become much more efficient in what they do if they have access to these AI agents to essentially do you know, the repetitive stuff effectively that we've done,

done before. And I'm not saying that AI agents won't require at least for some period of time, sort of a human in the loop before we, we're ready to actually just give them full autonomy. I, I imagine that humans are going to be in the loop approving things that an AI agent sort of says, does Axon creates whatever that that'll exist for a while. So I, you know, that that doesn't go away, But I, I think people, they just become more

efficient. And I don't think it's any different to when, you know, the personal computer emerged and everybody thought the personal computer was going to replace all sorts of, you know, roles and jobs and stuff like that. The stenographer, the, you know, the, the typing pool, the, you know, whatever it might have been, yes, you know, they get replaced. But I still think there's, you know, it's not like there's all these people out of work.

People's skills evolved. People learn how to use these things. They'll become more efficient. They've got to embrace it and go with the times sort of thing in that regard. Yeah, I, I feel the same way. It's like you can't prevent progress, right? The progress is going to happen. So you have to position yourself on the right side of it. You don't want to be the person who's constantly falling behind, like the person who went around and lit all the street lights before there were Electro

lights. If they they stuck to it and maybe they were lighting the last few. Eventually they have new skills for the future. I'd say, look, you know, this is something that Andre has shared with me multiple times over the years. Andre, the CEO of, of King, that organ, you know, capitalism, you know, and, and you know, and organizations are hyper focused on that they will find and drive efficiency, you know, constantly or good organizations will, you know, and capitalism drives

efficiency. Basically everybody's looking to do things faster, cheaper, better all the time. All right? And it, it's constantly moving in that direction, I say, and this is just the most recent example of it. I think that we're going to see

so. Yeah. What is your question, Patrick? If you were, if you had a son or daughter who was in college, what would you tell them to learn right now? And and don't tell me art history, because that's cheating. So yeah, what? You know what's interesting? I've got like I've asked this, a couple of people have ping as well. And so it the, the one thing that none of my kids have gone into which I went into was computer science. So my kids didn't go into

computer science. One of them is doing pre Med. My oldest son that graduated, you know, did actually business and data analytics are my youngest sons doing kind of business and doesn't really know yet. So I, I'm actually, you know, to me, honestly, learning the business side of things gives you the opportunity to understand how to run a business, how to build a business, be a little bit more entrepreneurial, all right, because you understand how businesses function.

And I still think that's going to be necessary. People who understand how to operate and run a business is always going to be needed, irrespective of what that business is. And I think that's just a great set of skills to have. I, I'm more way more concerned if I was, you know, about going into computer science now, because I, I mean, I was a software developer and I wasn't a very good software developer, perfectly willing to admit it,

all right. And I don't think I would survive through what it means to be a developer now, given how much more efficient developers can be made using things like now what's it called, you know, tow pilot and stuff like that, that the. If you're a lazy developer, you could you might be able to get by right? You figure out all the ways to get. Yeah, but I, I all. Your work is done by doing

nothing. That's true, but I just think the number of, I mean, again, efficiency is going to drive that, you know, developers are going to become more efficient and therefore we're not going to need as many developers to to, you know, develop the code. And the other thing is, look, I mean, what's a developer really doing? A developer is translating business analyst type requirements into a language that a machine understands.

If I can now just use natural language to tell the machine what I want to happen, do I really need that post in the middle that's turning, you know, those requirements into code? I can just give the machine, you know, I can just give the, you

know, the AI the requirements. So now becomes sort of more a case of, all right, maybe people should be learning about prompt engineering and understanding how to actually define these requirements in a way that the AI can use it to actually build the applications itself essentially. So it just becomes a different language you have to learn essentially to be able to, you know, develop the applications that people want to. Use.

Yeah, I've been encouraging my son to do the prompt engineering and really get good at that. He's a little sophomore in a cybersecurity degree program, and I wouldn't say he's a lot of a tinkerer. He was a tinkerer. You know, early in his years he was setting up his own PC for doing video games and trying to figure out how to, you know, get the fancy sorting in his game without actually doing the work.

So, but I would love to see him tinker with getting the open source code and seeing what he could do, seeing what kind of data sources he could plug it into and figure out how it works, because I think that's the skill that businesses are going to be very hungry for. Yeah, absolutely. And I don't think that, you know, I talked to him about, like, are they teaching you this in school?

And he's like, no. And I believe him because I, I remember going out in his when he was, you know, looking for colleges and asking questions about things such as that, such as cloud computing. And it's like these professors, they were behind where we are even in, in the business world. And I was like, man, oh man, I can't believe you guys aren't like on the cutting edge of this stuff. Maybe it's just the schools we were looking at. I don't know. Yeah, that's a problem, I agree.

But yes, I think, you know, learning and understanding how to translate, you know, so, and this gets back to the business side of things. It's like being able to translate the business requirements instead of actually into code as we know it, But into, you know, to to to basically tell an AI what it what you need. I think is the where this evolves to over time

essentially. There'll still be need for hardcore developers obviously, but I just think a lot of organizations aren't going to need as many of them you know it'll be. It'll look very different in 10 years time as an example. Oh yeah, for sure. Patrick, you've been super generous of your time. We had a great conversation today. I know you're out there on LinkedIn, so I sent you an

invite to get connected. I don't know how you are connected given you're on the show before, but I'm sure other people after the show will be sending you invites. I already get a number of invites per day and I love it. I want to talk to all of our listeners and get to know you all. And a great way to get to know people is through the conferences mention we've got discount codes for EIC and Identiver, so please make sure to take advantage of those. And Patrick, I'd like to go out

today with a a lighter note question. Given those two conferences, EIC in Berlin and Identiverse in Vegas, what are your tips for each of those to do's for whether it's a first time conference goer or maybe somebody's been there a few times, they've got any like secret Nuggets for each one of those? I, I've spent a lot more time at, at Anniversa over the years than EIC, so I'll sort of focus on that.

It's, it's honestly you, you got to get it outside your comfort zone and just engage and talk to people and you know, you know, at whether it's at, you know, might be a lunch or a breakfast, you know, sit down at a table where you don't know anybody, start talking to people. Everybody starts in the same situation where, you know, they don't know a lot of people in the community. But I've always found the identity community to be very open and embracing of new people

and old timers essentially. So you know, that to me is, is the key here. You know, everybody, everybody was in your place at some point in their career and felt the same way. So, you know, don't be afraid just to open up and reach out and ask questions and introduce yourself and stuff like that. Essentially is the is the key. The same thing applies in the EIC as well with with Martin and those guys too. So, you know, I would say the

same thing there as well. Yeah, this seemed to be my first time in the EIC. I've been to Germany before, but never Berlin. I hear that, you know, it's a very lively city. Of course, there's a lot of history there, a lot of places to check out like the Berlin Wall and you know, I mean, heck, I'm not going to do as good of a job. If you're interested in looking for sites to see YouTube, Google, there's tons of information out there. I have actually been to Las

Vegas probably 20 or more times. I my biggest pro tip is to pace yourself. I mean, especially if you're somebody who likes to have a good time, you get to Vegas. If it's your first time in Vegas and all those lights are on and you go into, you know, go through the casino, they just have a way with all the bells and the lights and they pump extra oxygen into the room, makes you feel energized and you

should enjoy that. My recommendation with my my recommendation with Vegas is don't end up inside for three days like I have a couple of times. Get out and get some fresh air in the middle of it if you can, because you know, I, I've, I've inadvertently spent three days indoors in Vegas and never saw the sun. So. Yes, that's that's good advice. I've I've never done the whole 3 days indoors, even though Jeff has told me he's done that a few times.

I'm not like a when I was a kid I wanted to be outside around the clock, but you know, as I've gotten older, found lazier about it. But I think for a certain amount of time, I'd just go stir crazy in indoors and and but here. So my advice is pace yourself. Don't try to have all your fun fun upfront. You know, a little bit at a time. There's a lot of like after hour parties, but that doesn't have mean you have to be out until midnight every night because the shows you know, take place in

the morning. Get off to a fresh start, have breakfast, get in there, be mentally aware, engage. Try also to break away from work for a little bit because yes, I know, I understand. And I've fallen into this trap many times over the years where you're right in the middle of like a hectic project. But if you travel all the way out from Las Vegas and you go to two, two of the sessions or something like that, you're really going to regret it.

You've got to try to find a way to get up early, do your call, maybe save some of the calls till later today. Maybe take a break in the middle, but make sure you're going to a number of the sessions otherwise you're going to end up being disappointed in the end. Yep, good advice. Yeah. So that's what I've got for you for this time, Patrick. Again, thanks for joining us. For everybody out there, find us on the web idacpodcast.com and our YouTube channel is

idacpodcast.tv. That'll drop you right into our YouTube. Again, love hearing from everybody on LinkedIn, so find us there. And thanks again, Patrick. Until next time, everyone. Thanks, Jim. Bye. 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.