Hey, everyone. So nice to be here again. Always a pleasure to speak in front of this audience. And today I'm going to speak about AI, well, security for AI, obviously. So I thought about how to do this session, you know, in a more maybe interesting way, not just to pitch. And I came up with a series of questions that I want to present in front of you and answer at least some of them, maybe not all of them, because currently what I see, there's a big noise in the market when it comes to agentic security.
And everyone is speaking the same type of language and you need some tools to distinguish between what are your true objectives and how you're going to achieve them. So I want to share with you some of those questions so you can ask yourselves what do you want to do when it comes to agentic security. And the first question is why do we even need to talk about that? It seems obvious, right? It seems very obvious.
Obviously, this is a hot topic. We need to talk about agent security. But why? Why is that so important?
So, you know, Jason just shared with you that identity is the security perimeter. And I absolutely agree with that. But what I want to add that now is your opportunity to actually take control before everything gets escalated. When we had to secure human identities and even machine identities, we had to come after the fact. But this doesn't have to happen with agent security, right? Because now your organizations are trying to define and build the methods and the infrastructure to actually secure those agents.
And you, as security and IEM leaders, that's your time to put controls in place to begin with and not after the fact. And that's the reason we need to talk about agent security. Not just because they're there.
Obviously, they're there. And everyone's moving very fast with agent security. With agents in general. But you need to be there at the beginning to put those controls in place.
So, my first question is, why are agents so different than humans? Okay?
So, we have our human identities, which we try to handle for a long time. And we have the machine identities. And I'm arguing there's also agent identity, which is slightly different. Let's see why.
So, first of all, humans are predictable. They follow a different set of boundaries than any machine or obviously agent. We know what they do. We can see. We can govern. They ask for an explicit request when they want to act. And eventually, we can come to them, to our human identities, and ask questions. They can be accountable for what they are doing.
Now, looking at the machine identities. Machine identities or service accounts, right? They follow a very defined path of action. They know they are defined to work from A to B. There is a very well-defined path. Right? Even if they are not accountable, but they are predictable. Because they were programmed in a certain way to follow that specific path.
So, their boundaries are already set in the activities they are designed to do. And typically, they have kind of a fixed scope in which they operate.
So, we have our human identities, which are accountable, and we can see what they do and they act very specifically. We have our machine identities, which are predictable, set to follow a defined path. And now comes the agent. They are different. Why are they different? Because their path of action is not predictable. It is not predetermined. They are actually trying to please us. They want to do whatever we will ask them. And if they have the ability to access tools, data, services, whatever, they would do so. That's how they are designed to operate.
They are designed to take whatever resource is available in order to achieve their task. They do not follow a predefined path, but they actually try to find the right way to get whatever they need. And we need to understand that's how they operate.
Because, again, if they have access, they would use it. They are not accountable in any way to what they do. They are actually trying to do the best as they can. And that's a change in behavior we need to understand. And eventually what happens is it creates a control gap. Because the way we used to control identities up until now, maybe, is not really the right way to control those agents. Those agents that operate dynamically, and they are built to please whoever is acting them.
Also, remember, agents, they can create other agents and other agents. A single agent can create, on a second, 1,000 more other agents. And we need to remember that behavior when we think about how to control what they do. So that's one. The difference between human identities and agents. The second thing we need to consider is the numbers, right? Humans are no longer the majority of the identity.
Now, many of you have been in the space for quite some time, and you were trying to control human identities. Did you succeed?
Well, maybe, to a degree. We are still trying to govern, manage, understand what human identities can do. I'm still speaking with customers that are trying to tackle that identity governance challenge. So it's not fully solved.
Now, think about the amount of human identities, the amount of employees or partners or external users that you have, double by, I don't know, 100, 1,000. We have all kinds of statistics. And now all those new identities are operating within your premises, within your organizations. They have access to all the data services that you enable them to access. Can we use the same methods?
Well, they didn't really prove themselves day one. So think about if that's the right approach. So we have different behavior. We have amounts. And the third factor I want to ask you about is what are we actually trying to protect? Are we trying to protect agents?
I mean, if you would have an agent walking in the Internet doing whatever it wants, is that okay? Well, I think it is. But if that same agent is trying to access our data and services, trying to take actions on what we have within our organization, is that okay? I'm saying that's the goal you need to consider. That's the end game. So if you think of your control path and try to lay it out here, you need to ask yourself where do you want your control to end? Does it need to end with the identity? With the agent identity? Maybe we need to move a bit further to workflows or services?
So I would argue you need to consider all the way through. You need to consider the end game. When it comes to security, when it comes to protecting what agents and humans can do, you need to consider the end game. And eventually the end game is what data they can see. What can be exposed? What actions can they do in order to, within our organization? So those are the three first questions. We have agents, behavior, at scale, accessing data. That's the equation we need to consider. And now we need to ask ourselves, are we using the right control tools?
Because the traditional approach just tells us what can happen. It cannot tell us whether it is appropriate now. I'm going to use two examples to explain that. Okay? So the first example is an agent operating in my CRM space, accessing data, where a sales rep is asking them maybe to get some statistics about all kinds of deals.
Now, this agent obviously has access to all the CRM, can access deals all over the place from all reps. And the agent will try to get statistics from all the data that is available to that agent, including maybe data that sales reps should not be able to see, because that's how agents would operate. If we are not binding the end user to the agent activity and to what they are trying to access, eventually that's what's going to happen. Data is going to be exposed. Okay?
So we basically, the operation has succeeded, data was retrieved, information was provided, but the authorization was not there. Not in an appropriate way. The same goes for tooling.
Agents, the same agent, that same CRM agent can operate within that space, within our CRM space, and now they can search, they can list, they can send emails, and they can also issue a refund. Because maybe that's aligned with what they think the sales reps want to do. The sales rep would want to maybe please the customer, so the agent would be able to do that. If we are not putting some controls, not just on the human user, but also on the agent in combination with the action that they are doing, then we can lead, that can lead to those all kinds of mistakes.
Now, understanding that, the next question is, what is the right control model, right? We need to provide some answers. So eventually, the right control model is to understand the intent. Probably you've heard about that, and there's a lot of buzzwords in this market going on, but let's understand what it means. Intent-based access control. Understanding intent, control access accordingly. Because intent eventually is the why behind the access. We need to understand why access is happening, why access is happening now. Who are the actors there?
We have a human identity, and we have an agent identity. What are they trying to do? Or whether it's an agent operating with other agents, what are they trying to do?
Remember, there's not always just one identity within that process, and intent includes all actors in the process. Second question, what are they trying to access? It's not enough they are trying to access a CRM repository. Within that CRM repository, what type of data are they trying to access? My US-based account or my European-based account? Are they trying just to retrieve data or maybe they're trying to issue a refund? All those questions are relevant to truly control what they can do.
Also, the here and now. Why access is being done now? Is that 8 a.m. or 8 p.m.? So the context of access is truly important in order to control efficiently. So how can you achieve that?
You know, eventually, just putting a lot of questions here, but some answers should be also provided. Intent can only be achieved with runtime controls. Runtime controls is the method to understand intent continuously throughout the process.
Agents, they do not operate just in a single operation. It's not just opening the door to access the agent. It's opening the door and continuously verifying, approving each and every operation. The agent wants to retrieve data?
Wait, can you retrieve that data? The agent's trying to do an operation?
Wait, can you do that operation? So that is true control throughout the process, and it can be achieved only with those runtime operations. So we understand there are agents with different behavior. We understand they are huge numbers of agents. They are trying to access our most secure assets. We need to control them by understanding intent using runtime controls. So my next question is, how do we do that? How do we apply runtime controls? And that's also a tricky question, because in order to answer that question, we need to understand where agents live, and how are we building agents?
And do you think there's just one answer to that? Well, obviously not. It can't be that simple. So the next set of questions is where and how are agents built and operated in order for us to enforce runtime controls? So I created this map to kind of understand that. I'm finding myself doing a lot of discussions with my customers, and they are asking those questions. And I started with that statement at the beginning. This area today is very confusing. All vendors try to speak very similarly, whereas the vendors that provide those infrastructure for agents, they keep inventing.
They keep providing more and more solutions. One of my customers, as an example, asked me, can you support the Microsoft ecosystem for agents? Okay. Which product do you mean? Microsoft Foundry, Microsoft Copilot Studio, Microsoft 360 SDK, and I can just go along with the list of solutions they provide for agents. And that's why I created this map. You need to understand eventually how agents are built, where they operate. I'll do that very quickly, because I don't have time. So first of all, we have all those frameworks where agents are built.
This is code for developers, or maybe now not only for developers, but anyone who can use a copilot. So those are all frameworks. That's where code lives, and that's where control can be applied.
Next, we have all those no-code platforms. That's where code cannot live. And there are a different set of controls there as well.
So again, this is just a sample, just to give you an idea, trigger the thought, and understand where your organization is planning to operate. So we have the raw code, we have the low-code platforms, and then where are they operating in production? That's where all those frameworks come into play. We have Azure AI Foundry, we have the Bedrock Agent Core, whatever, and Google Vertex, and many more, by the way. That's a partial list. But now also, a lot of other vendors are also having all those agentic platforms internally, like Snowflake, Cortex, and the Databricks, Mosaic.
Now, why do you even need to care about all those? Because if you think about, first of all, understanding where agents are, and then controlling what they can do, it needs to be suited for those type of technologies. I would say there's not just one way to control agents. I cannot control agents in Snowflake the same way as I would control for the Microsoft ecosystem. And even in Microsoft ecosystem, multiple solutions are there. It's not to create confusion, it's to create understanding. I'll try to publish something around that. That's my plan.
Anyway, last thing I want to say, AI gateways is also in the mix. There are many AI gateways. All of the gateway vendors, like, you know, Kong, Apigee, Microsoft, API management, Azure, AWS, any long list, gateways are also in the mix. Bottom line, there's no one single silver bullet. Can't solve everything. And eventually, you need to lay out the question, what are we trying to protect? How are we operating in our organization? And what's the best way to achieve that? Last question. Too many questions for a 20-minute session. But last question, okay?
So, what are we trying to enforce within that flow? And remember, it's a flow. It's not a single operation. And eventually, when you consider that flow, we want to protect both. What questions can be asked? We don't want everyone to ask all questions. And that would be your prompt control.
Second, data, which is fed into the process. What data can be utilized in the agentic context? The tools. MCP is a big topic.
Last year, I actually spoke more about MCP. Today, I think most of you know the risk with MCP.
Obviously, a lot of advantages, but tight controls are needed. And the last part here is the response.
Also, what we are then sending back to the user. Can the user see all of that? And right on time, nearly. Key takeaways. Those are the questions you need to consider. First of all, agentic demands a new control plane. It needs to involve intent. And you can take a picture. Okay. Thank you very much.
Thank you, Gal, for the insights. And I think what also I see from the questions that this thing about the intent is a bit, people are still struggling to understand it. You said it now, intent-based access control.
So, I'm also wondering if we have now IBAC or whatever. So, the next back that we have.
So, one question was, when agents access data, they do it by actions, read, write, delete. Intent comes down to control these actions. What's the point with the intent?
Finally, I need to create a runtime policy based on the actions, like read, write, delete. So, what is the intent?
So, maybe people are still struggling to understand it. And maybe you can quickly summarize it and give an idea what it edits. Yeah.
So, intent, the way I understand that, is the context of access. The why behind access has been performed. And this is the relationship between who initiated the process, the agent who's acting, what they're trying to do, and why now. Okay? Thanks a lot. If there are further questions, join PlaneID Outside.
