Tips to Simplify B2B2X Identity Complexity

Hello everyone and welcome to the webinar Tips to Simplify B2B2X Identity Complexity, Architectural Lessons from Real B2B2X Deployments, Managing Customers, Partners, and Distributed Users. My name is Alejandro Leal, Senior Analyst at KuppingerCole, and today with me I have Rishi. Welcome Rishi, how are you doing today?

Excellent, very well. Great, so without further ado I'll begin the webinar. I'll start with just a few points on how the webinar will go, and then after my part of the presentation I'll call you back Rishi so you can jump in and talk about your topic today. So now just a few things to keep in mind. All of you in the audience, you are muted centrally, so there's no need to mute or unmute yourself. We'll be conducting two poll questions, so it would be awesome if you guys can participate in those. It helps us in our research and to know what you're thinking.

There will also be a Q&A session at the end of the webinar, so if you have any questions at any time you can enter the question using the control panel, and in the last 20 minutes of the webinar we'll be answering those. And yes, we will be recording the webinar, and the recording as well as the slides will be available in the coming days. So that's me. I'm not going to spend too much time here, but I've been at KuppingerCole for about five years, almost five years, and I cover topics like access management, ITDR, PAM, passwordless, and other topics.

Okay, so let me start by setting the stage for what we want to achieve in this session. So we'll begin by looking at what makes B2B2X identity fundamentally different, because this is not just an extension of workforce or customer IM. From there we'll move into real complexity behind these environments and the challenges that organizations face, so things like multi-tenancy, delegation, and fragmentation. Then we'll shift gears toward architecture.

Specifically, I'm going to talk about the identity fabric and why it's becoming critical in these ecosystems, and we'll also talk about some of the emerging trends, including AI agents and API-driven identity. And finally, from my part of the presentation, I will close with some practical recommendations, what you can actually do to, let's say, simplify and scale identity in B2B2X environments.

All right, so here's the first poll question. So how would you describe your organization's current approach to managing? You will see the options in the screen, so please, it will be great to know what you're thinking.

So, the opening statement. Your most critical systems are now accessed by identities you don't control. That's not just a security observation, but it's an architectural reality. If you look at modern platforms, they are no longer closed environments. They are ecosystems, and access is no longer limited to employees, but it includes now partners, customers, developers, and increasingly machines and AI agents. And the implication is simple. Identity is no longer something you fully own. It is something you need to manage across boundaries.

And that's exactly where B2B2X identity complexity begins. So when we talk about B2B2X, we're really talking about, in a way, identity as the in a way, identity as the connective layer across different ecosystems. So modern platforms expose APIs, portals, and services externally at scale. And access spans very different types of users. So customers, partners, and again, as I've been saying multiple times, agentic AI. So these identities are not really peripheral, but they interact directly with business critical and regulated systems.

And because of that, they require the same level of governance, assurance, and compliance as internal identities, if not even more. So identity is no longer just a boundary control. It becomes the mechanism through which trust is established and enforced across the ecosystem. What makes B2B2X identity different is not just scale, but structure. Because if we think about traditional identity and access management, whether workforce or SIAM, you're still operating largely within a single organizational boundary.

Even with consumer environments, you control the identity store, the lifecycle, and the policies. But in B2B2X, that assumption breaks. Because first, you're dealing with multiple identity domains, so enterprise, partner, and consumer. And each of these domains has its own identity source, its own policies, and often its own regulatory constraints. So you're not integrating systems, but you're in a way integrating trust models.

Second, roles are no longer static or isolated. A single individual can exist in multiple contexts simultaneously. Someone might be a partner in one context, a customer in another, and potentially even part of your extended workforce. And that means identity is no longer a single record. It becomes contextual and dynamic.

Third, trust. Trust itself becomes federated and delegated. So you're no longer the sole authority asserting identity. You rely on partners to manage their users, but you still need to enforce your own policies. And finally, the identity lifecycle is distributed on boarding, changes, off-boarding. They don't happen in one place, but they happen across different organizations. And that introduces delays, inconsistencies, and risk, especially when access is not revoked in time. So what I've been trying to focus so far is the core shift is this.

Identity is no longer owned, but it is shared, contextual, and distributed. And that's why traditional IAM models struggle. They were simply not designed for this level of fragmentation and delegation. So if we look at the core challenges, if we translate that structural complexity into operational reality, we see a set of challenges.

First, we see multi-tenancy. In B2B2X environments, multi-tenancy is not just about isolating customers. It often involves hierarchical relationships. So partners, subpartners, distributors, and then customers. And each level may require, let's say, different policies, different branding, different levels of control. And the challenge is that most systems were not designed for this level of flexibility. They either, to some extent, enforce rigid hierarchies or flatten everything, which really breaks real-world relationships. The second challenge is delegated administration.

So in theory, delegation is pretty straightforward. You set partners, you let partners manage their own users. But in practice, this is much more complex. You need to define what can be delegated, at what level, and with what constraints. And most organizations either don't delegate enough or they delegate too much. So the challenge is not really delegation itself, but it's controlled delegation with governance.

Now, if we shift gears now, if we look at federation complexity, federation is often seen as the solution. But in B2B2X, it really becomes part of the problem because you're dealing with different identity providers, different protocols, and different levels of assurance. And single sign-on across multiple portals becomes difficult to standardize. And most importantly, I think that federation answers who authenticated the user, but doesn't really answer what they're allowed to do, what context they operate in, whether their identity lifecycle is still valid, and what was the intention of that.

So federation solves authentication, but not identity consistency. Fourth, we look at consent management. So in B2B2X, consent doesn't stay within one system. A user might give consent in one domain, act in another, and expect consistency across both. And that becomes especially complex in regulated environments where you need auditability, traceability, and cross-domain enforcement. And finally, the old classic problem of security versus user experience trade-off, but it's even more amplified in these cases. External users are less predictable.

They use different devices, operate across different contexts. So if you enforce security everywhere, you create friction. And if you optimize for user experience, then you increase risk. And in B2B2X, you don't control the environment, so you can't rely on traditional assumptions. So if you step back a little, all of these challenges point to one underlying issue. It's not just complexity. It's fragmentation across identity, control, and trust. And that's what organizations tend to underestimate, the cost of managing identity in pieces rather than as a unified layer.

So once you recognize that fragmentation is the core problem, the question becomes, how do you introduce coherence without centralizing everything? And that's where the concept of the identity fabric approach comes in. Instead of thinking in terms of isolated IAM systems, the identity fabric approach is about decoupling identity services and orchestrating them across the environment. So you have a unified identity layer that connects different identity types, human and non-human, and spans across applications, APIs, and infrastructure.

And for many organizations, it's not really about just adopting the latest tool, but it's about keeping what you already have and incorporating new tools and have that coherence, that identity layer approach. Because it allows you to bring consistency to identity without forcing everything into a single system. But the reality is that if we look at most organizations today, what we typically see is a collection of loosely coupled tools. So we see the IGAs, the PAMs, IAM, access management, all in a way operating independently. But now they're connected through custom integrations.

Identity context doesn't flow consistently across systems if organizations continue to have this fragmentation. So in that sense, organizations end up managing identity in fragments rather than as a coherent whole. And that leads into identity silos. So in the next slide, we can see that separate directories duplicate identities, inconsistent policy enforcement, poor user experience at system boundaries. All of that translates into operational overhead and cost.

And the identity fabric approach aims to address that by introducing a unified identity context, decoupled services, and an orchestration layer. So instead of stitching systems together, you are designing identity as a layer, as a coherent layer across them.

So now, shifting gears. I know this is something that Rishi will talk about more in depth. But this complexity that I've been talking about increases further with the emergence of agentic AI. Agents act on behalf of users and interact with systems through APIs, often via Agents act on behalf of users and interact with systems through APIs, often via protocols like MCP. And what this introduces is a new class of identities, non-human identities operating autonomously. And the challenge is that MCP standardizes how agents interact with systems, but not how identity and trust are managed.

So you need an external identity and governance layer that includes scoped access, consent management, strong authentication for agents, identity at work gateways. Otherwise, you end up with automation at scale, and especially scale without control. And we've seen in the news recently, there's been already situations where AI agents have done things that were not originally planned. And if organizations do not take steps into managing that now, well, that could lead to further risk.

So now that we have talked a lot about the challenges and the, let's say, emerging trends and the identity fabric, we can also look more into the capabilities at work. So what actually works in these environments?

So first, multi-tenant architectures that support both isolation and flexibility. Second, authentication that is adaptive and consistent across user types. Fast forward authentication. One of the other ways to deal with this.

Third, delegated administration, because identity lifecycle cannot be centralized. Then, fine-grained access control, especially relationship-based models, and developer-centric IAM.

So APIs, SDKs, and extensibility. Because identity today needs to be embedded, not just configured. And many organizations are already providing these capabilities, but the challenge is to do that at scale and, of course, to execute them correctly. So I'm aware I'm running a little bit out of time, so thankfully, I believe it's one of the last slides. Almost there.

Yes, so future direction. So we look ahead. Identity is clearly evolving. We look at the market. There's been lots of acquisitions on companies that are dealing with companies that are dealing with NHI management or big companies looking at identity companies. So it took quite a long time for the industry and for organizations to understand that identity is quite important. So from our perspective, we're moving toward identity fabrics that reduce fragmentation. So IAM is becoming API-first, consumed as infrastructure rather than standalone systems.

We're also seeing convergence between human and machine identities. And increasingly, trust decisions are based on context, not just based on authentication. So identity is shifting from a control system to a distributed trust infrastructure. I'm pretty sure Rishi will talk about that as well, and hopefully we can also hear some examples from his perspective so we can get a more clear picture on that. But before I hand over, I would like to talk about a few practical recommendations. So what to prioritize when modernizing. So if we bring everything together, what should you actually do?

As I've been saying multiple times, adopt an identity fabric to reduce silos and fragmentation. Design for multi-tenancy and delegation from the start. Prioritize API-first and developer-centric IAM. Implement adaptive and passwordless authentication. We've been talking about passwordless for quite a few years already, and many vendors and organizations realize that it's more difficult than it seems. But it's hard to say that passwords will probably be around for a while, but it's important that organizations stop using phishing methods that are prone to phishing.

Another thing is extend IAM to AI agents early and API ecosystems. And ensure alignment with regulatory requirements. And ultimately, I believe that the key takeaway is this. B2B2X identity complexity cannot be eliminated, but it can be made much more simpler and coherent through the right architecture. And success comes down to making identity work consistently across ecosystems, organizations, and now machines. So before I hand over the mic to Rishi, last poll question. So what is the biggest challenge you face in managing B2B2X identity environments?

And with that said, I would like to now give the floor to Rishi. And then in the last 20 minutes, we'll have some time for Q&A. Thank you very much, Alejandro. Very glad to be here. First of all, a quick introduction.

I'm Rishi, one of the co-founders of Dscope. Dscope is a customer identity and agent identity platform. Very excited to share some of our learnings that we have seen over the last few years working with many customers.

With that, let's dive into some of the topics here. What I'm going to do in the presentation today is cover first a whole bunch of learnings in the B2B2X related domain.

In fact, some of the questions I saw come in are already related to things like which industries this is applied to, etc. And we'll cover some of those. And then towards the end, we'll cover some of the new trends, MCP servers, and agentic identities, which are being adopted very fast, and some of the best practices there. So here's a quick agenda, as I said, flavors of IAM, how we see different parts of IAM, how do they relate to B2B2X identity challenges and tips.

So first of all, when we look at the external identity management, which is excluding the workforce, there are four different pieces that we see. One is identity for B2C scenarios, where you have to log in individuals. And the challenges we see are user friction, bots and attacks takeover. These could be SMS pumping attacks, these could be account takeover attacks. And then very static user journeys where you don't have different options to be able to log in different set of people.

Second challenges is B2B, which is single sign on, how do you do MFA, how do you provide FGA, those kinds of issues. Third is logging in partners or contractors. So these are external entities, not just customers, you see B2C customers and B2B customers on the left, but external partners and scenarios like those identity silos there, multiple user pools, IT overhead in managing those. And last we're going to cover is just machines, agents, how do you secure your APIs, how do you secure your agents, the right level of permission for agents.

Now, why does a workforce IAM not fit here? It's a very interesting question. A lot of customers kind of struggle with this. But the idea is workforce is very centralized and predictable. You provision a user, you verify a user, the user journeys are only a few. There are certain applications that you provision and an employee works for the company. So the friction does not matter that much.

Well, I mean, this is changing, but still it's not the same. But when it comes to customers or partners, you really need to worry about self-service signups, self-service password reset flows, friction. How do you make sure the user experience is really, really, really good? So this is why I think we have seen workforce direct from external identity. Talking of the B2B2X challenges, I think this is an every industry problem. I know there was a question from the audience about this, but we see this as a challenge everywhere.

Insurance industry, pharma, automotive, and not only these, I think we see this problems in retail and e-commerce platforms which do marketplace scenarios. Depending on the different vertical, now, the actual application may be different. Customer portal, broker portal, reinsurer portal, or in the pharma world, it may be a partner, supplier, pharmacy. So the real incarnation of what the problem is may differ, but the problem exists in all different verticals. One of the biggest challenges when you see a B2B2X scenario is just SSO, right? Single sign-on.

The IDP is not centralized in cases, and the IDP needs to come in from customer's IDP because it's B2B2, and then the X, which could be a B2C or a B2B. But SSO struggles like connecting with different IDPs. You will have all different flavors, some legacy. How do you make sure? How do you test those? And this results in large onboarding times, failure onboarding, support costs going high. So this is a huge struggle that we have seen. Second is just the level of tenancy. And I know Alejandro touched upon this, but multi-tenancy is a big problem. You need two level, you need three level.

Who manages the roles in the partner tenant? Do you have self-service onboarding on those? Do you have delegated administration there? What level of granularity do you have in fine-grain authorization?

Very, very, very complex environment. I think one important thing here is to make sure as you're designing the system, as you're choosing your vendors, to see if it meets your tenancy challenges based on your situation.

Now, fragmented identity stores is kind of the next one that you will see, which is different applications may have their own login systems. Now, your goal should be to have all customer identities or partner identities or agent identities centralized. They can federate, but federate does not mean there is no linking. We have seen often work with large customers where they start by saying, I have 15 different identity stores, different applications, and this just becomes a very complicated environment to manage.

And then comes the overhead, which is internal, which in today's world means increasing cost, decreasing margins, and how do the engineering teams respond to these? Can you disable only two users based on a criteria? Can you send me the last seven audit logs? These are all overheads that IT and developer teams face. And over time, you need to make sure these are aligned across your organization and you can reduce this overhead. And the last but not the least, security and compliance, right?

I mean, how do you make sure that the security and compliance teams have the right level of controls, the right level of security? And I think the most important here is we are starting to see new and new compliance regulations evolve from Dora as well in Europe. And the most important thing to make is you should have your controls, measures very well defined, and then you can map to different compliance measures. So this becomes an important piece.

Moving on, I think we touched upon a lot of the challenges in B2B2x. One of the emerging things that we are seeing across the board is just AI agents spawning up everywhere. Every business unit is starting to build up new AI agents. They're spinning up in different places. We need to make sure that these AI agents can authenticate properly. You're giving them the right set of permissions. The decision-making for these agents is not like a human decision-making.

They could be made by a human, but then AI agent has certain level of permissions, which basically means you need to put very, very, very thorough audit. What did the agent do? Who approved it? What kind of actions did it take? And then to make sure you design this right, there are certain things to be kept in mind from a risk modeling perspective. The agent should never have more permissions than a human and should have a human oversight. And if it's a fully autonomous agent, it needs to be audited properly.

All in all, what we are starting to see is, for this paradigm, you do need a dedicated identity model, a dedicated identity system. Now, of course, it needs to collaborate with your human identity, customer identity, or workforce identity platform. It needs to federate with that for bringing in the right human roles. But from an agent modeling perspective, it needs dedicated pieces, including what is the ownership of the agent, who created the agent, who is the agent acting on behalf of, standard protocols, everything. So this becomes a huge initiative in itself.

So based on our large set of customers, roughly more than thousand customers in production, there's certain tips and best practices that we have seen. I think one, from a multi-tenancy perspective, think through the scenarios, model your different set of entities, different tenants that you may have, what will be the sub-tenants, and really think about, does each tenant need a different auth model? Does it need different level of password complexity? Does it need different MFA permissions? And whatever it is, map that out ahead of the implementation.

A simple map of the requirements of these entities goes a long way. And then as you design this, make sure you are enabling it for self-service SSO, skin setup for tenants, auth model setups is there for each of these things. But building the infrastructure for the right multi-tenancy model and thinking ahead and choosing the right providers and designing the system goes a long way. Here's an example of one of Dscope's customer, Revo Insurance, where they had multiple external facing portals. They're an Italian insurance company listed on Euronext star.

Their whole process before we started to engage with them, multiple portals, very complicated SSO setup, very manual, and the customers and partners used to suffer. Broker individual and partners had different security requirements. They all needed different set of permissions and modeling. So Dscope came in, established and helped them with IDP-initiated SAML and SSO.

Now in surface, it looks very simple, but given the fragmentation of portals, fragmentation of tenants, this was a task where planning ahead and designing the right multi-tenancy model in a flexible system such as Dscope was critical. And this is an example where you have multiple different parties coming in. Login requirements, SSO requirements are different, but you need to still centralize all of that. Second one, identity silos.

We touched upon this earlier, but we are starting to see mobile portals and partner portals and people accessing from website and support portals, which are commercial applications. Some of this could be homegrown, some of this could be commercial applications. You need a single source of truth. You need single source of identity. You need to be able to customize user journeys based on these applications and align them. You need to audit every action across every portal. You should be able to revoke a user from all the portals or certain portals. So per portal user role becomes important.

And then last but not the least, branding across application is also an interesting one, which you need to keep in mind as B2B2X becomes important. Now, here is a way to think about it. Outcomes from an identity federation deployment. So Databricks as a customer of Dscope, they had multiple different apps and different IDPs internally because some customers deploy in AWS, some deploy in Azure, some deploy in GCP. And they wanted a different login experience slightly from a user perspective and where the user is originating from help portal. But all of the user store needs to be central.

Everything audited needs to be central. So we were able to design a full identity routing where the user comes in from in a help portal based on their characteristics of which customer this is, what cloud are they deployed on, route them to the right IDP, and go log in there. Then the next step is really building it for self-service admin. Basically meaning give every user a self-service capability to own their profile, reset their password, giving tenant admins capabilities to change roles and go out and be able to track all audit trails for each tenant.

All of those capabilities need to be at the self-service level. Users can manage their passwords, tenant can give them role admins, etc. And then invest in branded experiences. So each tenant could be different brand. This is self-service capabilities, have widgets across your different portals, all of those. And the last piece is from an FGA, like making sure the right level of access control exists in the application.

Whether it's role-based access control, whether it's relationship-based access control, whether it's attribute-based access control, different industries, different use cases may require different types of access control. And you need to be able to map different levels of access control for different set of use cases inside your organization. Be very careful that you don't over-design it in some cases as well. Let's jump into the last five minutes with some of the MCP requirements and what we have seen pop up.

One of the biggest things we are starting to see is MCP servers being built and agents connecting. This even further complicates the architecture. You need to be able to say a user connects using a cloud or a charge GPT to an MCP server, which needs its own authorization server and a credential vault, and then connecting the application.

Now, this architecture is what we are recommending from an MCP auth in a B2B2X environment. Now, notice one of the things by putting a dedicated authorization server in the middle, we broke the direct connect of client to the application, which means the token that the agent has is not the token to the application. And this is very, very important from an architecture perspective.

So, this architecture separates the token and goes out and make sure the right security control is in place. Here's an example of the use case where one of our customers, u.com, deployed MCP auth with G-scope and being able to deliver very, very secure access controls for all of their customers using a variety of agents across the board. U.com is a productivity platform supporting developers and other constituents in an organization. And the key thing for them is reducing the attack surface for AI agents being able to work through different AI agents and setting the right access control.

With that, I think I would like to kind of close with a brief overview on G-scope. These were some of the learnings. G-scope is a customer identity and agent platform. I've been around in business for a little over four years, 1,300 organizations in production. The four core reasons why we have been able to earn the trust of some of these larger organizations, as you see down there, GoFundMe, Databricks, Godot, Xlink3, and that is we have been able to reduce the implementation time significantly.

Customers go to market with our product three to four times faster, given how flexible the platform is, different level of tendency, being able to design user journeys. So flexibility is second piece. Third piece is being future-proof. I think one of the things that I have seen as we work with large organizations across the world is your identity journey is not a single journey. You build a journey and then new requirements come in, you need to modify it. And that's what's happening in the agent world.

We did not even think about AI agents and the access control there till about a year and a half ago. And now, every identity team in every company needs to think about how do we handle agents in addition to customer identity, in addition to partner identity, and in addition to workforce identity. And this is why a very flexible and easy-to-configure platform really should be the foundation from a B2B2X identity perspective. Thank you.

With that, I'll open the floor for questions and hand it over to Alejandro before that. Thank you, Rishi. That was great. Lots of insights, lots of practical examples. I really like your slide on MCP. I think that's a conversation that we need to be having now. You articulated it very well. I see that we have already some questions in the chat, but before we do that, I'll just briefly go over the remaining slides. So we have plenty of research on these topics on our website. We recently published our leadership compass on SIAM. I believe this scope was featured in that report.

Here are other services that we do. We do also events. As some of you may know, we will be having the European Identity and Cloud Conference taking place in just two weeks in Berlin. We still have spots available, and if you're interested, just scan the code. We'll be having conversations around identity there, and also we'll be having some other events throughout the year in Cologne, in Munich on NHIs, and in Frankfurt on SIAM. So great. If you have any questions after this webinar, you can reach out to me. You can reach out to Rishi, and we'll be happy to answer your questions.

But for now, let's look at the... How about first we take a look at the poll results, and then we can check out the questions. Okay. So if we look at the first poll question, the question was, how would you describe your organization's current approach to managing B2B2X identities? So it turns out over 52% said partially integrated, some federation or shared services in place. 26% said mostly siloed, and 22% said moving toward a unified identity fabric. 0% said fully unified and context-driven identity across all user types. What do you think about Rishi? Does that surprise you? Interesting.

Not really. I mean, I think the spread here is always interesting to see. I think to me, one thing I'm learning, Alejandro, identity industry is very, very fragmented. Requirements are fragmented, and we have seen this to be across the board. So not really surprising from my perspective. Results very expected. Same here. Absolutely. So if we look now at the second question, what is the biggest challenge you face in managing B2B2X identity environments? So 37% said integrating identity across APIs, platforms, and emerging AI use cases.

26% said implementing scalable multi-tenant and delegated admin models. 20% said managing multiple identity types, and only 15% said balancing security, such as MFA and compliance with user experience. So it looks like the two main challenges is integrating identity across APIs, emerging AI use cases, and scalable multi-tenant and delegated admin models. Which I think, by the way, is a very appropriate result.

I think more so than even like first one, I think I didn't have any commentary, but I think from my read right now, managing APIs, platforms, AI use cases, agents, is the number one challenge. I think this we are seeing across our customer base, so much engagement, because of the uncertainty at hand.

Right now, people don't know what to expect of AI agents, the unpredictability, and the businesses are moving much faster than the identity teams can respond. And this, I think, is becoming a huge challenge.

So very, very appropriately said. And then the multi-tenancy is your legacy. That is what you're moving along, complicated architecture. So absolutely. I think completely aligned with this. I think AI agents, we are seeing same in our customer base as well. And that's definitely the situation. Awesome. All right. So now let's look at the questions, so we can continue the conversation. So the first question says, which industries and use cases benefit from the B2B2X approach to identity? Would you like to take that? Yes. One second. Yeah. So which one was this?

Which industries and use cases benefit? Yeah. So as I touched upon this a little bit earlier, I am seeing this across different industries. The way I think about this is rather than the industry or use cases B2B2X approach, the way to think about it is when you deliver a service or a product or a login experience, are you delivering it to an organization and their users use it, or are they surfacing it to somebody else again? So as I mentioned, insurance is a big vertical. We are starting to see this. We are starting to see this in retail as well.

So I think we are seeing this across many different verticals from insurance, pharma, automotive. But the key thing I'm starting to observe is this is mostly emerging in areas where they're either two level marketplaces, where they have agents in the insurance world, or there's pharmaceutical in the supply chain, or automotive dealers. Those are the scenarios. Whenever there is a two tier business model, that's where it emerges. And that's where we need to think about these particular use cases. Absolutely.

Not much to add, but yeah, I think that the identity approach really shines in ecosystems where one organization needs to securely manage identities, not just for its own direct customers, but for its partners, users, devices, etc. It's less about a single company's user base and more about federated multi-tenant identity across, let's say, value chain. So as you mentioned in your examples, insurance, finance, healthcare, I guess those are some of the industries that come to my mind.

Okay, now let's look at the second question. The second question, I already answered it via the text, but I don't know if you would like to add anything, Rishi?

No, I see partners and organizations. I think the distinction is not much. I think it's just, what is your business relationship? In some cases, it does matter who's IDP, but I agree with your answer there. Nothing much to add. The next one is more interesting.

I think, as you said, we should discuss, and I would love your opinion and I'm happy to chime in, is like, would you classify AI agents as another type of machine identity, or are they unique enough to be treated differently? Now, this is a hot topic with every customer I meet. And I think the answer is they are different. They are a version of machine identity, but they are unique enough to be treated separately. And the reason is, the machine identities were much more static in nature. They used to do certain tasks, they used to have very static permissions.

AI agents behave like a human, but you don't want it to give the same level of autonomy as a human yet. So there are some characteristics of a human identity, and there's some characteristics of machine identity. The biggest thing to keep in mind why you need to treat them as different, Alfred, is because you want to understand each AI agent is non-predictable and probabilistic. It will want certain actions, then it may ask for more permissions, it may do a different action, it may hand over the tasks to another agent. So this is different than your old machine identity, which was very static.

So that's my view. Again, I think Alejandro would love to hear your thoughts, but this is a good discussion topic, even over drinks or over a work meeting. It would make a very good webinar topic to spend more time talking about it. But I'm afraid that I must agree with you. It would be more fun if maybe I disagreed for the audience. But as you say, yeah, they're different in key ways. They're autonomous and task-driven, so that distinction between being static and more dynamic.

So they don't just execute predefined actions, they make decisions, they call multiple systems, they act on behalf of other identities, and their behavior is dynamic and unpredictable as well. So I'd say that from an IAM perspective, they require, in a way, like identity, like machine identities, but also delegation models, consent, and context awareness like humans do. So they're not entirely new, but I'd say they're complex enough that treating them as a standard machine identities is insufficient.

And I know that things are moving fast, things are changing, people have different perspectives, so I'm sure that this exciting conversation will carry on and we'll probably have maybe different takes next time we talk about it. Okay, let's look at the next question. So the question is, where do you place a workforce IGA system within this B2B 2x view, knowing workforce, partners, and customer accesses can be mixed? Would you like to take them, Arushi?

Yes, I'm just reading it again, knowing workforce, partners, access can be mixed. Yes, I think, Philippe, this question is from Philippe. The way I recommend to think about this is, your workforce IGA solution should be managing your workforce identity. And in general, whenever it comes to partners and customer access, yes, they could be mixed. But what I'm starting to see is, typically those systems have, like, partners and customers have way different complexity requirements, way different modeling requirements.

IGA solutions are designed to be provisioned and be more static in nature compared to self-service and some of the other multi-tenancy challenges we saw. So I would keep them separate. That's what I'm saying.

I think, Alejandro, I don't know what you're seeing in deployments, but workforce IGA does not extend well to partner and customers as we have seen. I agree with you, Arushi. I have nothing to add on that one. We have another question, but I believe you already answered this. I think this is a good one to even take it for other audience if you want to. I think some very good questions from Alfred on MCP servers. This one is basically, do you have any insights on how to manage MCP servers in a B2B2X setting? One MCP server per customer. How do we add two layers of control?

Now, just to clarify, right, what really the question here is, you have multiple customers as an organization and those customers have users, which is B2B2X model. Should you build one MCP server or should you have one MCP server per customer in the architecture?

Now, based on scenarios, you could go either way. My recommendation here is try to design it as one MCP server. And the reason is because a lot of the platforms like Claude and ChatGPT and others expect you to have one URL to be connected as a connector. They don't know your customer.

Now, you can design it as a single URL and inside that MCP server, you can do auth routing, as we call it, and says the user is coming in, the user hits a login, they can put in your email, their own email, that can route them to the right tenant. And I think the biggest question here, by the way, a lot of learnings coming from multi-tenancy here, Alfred, is you should think of it as each user inside each tenant for the MCP server should have its own authorization model, may have different permissions.

So tenant level authorization is very important if you want a secure MCP server, because you may have completely different role-based model based on different tenants that they have. Some may have only three roles, some may find five roles. So that's my recommendation.

I'm very, very happy with this level of question that you're asking here, because designing this right ahead of time will go a long way. Would you say that one MCP server per customer depends on the organization's operational maturity or risk model, isolation requirements, sort of those things?

I think, yes, there could be reasons why you do one MCP server. I don't know if it is risk model, but it could be a function of what tools and use cases you want to enable. I think ideally designed, again, to reduce complexity, right? If you're starting ground up, start with one, see if you can meet it. But in some cases, when you have multiple different set of tools that you want to in different MCP servers, that's where it could come in handy. But I think we are starting to see, at least sitting in the valley here, where people are really AI forward.

I'm seeing they are all going for that single model, but inside that, you kind of segment in the tenant level. All right. Maybe just one final question from my side to you, Rishi. How important is customized branding in B2B2X? Excellent. I think when the last X is a C, then it is critical, right? In a lot of ways, your customer, which is a business, will want to give a face to each of the customers very different. Each business will want their own branding and styling, because consumers don't care who was the first tier, right?

I mean, whether you are using software platform A versus B in delivering the service to that end consumer does not matter. So when it comes to the last X being a C, B2B2C, then very, very critical, Alejandro. We are seeing people really care about pixel perfect, right UI, right branding, colors. If it is a B2B2B, in that scenario, also important. It's important to kind of be able to kind of create some personalized experience, but then the priority reduces.

But I think to me, in general, what I'm starting to see is the importance of user experience, importance of styling is becoming more and more important. There's two things happening, right? Once you interface with a human, then you need to be really branding aware. When you're working with an agent in the B2B2X MCP scenarios, then you really need to design the right architecture, right agent experience as it's being called. Absolutely.

Well, thank you, Rishi, for sharing that. We've had an excellent webinar, very good questions, very good insights.

Rishi, if you had just, let's say, 60 seconds and you're talking to a CISO, what would be the main takeaway today? Yeah, no, first of all, yes, agreed. Very good questions, very deep engagement. I feel my takeaway is this is a good time for you to rethink your identity stack as you welcome AI agents and MCP server in your organization. This is the time where I think the AI is one of those things where once inside the organization, it's going to scale very fast. So building the right foundation, the right set of controls is very, very important.

And that is where if you see all of the material, which we'll share with the audience is very important, thinking the right multi-tenancy, right security controls, right MCP architecture. So think of these identity controls ahead of time and don't use your existing identity infrastructure as is. It may fit the need, but first design it, then decide whether you're going to use as is or you're going to bring in a new identity system for AI agents, but be deliberate about design. That's what I would request. Exciting times.

Well, Rishi, always good talking to you. Thank you to everyone from the audience. If you would like to ask us any specific question, you know where to find us. And thank you everyone. Have a great day. Thank you.