AI Rewrites the Rules of B2B Identity Access

Hello, everybody. Welcome to our webinar today. I'm John Tolbert, Director of Cybersecurity Research here at KuppingerCole, and today I'm joined by Jacob Ideskog from Curity. Hi.

Hi, Jacob. Great to be here.

Well, today we're going to talk about how AI rewrites the rules of B2B identity access. So, a few logistical things up front here. Everybody's muted centrally, so there's no need to mute or unmute yourself. We're going to do a couple of polls while we're having our chat today, and we'll talk about the results at the end. There's also a Q&A session, and you'll notice on your browser here there's a blank for questions, so we encourage you to enter questions at any time, and we'll take them at the end.

And we're recording this, and both the recording and our brief slide deck will be available in the next couple of days. So, I thought maybe it would be a good place to start just by sort of level setting what we mean by AI. I think it's a term that gets overused or genericized maybe a little bit too much you know, especially in popular public opinion. We hear everybody talking about AI on the news. We see a lot of messages in marketing about AI. I think there's maybe some conflation of AI and even AGI, artificial general intelligence, and of course we're not there yet.

But I think it's good to be clear about the different forms of AI that are in use today, and then later we'll talk about what they're used for. Yeah, I mean the term itself is almost becoming synonymous with Gen AI, which obviously is not the case. You can see the AI stamp on a lot of things. Like you say, they've been around for a long time. Machine learning is not new, as everyone knows. We're marketing it better now, perhaps getting more use out of it, and so on.

But it's good to keep this definition separate because it also helps us when we want to understand where could it be transformative. Because in some areas, as we'll see later, it's been around and it's been transformative to some extent, or at least quite useful. Whereas Gen AI has not had an impact and in other places, machine learning has not been possible, and Gen AI is the only thing that could improve the state as it is.

Yeah, the theories behind AI and particularly machine learning have been around for many decades. And the big leaps have come in hardware capacity that enable us to use different kinds of machine learning algorithms at scale today. So we've seen unsupervised AI for looking for anomalies in huge data sets. Supervised ML can be used to classify those anomalies. Then there's deep learning, which is a more advanced way of combining the two.

And LLMs, we've got LLMs, which are a form of generative AI. And I think that's what's really gripped both the public imagination as well as investment.

Yeah, for sure. And it's easy when looking at the trend right now, it's everywhere and it happens. The pace is high. So it's easy to think that the sky's the limit here and everything will keep up with this pace at all times. But we don't know. We don't know that. We don't know the limitations of the current Gen AI tech, essentially. How far can it go? We could build bigger and better and stronger, but can it become really intelligent or solve really complicated things? We'll see.

But right now, we have to work what we have and understand that, because that's hard enough, actually, especially in the security world, as we'll discuss further today. But all in all, the proliferation and use of this is something that we need to be really aware of. Whether we're using it or not, when our companies are platforms, you tend to be used by other systems and those other systems will be agents, if they're not already. So you need to prepare for that.

Yeah, and it seems like there's an expectation that AI in one form or another is going to be put into every software product. And I think we're still, even though it's been around for a while, still sort of in the experimentation phase to see how useful LLMs are, for example, in different kinds of software products. But they're here and more are coming.

Yeah, exactly. I mean, the last year, I mean, any company you've looked at, the sort of roadmap or new features are one way or another AI, whether it's useful or not. Doesn't necessarily have to be useful. That's for the future to tell. But obviously, natural language in itself is a very good way to be thinking about or configuring systems and understanding data and so on, because it fits us, obviously, as humans. So just simply from a UX perspective, AI will probably transform quite a lot for us in the event.

Yeah, at its core, LLM is text prediction and text understanding to a degree. But there's also quality checks that need to be involved, too. And we'll dive into that a little bit more in the next few minutes.

Yeah, yeah. When you break it down, it's interesting like that. It's a predictive engine for what's the next word, but a smart one at that, for sure.

Yeah, I think a lot of powers are ascribed to it that maybe aren't necessarily quite there yet, because it is text prediction. That's why I think there's a lot of experimental and production use of LLMs for code generation.

Yeah, which obviously, if we're talking risks, we've already seen. The things we've been working so hard the last 10 years to make sure people don't put credentials in their code base or check in sensitive details that shouldn't be even in the Git repository ever, that's coming back. We have to re-learn and reset the rules again, which is, I would say funny, but it's also not funny at the same time. But as a whole, it's brought up some light, if I mention on this slide, the term non-human identity.

And it's been interesting from my perspective, because it's something we've been working on curatively for the last 10 years. Obviously, non-human identities, we just haven't called it that. There's been many names I could list it out here of machines talking to other machines or machines doing tasks. In my world, in the identity and access management for consumer facing or externally facing applications, it's typically things that talk to APIs in one way or another, whether it's web APIs or other APIs, but it's things.

And it could be internally two systems just talking to each other or externally a mobile app doing something or something. But the non-human aspect has been there all the time. And I think this slide is a very good reminder of that, that these type of identities aren't new, but the last sort of bold piece here is, because it's also autonomous and non-deterministic, which I would say is new in this state. Yeah. The ones that jump out to me are the old ones, like service accounts. They've been around for decades. If you're running a piece of software, often it has to have a service account.

And we've had ways of dealing with those from a security perspective for just as long in the privileged access management, for example. But think back over the last 10 plus years about the craze around IoT device management.

Well, now device management machine identities are a subcategory that now falls under NHIs. So NHI, I think, can be a scary term in a way because it encompasses so many different things. And it feels like, oh, this is something brand new that we've got to deal with. But many of these have been around for a long time. But you're right, the idea of AI agents operating on behalf of human users is something different. And it will require us to think in different ways and develop new tools to be able to identify them and then properly handle them within our IAM systems. Yeah.

There's a classification or a taxonomy problem that we're starting to see materialize a little bit because in the external face and identity space, we always thought about three parts. We had the user, we had the application needing some sort of access, and then we had the resource or the API. But the resource is not necessarily so interesting as the access. So if we remove the resource, it's like the user, the application and the access. Those are the three things that really matter and that you typically govern. You don't necessarily govern the endpoint.

You do because you have a gateway and you have catalogs and things around that. But the access is what matters. And what provides the access are those two other parts, the application or the client and the user in combination. And when we've talked about non-human identities before, the user hasn't been there, so the client and the user has been the same thing. But as we start talking about agentic access, that question remains to be answered. Are they the same thing or not? Are we adding some sort of non-human user here to act on behalf of some company or some organization or some other user?

Or are we treating this as a full application on its own, like we did treat other applications before? TBD on that one, I'd say. But we need to just decide. I don't think it changes a whole lot from the security posture perspective, but it does change things from a governance perspective a little bit.

Yeah, I think maybe in terminology semantics here is where some of the innovation has come from is just realizing that there are lots of different kinds of identities out there. Our IAM systems are full of them and have been full of them for a long time, whether it's devices or now workloads and containers, things like that. But most enterprises report they've got probably more NHIs than identities that relate to actual human users at this point.

Yeah, yeah. And I thought it was interesting that you added the secrets, API keys, tokens, certificates and so on in the beginning here, as they are really the identifiers or the authentication mechanisms or the carriers of information that identifies a non-human or a human sometimes to the system and are the carrier of that information. Because that I think still holds true for agentic AI.

I mean, we still need the mechanisms to communicate identity. And we have a bunch of mechanisms.

I mean, the token-based architecture, which we'll probably come back to a few times today, is about getting all those systems working together uniformly with a singular point of trust or at least a few points of trust that allows them to present themselves to other entities in that ecosystem. Closed or open, doesn't matter, right? But that contract and how to convey that information, how to prove yourself to the central system and how to convey that identity proof to other systems, that's still relevant.

And if you take an agent and break that down a little bit, it's also easy to just talk about an agent as one thing. But it's really sometimes quite a big application.

I mean, you have one or many models, typically many. You have the tools that it needs to access, which could be local or it could be MCP APIs that it uses. And there could be, there's all these things that comprises this. So the agent itself is almost a small, can be a small ecosystem of these things that actually also need to identify the identities even if you want to go into the rabbit hole. But it's still just an application in that sense, following those principles.

Yeah, I mean, I think that's one reason I wanted to start off with things like API keys, token certificates, is they're representations of an identity. So yeah, they're authentication mechanisms, they're also representations, but they're also things that we've been working with for many years. So it's just different use cases with many of the same mechanisms. One thing though, that also sort of stands out a bit is lately, not only because of AI, absolutely not only because of AI, but I think AI accelerates this a bit. That is the sort of mere explosion of these to manage.

The more of these small applications you had, you already mentioned, you have more non-human identities than identities out there. That also means there's a lot of credentials to manage. There's a lot of systems that need either certificates, keys, secrets, or the flavor you pick, or the thing that works for that particular system. And that itself is something you can't overlook when you start building even more and throwing AI in the mix.

And in the workload space, obviously, that's where there's new standards popping up, like the Wimsy working group is working on in IETF to ensure that you can use platform assertions or attestations to identify these systems towards something like an OAuth server to get tokens, so that you don't have to spread out credentials and manage credentials for just a growing number of machines or machine systems. Machines is probably the wrong word, but you know what I mean. Yeah.

And as identifiers and credentials, the differences in them can be useful for distinguishing between, let's say, the human part of human in the loop, a concept we'll go back to in a few minutes, as opposed to the agent itself. So, again, I think this is a point where IAM systems need to have additional sophistication in order to be able to distinguish the human user from an agent.

Yeah, I agree on that. So, I thought maybe we'd look at some of the kinds of agents that are already out there in use, in production today. I think we've all probably encountered chatbots of one kind or another, general purpose conversational AI agents, help desk password resets. But then there are agents that are embedded in procurement systems, things like financial analysis, document processing. We're not at the point where these things are theoretical. They're already in use by many enterprises today.

And I think the fundamental challenge that we face as identity and security practitioners is, how do we make sure that their permissions, their entitlements, their abilities to access and do things via APIs are properly constrained? What's been your experience on AI agents so far?

I think it's a broader question even, because if we look at the trends that this is showing, is that even in a large corporation where you just have 100,000 employees and as many contractors or others accessing your system, there's a question starting to be needed to be asked is, are all of those to be treated as internal or external identities? And once you start throwing all of these agents into the mix, that question gets really interesting. Are we fundamentally looking at this as a workforce problem?

We're bringing in agents as workforce employees, quote, unquote, or should we start looking at the entire organization as, well, it's an external type problem where we have outside in a lot. And more and more of the systems that need access to our internal data through APIs or direct access to databases or however things are done are built in-house or procured and specialized to that.

Together, this tells me that there used to be a pretty firm split. We had the workforce and the IGA and the PAM and all of that trying to govern how we deal things internally. And then we have the external facing stuff where my company is operating on SIAM and B2B type access where outside in and accessing the platform as such. But that gradient or that line is blurring out a gradient and the color of that gradient is shifting. It's going away from workforce and we have a lot more now to think about of how things are coming in.

Even though we bought it, we treat it as an internal thing, but can we really? Does that model really fit or should we mentally flip that and start thinking about this? How do we think of access if nothing is internal? Because that can make it at least conceptually easier or the mental model can become easier. Then you have all the variants of this anyway. But because what you will end up with here is a huge shadow IT structure if you don't take control of this.

I mean, any employee can connect their account if everything isn't locked down, which I bet you it isn't. Can connect their account to some cloud agent or whatever. It doesn't matter. Something they find that can work with standards and integrate and do the work for them or help them in their work or enable something in their browser or enable something in their inbox tool or what have you. And that makes this not so much a sort of in-house problem, but a complete problem for all the identities in the organization.

So I think we're looking at a pretty scary situation ahead where we don't know what is connected to what. And this problem obviously existed before. If you connected your Jira system to some other thing and it started to export data from there and publishing it elsewhere, that was a problem. Your data got leaked, but that was still some intent behind. Now there could be, it's undeterministic. You don't know how the intent of the agent will change over time. You don't know who connected to what. So control is critical here.

And as such, if you haven't built the foundation of your API structure, your application structure internally with how access is controlled on those, we talk about a token-based architecture a lot. I mean, using OAuth to send tokens back and forth or OpenID when speaking with applications or SAML for that matter, for SSO and those types of things.

If you haven't laid that foundation yet, I mean, it's urgent because otherwise you're not going to be able to also take that the next step, add the relevant security mechanisms on top that you might need in order to lock some of these things down or at least get a good sense of who's accessing what. Yeah, I think there's a lot of good info there in what you said.

I mean, let's go back to shadow IT. I've seen the term a lot, shadow AI. Many organizations probably aren't aware of the actual usage of Gen AI products that their employees are making right now. And the one that jumps off the page most to me here would be like procurement agent software and managing the delegation there. Now I can see there's a lot of room for efficiency and improvement if you have an agent that your procurement staff can use to, let's say, keep an eye on five suppliers and buy things when the prices are at their lowest.

But I think proper delegation and then again involving human in the loop on making high value transactions is going to be essential. But again, to get to that point, we need to know what the users are using and what capabilities they have to delegate their authorities as procurement agents to an AI agent. So there's risks there that not everybody probably has considered carefully enough.

No, exactly. And then it comes down to what I started off by saying about the user, the application and the access.

I mean, if you haven't defined your access model in a proper way or in a way that fits external access or other systems asking for access, it's going to be either wide open or shut. And shut obviously isn't going to cut it. And wide open, well, that's not going to work in the long run. So you need that sort of model in there, however you define it, so that you can also decide on which parts of that require humans to do something. Like where's the limit? Where do you need human interaction, human in the loop?

Just like we did with supervisor approval or things like that, it's similar, but it needs to be more protocol based. You can't have it as a process anymore only or a process tool, because that's not going to cut it. It needs to be a protocol that becomes automated so that this can work with machine to machine and just call out to the human in the middle. Exactly. So now that we've talked about AI agents a little bit, we're curious to find out where you are in the journey. Is your organization using AI agents yet?

You know, we'll see five choices here. No, we're thinking about it. We've just started using it.

No, we've already implemented it or, you know, it's perfectly fair to say, you know, I'm not really certain what's going on with AI agents in my enterprise. So feel free to answer that and we'll discuss the results at the end here. So now we've kind of established we are using AI in different areas around IT, I thought it might be interesting to kind of dive into what are we doing with it in IAM today? And I tried to delineate, you know, usage of ML versus LLMs here with different colors.

But, you know, things like ML for anomaly detection, I hinted at that earlier. That's been in use for a long time in, let's say, cybersecurity, for example, with trying to sort through the literally millions of malware variants that are out there. There's not enough human analysts to look at every piece of malicious code or suspicious code and determine whether or not it's malicious. So machine learning has been very, very useful for finding anomalies and then classifying them. And the same thing is true for behavioral analysis.

So if you have log files that are full of, you know, access attempts, you know, there can be too much of it to have human investigators sit down and really decide which ones are spurious and don't need your attention and which ones might indicate that, you know, that a threat actor is present in your environment. So machine learning has been a staple. Go ahead. Sorry. Yeah.

No, AI or ML in this case has been also interesting because it's very good at finding patterns that typically you wouldn't find. I mean, as humans, you wouldn't think about that these are patterns. When we see these things correlated, it actually means something.

So for, like you say, for bot detection, for instance, it's been quite useful, but you can't look at just one thing. You have to look at all the signals that you can get and then try to find patterns on that. And the more signals you can collect, the more accurate you can be in your prediction of is it something. But you can never, interestingly though, it's very hard to say it's absolutely not a bot. It's more of that scale of, yeah, it could be a bot and I'm certain to this degree, right? But you can never be fully certain that it's not a bot in this.

So it's all about statistics in this area, but it's been quite useful and quite, you know, there's a lot of good tools out there for all kinds of anonymity detections and both in the authentication space, but also in just regular site usage where this makes sense. And I mean, customers that we have worked with, they're worried about, you know, anomaly API usage, for instance, and is it really their app using their API, that type of thing and building a right architecture atop could prevent those types of things.

Using attestation based applications when you're building insecure applications, like mobile applications, attaching to the hardware and making sure you attest and know who the application is that is talking. There's a lot of, you know, these things that you can do that are adjacent to the ML, because at the end of the day, if you have to resort to machine learning, and you're kind of at the place where we don't know, so we have to guess. And that's very often where you end up, because we don't always know, you have to guess. But there are also places where you can know.

And so it's not the silver bullet for everything, of course. But it's been around for quite some time. And that's interesting.

And so we, I mean, we've all been, like we said, in the beginning, we've all been using AI for longer than we think. We just didn't call it that. So much. But what I think, yeah, go ahead.

Yeah, I think it really underpins a lot of processes that we take for granted these days, like identity verification, that's used in, you know, behavioral biometrics. It's really the foundation of a lot of fraud reduction Intel platforms to be able to take in many, many signals from different sources, and determine which one which signals might indicate a risk. We see it now, too, in identity governance platforms, you know, for role mining and things like that.

But, you know, where we have been seeing over the last couple years, some innovation in IAM is around the use of LLMs for very specific tests, you know, natural language, for policy authoring, you know, policy authoring has been something that has traditionally been quite complex. I come from the background, working with exact many years ago, and I think it's a great standard still for authorization, but it can be quite complex to write policies that way. So using a natural language interface to be able to help construct access control policies is really useful.

Yeah, I think that that's probably the place where Gen AI can make, I wouldn't say the biggest, but at least a very big impact on the security of our systems, because like you say, policy authoring is hard. It's hard to do on at scale.

And, you know, that's all probably been preventing, or in my experience, it's been preventing organizations from deploying this. I mean, you obviously need a lot of mechanisms in place to do good policy based authorization. But just the fact to maintain a large set of policies and knowing that they're accurate and doing what you want to do is a prohibiting factor. So this is a door opener for that, which is great, I think. But one thing that stands out on this list, though, is that I don't think yet we've seen any groundbreaking fundamental shifts for IAM when it comes to Gen AI.

I mean, we see a lot of non-human, or sorry, natural language inputs or configuration schemes and other things, and that's great. It helps, it simplifies, but it doesn't fundamentally change how IAM works. That's yet to be seen.

Yeah, you're right. There hasn't been a revolutionary paradigm shift yet, but it definitely, I think, can help with some of the mundane tasks or the complex tasks like policy authoring or even handling some basic things for user support.

Yeah, yeah, for sure. We wanted to mention OWASP has a top 10 for agentic AI threats and mitigations. I put the link there in the subtitle, subheader, but there's a lot of things for us to think about here. And in the interest of time, I certainly won't go through all of them, but tool misuse kind of would be represented. And I'm sure we're going to see lots of attacks that begin with a misconfigured or a compromised AI agent operating on behalf of a real user.

Yeah, exactly. That one worries me a lot. Not only because of, like we mentioned before, the tool just had too broad access and the AI was somehow tricked or figured that it should use that broad access more than it was intended to. But the other is the agent to agent protocols that start showing up. So you set up this access for an intent that you had in the beginning, what this agent was supposed to do and so on. But then more agents starts to come into the mix and they start communicating. And what tool do you have? Can you use that? I have a different task than you.

So I'm going to ask you to do something that you didn't think about or were built for in the beginning. And that might not be guardrailed well enough. That's TBD. So you end up with these sort of zombie accesses almost out there that you gave it a certain thing, you had access because it had a very particular intent. And then that kind of goes into zombie mode after a while, because it's just been doing that. But then something else wakes up and starts realizing, hey, you can do more. That's great. I can use that. So it doesn't even have to be malicious necessarily.

It's just unintended, which is sometimes equally bad, I think. Exactly. One other quick one I'll mention is maybe overwhelming human in the loop. We're all familiar with imagery fatigue. I can foresee that this will be very similar to that. If you build in that to your protocol where you need to get authorization for a particular transaction or something, it will be easy, unfortunately, for a malicious actor to run something that's akin to an MFA fatigue attack by triggering the human in the loop routines. Yeah.

This is hard, because this is also a place where we're going to need human in the loop, just like we need MFA, right? We can't do away with the function. So when we build these security, it is something to take into an account that when should you ask for this? How often? And if you ask too often, that's an indication of something. There could be either an attack going on, or there could be a rogue agent doing things it shouldn't be doing and things like that.

So yeah, it is interesting. It has a lot of similarities with MFA fatigue. So let's talk a little bit about security concerns that we have about using AI in all of its different forms. The one that jumps out to me here is data exfiltration. You're never quite sure what your enterprise users might be doing with, let's say, your confidential data, maybe data that's got HSPII involved. So you may be opening yourself up to regulatory non-compliance if users are cutting and pasting information into different AI services.

Are these AI services using that sensitive data that you have for trading their models? I think there's a lot to consider here about what repercussions there may be about confidential data leakage, but that's just one. Are there any of these that jump out to you?

Yeah, I think the sensitive data leakage from another perspective, and that is the integration protocols between any AI and the tooling, the MCP APIs typically, is still in the works. I mean, there are authorization standards for using OAuth over MCP and so on, which are looking promising, and I think that's the direction things to go. But the tooling or the SDK support for that is still weak.

And once the sort of authorization request or the way to ask for permissions that the AI need to do gets a bit complicated, I mean, the obvious thing for a developer to think about is, hey, I'll get the AI to just shape this for me. So you kind of move up the logic from what should probably have been on the integration layer in the middleware almost into the AI, and the LLM construct the request because it's great at that.

And that could be okay, but in the end, that could also result in the actual result coming back to the LLM, which could contain things like access tokens or credentials that it should be using or other things. So I think it's going to be easy to make those mistakes if we don't make sure we have good guidelines and good SDKs and good tooling around how communication from an agent or from an AI system should happen. So those mistakes, like we mentioned before, you check in credentials in Git because the AI wrote the code for you with the credentials in there.

Similarly, these things can happen live, I think. That's a protocol question, but it's also a developer question that should be somehow preventive protocol.

Yeah, so there are many different things to be thinking about with regard to using AI applications. But what about using AI and IAM?

I think, as we noted, there are different IAM processes like identity verification and user behavioral analytics that are using it today, but that's just ML. What, maybe I shouldn't say that's just ML because we know that malicious actors have really been using deepfakes a lot, deepfakes that are created with AI tooling that are publicly available. And this has drastically increased the amount of deepfake types of attacks at enrollment time that many organizations are seeing. Yeah.

And similarly to that, as we mentioned before on bot detection and so on, you could start corrupting the data in by letting bots run a lot of traffic. And the more that happens, the you could skew the data set on the other end towards something where it becomes less useful. But obviously also the bot could mimic your behavior a lot more than has been previously possible because it can act more human. If it's browser signals or how fast you click the button or where you move the mouse, those type of things obviously are going to become nearly impossible to detect like that.

So let's take another poll question. What are your top concerns about using AI agents? Is it data exfiltration, regulatory compliance or non-compliance, over permission agents or model poisoning? We didn't get a chance to dive too much in the model poisoning, but think about malicious data sets being used to train your models for nefarious purposes.

So yeah, we'll leave that open and feel free to give us your opinion there. So we've kind of set the stage for, you know, what can go wrong. Maybe we should talk for a minute about data leakage.

Well, there's still DLP, data security platforms that have improved and are, let's say, LLM aware so that they can actually enforce policies about not allowing, let's say, enterprise users to upload data that's marked as confidential or personal information. Data minimization is always a good thing to enforce. Don't keep data, don't send data that you really don't need for whatever your use cases are. Anything else here on this page?

Yeah, I think, you know, the first bullet on secure agent identity, we talk about least privilege here. I almost like to say, you know, zero standing privilege where you should be more dynamic in the privileges you or the access you give. Just because the agent needs access now doesn't mean it should keep that access all the time. So it should be more dynamic. You should sort of decrease that privilege over time maybe or, you know, whatever factors you may have of that. And that fits pretty well with, you know, how you build architectures around API access in general.

And the other parts like, you know, dynamic client registrations for how to get the identities out there and obviously use all the add-ons for the specifications like push the authorization request or par and so on. Those are good without agents. They're even more, you know, important and good to use with agents so that we make sure that there aren't factors there where you connect to something you didn't intend or something connected to you that wasn't supposed to connect to you. These are tools that can help with that. So that's pretty important.

And it's also beneficial just outside the AI space. So not a bad idea. Yeah. And the last one, I think it goes without saying, but I guess we should say monitor all access, look at your logs and, you know, have tooling like ITDR that can understand the difference between actions that happen from a real user versus their agent. Yeah.

Lastly, I think it's good to chime in a bit here about AI ethics. And, you know, the NIST has an risk management framework that is really interesting and a really good read. I've got it hyperlinked there. But here's some of the questions that kind of stood out to me from the NIST risk management framework. Thinking about LLM output, you know, is it accurate?

You know, I've seen reports, studies, academic studies that show, you know, depending on the source, maybe between 70 and 80% accuracy on output. So what do you do about quality control? That's in itself a risk that has to be accounted for at the very least.

Yeah, privacy. Yeah, go ahead.

And just, you know, privacy concerns, you know, are you, back to the, are you leaking personal information? That's, these are things that I think have to be looked at from the very beginning when you're engaging with different LLM based systems. Yeah. The interesting thing about this is that it's fundamental, like with any big problem or new technology or new thing.

I mean, you should always do this. You should break it down and go back to the basics because this framework is the basics.

Like, is it safe? It's a pretty obvious question to ask, but did we? Did we check security? Did we check resilience? All of these things. So going back to that, and then you realize some of these aren't so difficult to address necessarily.

Privacy, it's not necessarily hard to address. If you think about how your information flows in your system, who needs access to what, you could obtain a pretty decent or even very good privacy preserving system pretty quickly. So thinking about these and going back to the basic toolbox is always useful. So next up, Jacob, I thought you might want to talk about some of the experiences security has with B2B AI agents. Yeah.

Thanks, John. So, I mean, interestingly, we started off, I think it's 12 years ago, when there was, in our view, a pretty big shift happening. There was a platformification of companies. So you had a lot of data, you had a lot of services, and you realized, hey, we need to become APIs more. We need to have services so that we can build omni-channel access, so we can have apps and other companies call us and do these things. Some have done it before, but there was a pretty big shift going on then, mainly because of the App Store.

That drove a lot of the API transformation projects in a lot of companies. And we figured that this isn't really fitting into how the workforce systems are doing it. It's not working well. We tried a lot. We actually, I worked as a system integrator before working with security and doing these things. It was really hard to do flexible external identity facing systems that could protect APIs, log people in who weren't part of the organization, who weren't necessarily even having an account at the organization. Maybe you don't need one. Maybe there's EIDs logging you in or other things.

So getting that flexibility in and doing that in a highly secure manner, that was where we started off. And so security always focused on anything that's external that needs to get into the organization, should be logged in, should be identified as who the application is and who the user is, what kind of access does it need? And that should trickle through the entire system so that each component that sees this piece of the request also knows what identity is tied to that. And what do I know about that identity?

Not only who is it, but a few more details so you can figure out what's it supposed to do? What access does it have? And as this has sort of progressed over time, these identities, now we have word for it. We call it SIAM or we call it TIAM or B2B. But it's always been a bit of a mix. Like I mentioned, there's this gray gradient over where this becomes internal and where it stays external. But it's a very interesting problem. And we've been building the security identity server now for quite some time to solve this problem.

And what's been interesting the last year is that with the explosion, I would say, of AI agents needing access to systems, turns out this is the solution. This is the same problem in a different form. Like we talked about before, the non-human identity is yet another external identity that you need to treat. And it gets combined with other non-human identities like the workload underneath, who also needs a credential free of management system to manage it. And that's what we do. We can integrate with that. We can make sure you can identify the workloads, give them the right access they need.

And the thing that is running on top of that can utilize that. The agent itself, we provide mechanisms for human in the loop things and how to scale the permissions over time and how to make sure that just by starting in one then doesn't mean you left the door open for the next. So we're solving those types of problems. And I think this is interesting because it's kind of converging the whole space.

What we used to think of consumers and B2B, where you have different needs, the B2B is still tied to an organization and you kind of live in that space where one organization self-manages their users, builds their own applications or integrations towards your organization. And we do that, but now they also start coming with agents and you need to treat them similarly. But it could also be your own agents or agents that you provide in customer services or things for your end users and so on. So these all kind of fit together.

And it's been interesting to see the last year that what started off as a big scary of, oh, what's this? What are people building now with agents?

Turns out, hey, it's another external identity and we have the protocols for it. We have the tools, we have the integrations. And if you built a token-based architecture to begin with using OAuth OpenID, you're in a really good place. And that's what people have been doing with our system. They've been building token-based architectures with a good identity plane, sort of covering your entire infrastructure with identities flowing the right way.

So it becomes easier to tack this on and start allowing access that is non-human or autonomously non-human, I should say, because non-human has been there for a long time, like we said earlier. Right. Great. So now let's start off by talking about the poll results. Question number one was, what is your top concern regarding AI agents? 44% said data exfiltration. Another 44% said over-permissioned agents. 11% model poisoning. The second question was, is your organization using AI agents today? A third said yes, already implemented. 25% each said considering or planning and unsure.

So it's already underway, maybe more than we already know. Yeah. Interesting. Happy that data exfiltration got their top on the list.

Obviously, we should be concerned about everything, but that one is hard. But it kind of goes hand-in-hand also with over-permissioned agents. I think those two could be, they're not mutually exclusive on on chicken and the egg on those. Yeah. And if there's data exfiltration, there's a good chance there could be regulatory non-compliance if it's PII. Yeah.

Yeah, for sure. Interesting. So let's see, we've got a couple of questions here, and feel free to enter some more if anybody has a question. Let's see. Number one is, do you think that the advent of AI means that we have to rebuild authorization from the ground up? We've invested in recent years in OAuth and Zero Trust, does it mean we have to toss it all away? Or can this serve as a foundation in the new environment? I'll let you go ahead and start that one.

Yeah, I can start that one. No, like I mentioned before, if you've invested in this, if you built, yeah, Zero Trust is a good word. I like to call it token-based architecture.

I mean, that is the foundation. It fits. I would almost turn it upside down. If you haven't done that, you should hurry. If you leave the keys at the border of your organization, and then it's more free or just machine identity, and you don't really know who the original caller was throughout your system, it's going to be a lot harder for you.

So, that authorization structure and authentication and identity structure is well-equipped, and fits well also if you want to add additional mechanisms, such as authorization systems, which there are many good ones out there to use, like OPA, Axiomatics, and so on. So, it's a good base for this, and you're in a good position.

Yeah, I would agree. You don't have to throw everything away. It'll just need a little bit of augmentation, but a lot of the same protocols are already being used. There are new profiles that are being written, a lot of good work at various standards bodies that will eventually work their way into products.

So, authorization will continue to become even more and more important need for fine-grained access control, and I think the mechanisms are there. They just need to be enhanced, but to actually be able to recognize the difference between a human and the agent, and then to be able to alert and get a human-in-the-loop kind of decision when certain policy elements are triggered.

So, I think all the work that we've done thus far in IAM still holds, and will just need to be extended to work with agentic AI and other types of NHRs. Two, as organizations adopt AI workloads and MCPs, securing these environments while keeping partner onboarding smooth is a challenge. Can you share an example of how Qwerty can help a customer strike that balance? Yeah. Qwerty is an access-focused company, so we don't only think that getting a user logged in is the end goal. That's just a start. If you don't get access, it's pointless.

Logging into the app is nothing if the app can't call the API and get the data or do the thing it's supposed to do. So, it's all-encompassing in that sense, and I think there's so many similarities to how AI agents and the MCP proliferation of protocols or APIs work because it's the same relationship. It's just another layer of delegation in there because you delegated some rights to that agent on your behalf or on someone's behalf, the organization's maybe, and it needs to maintain that access.

So, at Qwerty, we do that. We have that mechanism in our product to make sure you can delegate that access down, and you can manage that access. You can see what happens. You can also then also work with decreasing or diminishing privileges over time for agents so that you can get the human in the loop when you need to and so on. Great.

Well, that's all the questions I see here. So, thanks, everyone, for attending, and thanks, Jacob, for a really engaging discussion on a very important topic.

Well, thank you for having me, John. It was fun.

Well, thanks, everyone. Have a good rest of your day, and we'll see you at the next webinar. Bye.