Identity Challenges in the Agentic Era [Intermediate]

Hi, everyone. I'm Meir. I'm the co-founder here at Descope. We are a sample from Customer Identity Access Management shortly. And I'm also going to talk today about identity challenges in the agentic era.

So, as mentioned, AI has a lot of talks around AI. Hopefully, I will enlighten with some new things today. A bit about me, as mentioned, co-founder at Descope, worked previously at Palo Alto Networks.

So, in the cyberspace, a company called Demisto was acquired by Palo Alto. And also, we had some old machine learning and AI teams. And both of them led those teams.

So, a bit of experience both in cyber and AI. Some terms that might pop up during this conversation is, first of all, AI agents. We will not drill down into that. Everybody already heard that one. But it's worth to notice the agentic framework, agentic AI. That talks a bit more about if an agent is more for a single task. Or agentic AI is about sometimes a swarm of a couple of AI agents where everyone does its own task. And you coordinate between them. And tools. And tools is one of the big changes that's happening today in this year around the agentic AI and AI in general.

Giving the ability, basically, to those LLMs that were more like a chat and had the knowledge and went for the database. To actually do an act with permission on behalf of the user. And interact with third-party APIs. Call your HubSpot, your GitHub to get data. Or even do action, open pull requests on your GitHub. Or go to your booking account and book you vacations.

So, this takes those AI agents and those agentic workflows to the next level. In a lot of time, I will talk about a lot of the tools and how it correlates to the identity, specifically.

So, start with some challenges that we are seeing in this space. In the identity of those agentic workflows. First of all, the biggest one is security. Half of the OSAP top ten security issues for AI in general. Generative AI. Is related, correlated to authentication and authorization. And that's definitely one of the big challenges.

And also, on the other hand, like a driver to why you need to focus or put emphasis on the identity of those agentic AI and agents. We'll drill down into that. In probability and scale, there is some of the talks here also talking about non-human identity. Those obviously go, regardless of AI, they were already exploding in the amount per non-human identity versus the real human identity.

Now, with those AI agents that also are on behalf of the user. Now, the number is going up. It's getting things more complex. Some frameworks, which we'll touch upon, like MCP and 828, try to handle that, facilitate and make it easier for the developer to handle those complexities. But those come with also some challenges of their own. And we'll touch on that, too. And those two boils down to making it hard to take developers to build AI agents to production for a consumer or customer-facing use cases. It's hard. There are different security risks involved.

And also, the implementation is quite complex. So, the developer needs to think, and we'll touch a bit on different identity-related complexities and challenges. We'll touch a bit of storage, a lot of the token storage and a lot of challenges that you are already familiar with. Bottom line, less than two-fifths of the AI projects actually transition to production.

So, definitely affected from the above. So, there's a lot that's happening in this era. We used to know that there was a human and there were bots. And we differentiated between bad bots. And usually, the bots you use are bad bots. And you have rate-limiting them to not overload your system.

And now, there's a new player in the game. It's like AI agents.

So, OpenAI released the operator a few months ago. It's operating on the browser like a user. It's still an AI agent.

So, is it a bot or is it a real human? How do you treat it? Do you rate-limit it like a user or you rate-limit it like a bot? How do you, from one hand, give him access to what he needs to do and those AI agents? On the other hand, you don't want to rate-limit it from a security perspective and not to overload your system with API calls.

So, there is some shift in how you handle and how humans and AI agents operate on the web or the browser versus your APIs of your application versus what it used to be before. And this drives some new changes which we'll talk about. Drilling down a bit to the security part. There are a few things that are really – a few threats that are really obvious in those areas.

So, we talked about the tools, right? The tools are the big differentiator that give the power for those agents to work with those existing systems. Going to your booking.com account and getting you on the next vacation. But there are challenges around tool misuse. What if you give your agent too much power, giving him access to tools that he wasn't supposed to go and maybe doing it on your behalf? Booking a hotel which is way too expensive than what you can afford. And maybe for some agent, you will give him access to your Salesforce account because you trust that agent.

But for another agent, you definitely do not want him to go and see sensitive data. So, you hear a lot of companies encounter those challenges. How do you make sure that the right agent answers the user the right tool and not misuse? It also correlates a bit to privilege compromise. What if that agent can do things like he was supposed to only read from the Salesforce? But if he can write things to that Salesforce account, that can create issues. Do the booking on your behalf. Also can create new issues for the user. What is authorized for each agent to actually do on each tool?

That is also roles, permissions. Those kind of access controls are needed. Identity spoofing.

Basically, those agents are doing action on behalf of the user. How do you validate it's really on behalf of the user? There was no account compromise and the agent is doing something by a malicious actor on behalf of a malicious actor. Definitely a big attack surface. And when we're getting for the multi-agent system.

So, we talked a bit about the agentic AI where it's like could be a swarm of agents where each one does a specific task. So, now what happens? You have communication between those agents. There is coordination. There is vulnerabilities about the communication between those agents. Can that be compromised? Can the agents miscommunicate and delegate tasks from one agent to the other? And then there is a vulnerable business in that. Delegation wasn't supposed to do.

So, those areas boil down to a lot of the threats which are one of the biggest threats that are related for authentication authorization in the gen AI space. I can show it forward that a lot of the things that basically also a developer needs to think when he's deploying data agents is related for a lot of the identity protocols that he already is familiar. If you want your APIs to be ready for the agent era, you need probably to be OAuth compatible. Because a lot of those agents talk on top of OAuth for accessing those APIs of the app.

Things like dynamic language, PXE, fine-grained authorization, token management. All those things are related to what the developer needs to think about when he's deploying his AI agent. And I'm touching here on MCP. MCP is also getting a crazy amount of traction. And a lot of developers come and say, okay, I need to probably do all that tool calling. I need to do it through MCP.

But MCP, remember, this is one I'll touch. I'll dive deeper into that. But it's a spec. He needs to think how he implements that spec, how he implements that protocol. And that protocol also comes with a lot of security issues by itself. It's also changing as we go, that protocol, and requires a lot of the identity. For instance, OAuth 2.1 is required to implement MCP spec. So he needs to wrap his head. The developer needs to wrap his head when he's deploying agents to production or across multiple identity-related protocols and implementations.

We believe that there is a need for a new agentic paradigm. Basically, to build on top of well-known and existing standards that help you. First of all, they are well-proven. Build on the top of the shoulders of giants, you can say, that have proven themselves along the time. So still build on top of OAuth. For instance, MCP, which is one of the most hyped protocols out there, is built on top of the known protocols of OAuth behind the scenes. It requires OAuth 2.1, for instance, which I touched a bit.

And there is newer protocols that was released by Google not too long ago, a few months ago, called A2A, which is talking more about agent-to-agent communication protocol. So keeping that based on standards of well-known is important and built on top of that. The other part, fine-grained authorization. As we talked about the permissions for those agents, what they can access and not access, which data points they can access. Sometimes we see that it requires more granular permission than the usual role-based access control.

And sometimes fine-grained authorization is needed to actually make sure that the agent gets into the right data point in time, has the right scopes, and scopes in time also. And interoperability. We need to make the developers efficient and give them the ability to integrate their agents with multiple tools fast. And that's what specs like MCP are coming to help. To actually standardize the way that AI agents communicate with tools and external local tools and make it really faster for the developer to deploy the AI agents in a secure manner. So we'll dive a bit deeper into two protocols.

The first one is, yes, no surprise here, MCP. I touched that a bit. MCP is built on a server-client architecture, where basically the client is more on the side of the LLM and basically communicates with the MCP server, which in its turn will do the API calls either to a remote API, like what you see below, and more simplistic sometimes, it's on the local workstation, the local platform of the user. When it's remote, there is also a remote server. That MCP server could be remote also by itself. That comes with its own identity challenges by itself.

Not too long ago, Gartner released a report where it just recommends, for instance, not to do remote MCP because of the security challenges that come with that. So there are challenges also coming with deploying MCP server by itself. It's also a challenging protocol by itself because it's changing all the time. It's relatively new. It was published last year. But there are still changes being made to the protocol as we go, so it makes that implementation challenging by itself.

But it is getting a lot of hype because it does solve a big problem of how to streamline that whole process of LLM talking with tools, which is one of the big drivers of the adoption of the AI in general. Inside the spec, you'll see direct references to OAuth.

So, for instance, you must implement. As I mentioned, the spec MCP in general is a protocol. It's not necessarily implementation. So the developer that wants to use it needs to implement that. And it requires OAuth 2.1, for instance. This is directly from the spec. And I give you another example that recommends dynamic client registration that by itself is a bit of an odd security-wise feature. You probably are familiar with the OAuth. But the dynamic client registration is kind of an open endpoint that you need to implement that doesn't have authorization.

It's open and does not have any authorization by default. So how do you protect that endpoint? You need to kind of rate limit that. That also raises questions. And it's also a subtle point in that implementation MCP, which is not 100% clear on the security angles of it. So it gives up with challenges by itself. And for the new protocol that was released is agent-to-agent protocol. The agent-to-agent protocol is relevant when you have multiple agents that communicate one with the other. It's significantly newer than what was released by Google, while the MCP was released by Entropic.

And it's new. It doesn't come to replace MCP.

It can, by the way, coexist. This one, the agent-to-agent, talks more about how agent talks with and internalizes the way that agents talk between themselves, delegate tasks, capability discovery. Capability discovery is relevant also in the MCP, because in the MCP spec, you can also declare what the MCP is supporting, which tools and what tools can it do.

But here, the discovery is between agents, which agent can do what. Task management, how you delegate the task and make sure they are completed, and collaborate on that, collaboration between agents, and negotiation on that. So it boils down to agent-to-agent communication. It is newer, also getting some hype, not as hyped as MCP. I assume it's because MCP is more relevant for the now problems. Agent-to-agent is about for the more complex ones, especially when you're talking about deployment and production, especially in the enterprise of a multi-agent system.

In a nutshell, this is kind of what it looks like. I won't dive deep into this one, but basically, the agent requests an agent card for the discovery phase to understand what the agent can provide, what can that agent do and accomplish. And then it assigns a task to that agent, processes it to the other agent, gets back messages, updates are streamlined. So this is, in a nutshell, that process, neural protocol. Jumping into some closing thoughts, I'll try to summarize some of the points that I discussed here and leave some minutes for questions. So how identity ties into those AI systems?

First of all, you want your APIs to be agent-compatible. Basically, you want to make your APIs, a lot of the time, easy for the agents to be accessed. And you can accomplish that by, first of all, making them OAuth-compatible by having you implement an MCP server that you deploy. So it makes it easier for other developers to integrate your APIs where they are LLM. So this is a big part of the identity that we believe that you need to make your APIs agent-compatible if you want to tackle that problem. You want to have secure MCP servers.

So MCP is relevant also for making your APIs compatible, but also the other way around. You're an agent builder, and you want your agent to talk with other APIs. So you need to make sure that your MCP is secure and is enterprise-grade. You need to make sure that the whole token management, I'm showing a bit here. The token management of those MCP servers, talking with other APIs, they are secure. They are not leaking any tokens between users. Interfaces for the LLM, you want to authenticate versus that LLM. It's also another identity problem to tackle. Consent management.

You want that AI agent to make API calls on behalf of the user. You want the user to give consent for that. You need to make sure you have a consent flow, which is well-built, and you write the right scopes. This is tying in for both ways. Also for making your APIs compatible for the agent. So you need to make sure that your APIs provide the right scoping so the user can get the right consent for that. But also vice versa, when you want to have your LLM do actions on behalf of your customers or your end users, you will need them to actually give consent to you to use their API.

And this is basically an over-usually protocol to give that consent to make those API calls on your behalf. So the LLM will be more powerful. Fine-grained authorization. As I mentioned, sometimes you need to actually make sure that each agent can have the right access to the right data at the right time to make sure that it doesn't leak for the other vulnerabilities I mentioned before. And prevent AI abuse. You want to make sure that you protect your APIs in a manner that they won't crash from too many agents doing actions on it. And no abuse.

So you need to identify those agents, and maybe you need to handle them and their requests differently from how you handle other API calls. There we are. Yes. Perfect. Five seconds.

Sorry, but no time for questions. Sorry, there's no time for questions. But thanks very much for an excellent presentation. I'll take it.

Oh, this one.