Thank you everybody, thank you for being here. Yeah so let's talk to a less complex topic instead of nuclear but still on the AI agent space. I confess so it's really hard to talk about AI agents these days because from the time that we submit the presentation proposal until the time we come to the AIC everything has changed in the world. So I will try to focus on some critical capabilities, so the challenge that we have for authentication and authorization, critical identity and access management capabilities and some questions for you to take back home and try to think about AI agents.
A quick introduction from myself, so I'm Rogério Rondini, architect, senior architect from PwC Netherlands. I'm originally from Brazil as you can see the flag over there but I'm living for almost 10 years in the Netherlands. When I think about AI agents I couldn't remember eight years ago Isaac Asimov, you probably have read about the laws of robotics, right? So that was a simple way that Asimov found to protect the humans from the advancements of robots. So why not we do the same for AI agents, right? So we could simply create three simple agentic AI laws and then we'll be fine, right?
But in reality this works very best on the fiction but on our daily basis it's not how it works. And I will start with some simple prompt, right? So you can see the age of the presenter when we start to talk about Maven, Java and things like that. So that's the only coding that I remember from 15 years ago. Probably there are more modern ways of developing applications these days. But let's assume that in this Vibe coding days you create a prompt like this and you put this on a large language module on such GPT or cloud code etc.
So basically what you want a simple web-based application and this should be four operations, should be using a Java compatible application server. You want to publish this application on this application server. The source code should use a Maven type of structure and you want to store on the GitHub. So what we are just doing here and how the large language module thinks when it's doing this. So basically of course this is a simplified view of how it works. It's way more complex but just to give an idea. So what we are doing, we are sending a prompt typing what we want in the natural language.
So everyone can describe what you want to do. Then the large language module will do a parse of this prompt. It will classify the intent. So in this case the intent basically is to create a calculator or a basic application and then it starts to break it down into deterministic pipeline. I think that's maybe one of the most important thing to think about agent. Because there is a undeterministic behavior which leads to deterministic actions.
So in this case very basic deterministic pipelining, create program using Java, use Maven, store on GitHub, download the application service, deploy and launch the application. So everyone of this action or this deterministic action will eventually call an external resource. So then if it's to publish you can have a command line to publish it to an application server. If it's a download can use a wget command or something. So in the end what the agent will do is use these commands that we usually in our daily base so to say to produce and compose results.
So basically if you look at this there's three steps. It's a prompt, it's an orchestration and the result. Think about on this way. So basically the large language model predicts the most probable next token based on training patterns. If we have a structured instructions or the more structured instructions we have, more predictable will be the deterministic actions. But in reality we cannot expect that a user or a person working with an agent or a chatbot or something will think about a deterministically or very well instructed action.
So then this would be the best word for us maybe thinking in terms of programming or very logically we could think about structured instructions but that's not what happened on the database. How we can look at this? So if we look at the agent anatomy we could think about something like this. This picture is was based on the google scythe model with some specific changes, some additions to this. But basically we have a few elements. So we have the user subject or application sending the prompt or initiating the action with an agent or request something to an agent.
An application in this case can be standalone application or another agent. Within this anatomy we have the input and transformation layer which I just explained. So we have a natural language saying what you want to do and then the agent, the larger language model will translate it into actions. Planning memory that we'll eventually use for the next input to continue the conversation with the agent. Something important, the intent. So it captures the intent of the subject as I mentioned before. So the intent in example was create a web application or something.
Then we have skills described, the capabilities of an agent, tools. So which resource will be used or which external resource will be available for an agent. The content itself, external resources and the reasoning when all these things are happening. So if we look at this, whatever prompt we send to the agent, it will end up on calling an external resource. So then here we can start to think about where we need to put some protection first because we are dealing with external resource. If we don't have data, if we don't have a financial transaction, it's just a normal chat GPT conversation.
There is no need for authorization. There is no need for too much security because you're just talking to chat GPT, asking some dumb stuff and then sometimes respond with a good information, sometimes it's not. But the place where we really needed to protect is in between the agent and the external resource. At least that's within the organizations that what we are trying to protect. Organizational assets, data, user data, financial data, etc. But in this model, what can go wrong? Every component of an agent, from what it hears to what it knows, is a potential attack surface.
Malicious input via prompt injection can lead to a wrong or dangerous deterministic action. And finally, I think that's also important, there are too many points of failure, but it doesn't necessarily need to be intentional. That's what we need to be prepared for.
Of course, there are hackers and malicious actors that will use this to breach data in an organization. But considering that it is indeterministic behavior, I just put in a prompt that I expect a result and it ends up on some wrong or unintentional action. I think everybody heard about someone that deleted all the emails from their own mailbox just asking an agent. I think someone from Meta or Google did this.
Also, what can go wrong? So we have this recent example from April, AI code agent deleted entire company database in seconds. And last week, also I was I come across some scenario where an attacker inject a prompt using Morse code to a grok bot and it end up that a transfer of $150,000 in cryptocurrency from one account to another account.
So it was, of course, intentional, but it surprised how the attacker thought about the prompt, right? Basically injecting a Morse code to a prompt and it lead to transfer money from one account to another account.
Okay, so what are the challenges then? So I list six challenges that we have now when we try to protect the agent or to work with agent security. One is the lack of agent taxonomy. There is no defined method yet to define agents. There's some initiative to create a taxonomy based on the level of interaction of a user with an agent. I read about some five or six level. I'm basically at the moment using three different levels of user interaction, so which gives three different categories. We have an agent basically which is act fully autonomous. Then we have an agent it act like assistant.
The agent to produce some outcome, it needs the final user approval. And then you have another category which is basically the human oversight. So there is not too many human interaction, but at least there is someone looking at what the agent is doing. So just to differentiate these three agent category. Delegation and act on behalf. I think this is the most topic that I've heard in this conference this year because this is critical, right? So the agent, regardless if it's human oversight or fully autonomous, in the end, the outcome will be produced to someone.
So there's someone involved in this context. Agent lifecycle, another critical challenge which leads more or less to the non-human identity. It's if your organizations are not really managing the lifecycle of non-human identity, how this organization will manage the lifecycle for agents. So that's another critical challenge. Also to have the right to work with agent for agent lifecycle. Dynamic behavior, I just mentioned. Authorization, it's also very difficult considering the dynamic behavior and the need of the context. And of course, the last but not least is scalability.
So everything that we have been doing so far in terms of identity and access management is very far away from the number of agents that is expected. So if you work more on the employee workforce side of identity and access management, we have a very small number of identities. We can think more about the consumer identity, which is millions of users, but eventually in terms of agents, we are at the scale of billions and everything. So this is very complex in terms of what to manage. So what to do? What's the role of identity and access management? Which capabilities are essential?
And the most important question is the current modules designed for non-agent key era is able to support agent key. I want to go quickly into scenarios just to explain very basic scenario, how it would look like. So you have a first scenario where there is an agent. The agent is called the shopping agent. Then there is a user asking the shopping agent for personalized recommendation based on purchase history. So basically a simple agent commerce scenario. We see a few elements here.
The agent itself, the large language module, which will in the end translate the desire of the user into intent and actions. Then we have APIs and authorization. So what we need from identity and access management, if you simply look at this, so basically we are talking about user authentication, consent management, OAuth, client authentication and authorization. We have one more complex example where there is an agent. It's a book pricing agent or procurement agent that needs to interact with a buyer agent to provide some some book price or whatever.
And then interact with the buyer agent to confirm a purchase. But then the purchase needs to be approved, finally approved by a human buyer or human entity.
Again, if we look at this, it's pretty much a B2B scenario as we are used to today in terms of identity and access management. The difference is now we have an agent and we have all those complexity, the undeterministic behavior. But still we are talking about user authentication, OAuth client authorization, push notification and everything, which is something that we usually do. So we have two scenarios, one pretty much consumer identity, another business to business. But we still need to talk about the non-human element, because in the end, the agent is a non-human entity.
It's a non-human, but sometimes with a human behavior. There is the scale problem. And here I think this is another problem that we have seen now. Every time we talk about AI agent security, we tie to a non-human identity. So if we just tie this to a non-human identity, we will end up into a privileged access management program or whatever. But we are missing the requirements from the CM or the B2B or the workforce if we want to provide agent commerce. So we cannot just look into an agent as a non-human and say this is a PAM problem and not a CM or a workforce problem.
And we still have the data element. In the end, we are talking about data. So then in most of the case, or at least that's how the standards are moving, we'll use MCP, the Model Context Protocol. Then the MCP proposes some authorization model. But who knows? How can we ensure that everybody within the organization, development agent, developing agent will use MCP? What if a developer, instead of using MCP or APIs exposed to MCP, decide for whatever reason to call that database directly, use a hard code credential inside of agent?
So we are back again to the same problem that we are having with non-human identity and privileged access management. And then we have the standardization problem. This is basically what we are doing, fix on the fly. So we have at one side the group or our colleagues that say let's use OAuth, a widely adopted protocol. Then MCP proposed OAuth. Then the standardization body create several other extension and RFP to support OAuth. But then someone say, oh no, OAuth is not a good fit for MCP. Let's build something completely different or something else. And then there is this AOuth protocol.
So then basically, we, organization, consulting firms, try to advise the client. We are in the middle of the situation where we don't have a standard or at least a standard that is fully agreed by everybody. And then we need to advise on these things. My time is flying. I will move to this slide. So how I see this on our daily basis or for you, to scale AI agents within the organization. We need a baseline. And the baseline starts with the strategy.
So if you look at the traditional way of implementing identity and access management, usually it is siloed within organizations between the three or four domains. Or have your workforce, you have a PAM program, you have a CM, and nobody talks to each other. So basically, what we are talking here, in some other words, is the identity fabric. So we need a way to think about the required capability. And in the scenario that I present in the example, I just highlight a few capabilities that are required from all these domains.
So we have the core capabilities, authentication, authorization, CM, workforce, life cycle management for agent life cycle, and the non-human identity, least privilege. So it's all from all capabilities. We have as additional required capabilities that I'm putting three different pillars, observability, human control, and limited power. So that's what we need to look.
And finally, a proposed identity for AI blueprint, where we combine in different layers all the identity and access management required capability, plus the agent registry discovery age life cycle capabilities, the agent gateway to enforce authorization, and the authorization itself, not only on the token or OAuth type of authorization, but on the data authorization. I think it's important to look at data classification and data authorization. And you cannot forget the support with visibility of observability and cybersecurity. To finalize, one minute for 30 seconds for practitioners.
I think the most important is enforce security by design in the agent. We need to have a security practice to develop the agent safely. For leadership, one of the most important is that buying a new tool might not solve your problem. And to take back home the million-dollar question, what extent is your young environment and operating model developed to support agent-key AI? Thank you.
