Setting Security Boundaries for Agentic AI: From Concept to Implementation

Good morning, good afternoon, wherever you are in the world. Thanks for joining us today. I'm John Tolbert, Director of Cybersecurity Research here at KuppingerCole, and today I'm joined by Gal Helemski, a CPO and co-founder at PlainID. Welcome.

Thank you, John. It's excellent to be here today. Happy to talk about this important topic.

Yeah, I'm excited for it. It's one that that everybody's talking about these days. It's an important consideration for security.

So yeah, we're going to be talking about how to set security boundaries for agentic AI. Yeah, absolutely. I think this is a topic many organizations are currently struggling with, and we'll dive right into that. Yeah. So a little bit of logistics info here. There's no need to mute or unmute yourself. We're going to do several poll questions throughout the webinar, and we will talk about the results as they come in or maybe at the end. We're going to take questions, so feel free to enter your questions in the control panel at any time.

You'll see a little tab down there for questions, and we will try to take those as we go. Also, we'd like to make this interactive, so feel free to submit questions and get us talking. And then lastly, we're recording this, and our slides are really placeholders for the discussions. They're not too terribly technical, but the slides will be available, and so we'll be recording in just a couple of days.

So yeah, with that, we're just going to have a discussion today. We'll talk about the poll results and definitely encourage you to participate and do Q&A as we go and wrap up with any questions that remain at the end. So let's just dive right in. So what is it about agentic AI that's going to force a change to the security models that we have today? I thought it might be good to maybe mention a few of the different kinds of AI agents that we see in the wild already.

You know, we've got the nearly ubiquitous chatbots, you know, conversational AI assistants, which, you know, can be useful to some degree. We have help desk or tech support agents that are out there, procurement agents, sales and CRM agents, you know, financial analyst agents, document processing, voice assistants, legal assistants. So there's a lot of software solutions that are already embedding agents that can be used by both consumers and business users. And each one of them needs to have a scope of what it can do.

You know, they're intended to act on behalf of people, you know, to automate things, to speed things up. But here's where I think it starts to get different. We can't really treat these AI agents the same way that we treat the associated human user that, you know, is behind that agent. What are your thoughts?

Yeah, absolutely. I think the main difference and it's very important, you know, to understand that is that agents can make decisions by themselves. If in the past, we had to code an application and there was a very defined, predefined platform starting to end, today, that's no longer the case. With agents, we know how we start. We start with a prompt. But then what happens next, it's up to the agents to decide whether to go left or right, up or down. So the path of action is not predetermined. It's undetermined, actually. And that's where the security model changes.

We cannot bind, like in the past, we cannot bind the path of action to something which is very static. Because the path of action is actually dynamic. It is decided as the agent continues to operate based on what it was requested to do. So it makes access decisions over and over again and makes a shift accordingly, based on what he thinks is the right way to move forward.

Therefore, we need to consider that way of work when we apply a security model to address that challenge. Yeah, you know, I think maybe it's important to demystify what agents are and how they behave. Think about how we interact with programs on the web.

You know, we're presented with information, we make our own decisions about how to navigate or how to, you know, start a transaction, authorize a transaction. But an AI agent is a code with a bunch of if-then statements, more or less. So the agent is getting presented with all of this information, you know, maybe the same kinds of information that we as users might see, but you're trusting it to make the right decisions when these if-then situations come up.

So, you know, we need to be sure of what, you know, as reasonably sure as we can be about what the outcome of how it's going to handle these kinds of situations where it has to make a decision on our behalf. Yes, absolutely. I agree with what you just said. We need to also remember that agents are designed in a way to please us, right? If we're asking the agent something, they will try to do that. They will try to do the best of their capabilities.

So, you know, if we can take an example from the real world, if I'm asking a junior associate within my organization to do something, they will try to do that, but they would acknowledge defined boundaries. Like if there is a locked room, they wouldn't try to go inside. They wouldn't open a door which they shouldn't be trying to open because they acknowledge unspoken boundaries in the human world. Agents are not operating in the same way.

They are trying to do whatever they can within their reach to answer what we asked for, and they are doing that on behalf of us because we asked for that task. And again, this is something that we need to understand and acknowledge when we are planning to define a security model there.

Yeah, I think we're going to see the need for changes in some of the security tooling that we have today. Everything from, you know, IAM with an emphasis on ephemeral identities, non-human identities, because really an AI agent is just another kind of an NHI.

But, you know, I think we're also going to need to see changes in things like EDR, XDR to become, you know, truly AI agent aware and how does it, you know, how do you change these security tools in a way to be able to understand the context of what agents are doing, maybe to be able to infer the intent of the agent and realize maybe there's an agent that's gone rogue or something that needs to be alerted about.

I think, you know, we've been saying for many, many years that we've got SIEM and SOAR tools, you know, for the very purpose of being able to collect audit logs and try to figure out what's going on there. But I think that's really going to change the more agents that we see operating in the wild to become AI agent aware. Mm-hmm. Yeah.

And, you know, to continue on that statement that you just shared, another thing we should acknowledge is that agents, they do not operate in a separate, you know, in a single universe, right? They operate in groups. And when we are, we like to talk about agent, but really we need to talk about I-GEN-T-K-I, which is a collection of agents, not just a single one. And in order to carry out a task, it's multiple agents that are typically involved, right? We are asking to form this agentic flow to do something. And there are all kinds of separate agents acting on behalf of us to do their tasks.

So going back to that observability and existing security tools that have the detection and response and observability and so on, now we need to kind of collect a set of activity in order to represent starting to end results. So we might have that in the past to a degree, but now it is much more expanded. And we are talking about other level of magnitude in the operation components that participate here. So let's take our first poll question. What concerns you the most about deploying AI agents in enterprise systems? Polls are available here on the side. So which one is it?

Is it excessive data access, misuse of API or tools, unintended workflow execution, lack of visibility and auditability, or maybe you don't see any significant risks for AI agents just yet? Mm-hmm. That's actually an interesting topic. I'm speaking with a lot of my current customers, and it's interesting to understand what are they concerned about. I would say the most or topmost concern is definitely around data. Data was challenging to protect even before agents, and now with agents it's even more challenging.

And the majority of discussions, at least I'm having with my customers, is around excessive data access or data exposure and how we are preventing that. Because it doesn't make sense to create agent per data. Maybe that was a method of the past to create different siloed access paths per data set and control it that way.

Again, this would not apply anymore in the era which we are at, and certainly not for agents. So agent is designed to have that access to large amounts of data. What do you say? Do you hear the same thing in the market?

Yeah, I think, and I think it's reflected here in the answers already. Right now we're sitting in roughly 40% each on excessive data access and lack of visibility. I know one of my top concerns, maybe just because of background, has always been the data access governance piece that you mentioned. Interesting to see that lack of visibility and auditability is right up there at the top too. Yes.

Yeah, we see misuse of APIs at 13% and unintended workflow execution at 8%. And nobody says that they see no risk at all. I think that's pretty realistic.

Yes, I will. I would agree. Absolutely. It's nice to see those results.

Okay, so next topic, when agents go wrong, what is the real risk pattern? I like this quote here, you know, agents don't go rogue, they do exactly what they're allowed to do.

You know, that's really spot on because, you know, we were discussing before we started about cases where maybe an organization tries to load up an agent with tokens or entitlements that sort of give it the full gamut of what the associated human user can do. And of course, that can be problematic. And it also sort of goes against the long standing tradition we have in IT now of zero trust and implementation of the principle of least privilege.

Yeah, absolutely. I think this is absolutely important to apply also here, least privilege or zero standing privileges when agents operate. And I agree with you also really like this statement.

Agents, they do what they can, what they are allowed to do. They would not try to do something which they don't have access to, they would do what they are allowed. So there is a very familiar security exposure or security incident, I would say, where an agent closed a lot of support tickets, and maybe some would say accidentally closed a lot of support tickets, but not really accidentally, right?

It had the access to do so it had the access to I think it was a service now it had the access to service now it was allowed to close support tickets, and it decided in the because of efficiency, right? It wanted to be very efficient. So he just looked at all those support tickets that are standing open for a long time, and it closed them.

It shouldn't have done so maybe, maybe certainly not on behalf of what that user and user he was working on behalf, but again, if they can do something, they will do that they will do that because they are designed to please they are designed to find the best outcome outcome to their best capabilities, right? So we need to be very, very strict with what they are allowed to do and what they shouldn't be allowed to do.

As an example, in that use case, if this was an autonomous agent, then maybe if the agent is not operating at the moment with an end user tied to its operation, it shouldn't be allowed to close tickets, maybe just to view tickets, maybe just to send recommendations, and we can actually do that. We need to bind the intent of operation to the actual outcome.

Otherwise, that's where the risk is in that gap exactly, that the capabilities the agent has in which is not tied to what they should be doing at a point of time. And that's the risk pattern I see just growing over time when the agent usage would grow as well.

You know, there are some other considerations, you know, that many of us have probably heard about already, but things like prompt and objection attacks, and, you know, the agent was too broad of a scope, which is what we've been getting at here, you know, being able to limit the agent to what it really only needs to get its job done. And then to be able to go back and prompt the human in the loop for decisions that might, let's say, involve a transaction limit, and then operate autonomously, but within the right parameters.

So yeah, I totally agree with that. Yeah, so I think this slide, I like to use this slide, it's to explain where controls are lacking or the other way around where you should consider adding controls. This is a very high level view of an agentic flow, but I think it represents very accurately how the agentic flow operates. It does so over, simplified, of course, but it represents even the most complex flows as well. So every agentic flow starts with a prompt, that's where we insert the request or, you know, whatever we want the agent to do.

Then there is probably retrieval of data to support that request, all kinds of technologies involved in that process. Then the LLM can decide to utilize MCP tools, most probably, or direct APIs. And at the end, after all that processing is done, there is a response. We identified, or the market has identified, four control gaps that you should consider. And it starts with the prompt. First of all, in the prompt, users can ask questions, or the agent can ask another agent to do something, and we need to control that. We need to control the request to the agent.

We cannot have anyone asking any question. Let's say this is an organizational agent, and someone from engineering is asking a question about the financial outcomes for the next quarter. Does that make sense? Maybe we shouldn't even go into data retrieval if we understand the question should not be authorized. So that's the first place where you should consider adding a control, control the prompt. And it's not just prompt injection.

It's also the actual prompting itself, which is a valid prompt, but not in the context of the current operation of the end user, of the agent, of the overall situation. The second gap relates to data. Data is always being pulled by the agent. So what data can the agent pull? Can the agent pull all documents, access all databases?

Obviously, the answer is no. Even here, controls should be set in order to define what documents or what data, structured data, can be pulled into the process, can be pulled to be utilized within the process. Going back to the previous question, I'm asking about business results of next quarter, but maybe I'm an account executive based in Europe and I shouldn't have visibility to all those business reports from China or from the U.S.

Again, I need to have access to business reports, but not to all of them, business forecasts, only to those within my region. So the agent should not have access to the reports. The user who's operating it should not have access as well. The next control point is, of course, in regards to the MCP tool.

So MCP, I think everyone here probably knows or heard about MCP. It's a very common way, a standard to access tools by the agent. It has become, I believe, widely used by many organizations and vendor companies to expose tools, to utilize tools. So it's very easy to do so today. We need to control that. When something becomes easy, it also becomes much more risky. Need to control what tools can be used.

Now, remember, it's not just about the tool. It's also what the tool can do, what data the tool can expose. As an example, you know, Jira exposes an MCP server like many other vendors. I'm just using this as an example. You can actually use a tool to get project information. Maybe the agent at this stage has the authorization to use the tool, but maybe not to all projects, maybe just to some of the projects. So we want to control not just the usage of the tool, but also the internal attributes or the parameters of the tool itself. And the last part here is the response.

So after that processing is done, a response is being generated, sent back to the user. Maybe the response contains PII data, privacy data, sensitive data, data that should be masked.

Now, this is the fourth control point you should consider. Eventually, you can pick just one or two, but if you want overall coverage, end-to-end coverage, remember the process is segmented. You need to consider all of those four control points. You need to consider blocking unauthorized questions, controlling access to data, controlling access to MCP tools, and masking the response.

You know, I like this because I like how you've broken down, you know, four major areas where you can apply controls. You know, and I hear a lot of people talking about AI agents, and to me, it almost feels like the dismissively gloss over and say, put guardrails on it.

Well, what does putting guardrails on it mean? And I think you really started sketching out an answer here, especially if you look at the prompt side.

You know, what is the input guardrail? And that's trying to figure out, like you said, is this something that we should even pass forward, or should this be dismissed at this point?

You know, is it appropriate to be more or less asking these questions or trying to, you know, complete a certain action? So, the guardrails, I think, can be both up front and then on the output side, too.

You know, filtering responses, making sure that the output is, you know, within policy parameters. But then also, you know, on the data retrieval side, I think, in order to avoid things like model poisoning, we need to allow list data sources.

You know, the RAG should not be so completely open-ended. It should be scoped to whatever is appropriate for the context of the types of requests that are expected to come in.

And here, again, is a way where you can put some guardrails around how it might execute going forward. But, you know, if these agents are not scaled back, then I think that's where the opportunity for them to go awry arises. Yes. And to continue one other statement that you mentioned, guardrails. Guardrails are commonly used in the agentic space. I just want to point out that the majority of guardrails today are operational guardrails. It's not sufficient. You should also consider security guardrails. Okay?

Remember, agent operates within the boundaries which you set. It's not sufficient to set operational boundaries. Security guardrails that are designed based on those policies are also important to implement. I agree. So probably the most important word I think that we can use with regard to AI agents and security is authorization. And I think we've been saying for a few years now that the time of authorization has come.

But with agentic AI, it certainly has to arrive because it's not about, I mean, yes, there's the notion of authentication and we need to authenticate both the human users very strongly when they're coding up their agents, but also the agents themselves need a degree of non-interactive authentication. But really, it's about the authorization here and what can the agent do? What should it be allowed to do? And then how do we represent that in a meaningful way such that we can have more control over what the outcomes are? Yeah.

Again, I absolutely agree with that. Authorization is opening the door. It approves who you are. By the way, it defines the who both from agent identity perspective and from end-user perspective if one exists in the process. So that's not sufficient. Maybe in the past we relied a lot on the authentication and in some cases it was okay, but not in the agentic flow, not when agents can take decisions by themselves. Agents take decisions based on what they can actually do and any decision is the right decision.

But it's only if the boundaries are not defined correctly, then that's where the risk is there and the exposure is coming. Okay, so we need to consider that as well. Think about zero standing privileges. I think that's like a top goal for anyone who's implementing security for agentic flow. Zero standing privileges. Authentication would just authenticate the user, would just say this is who the user is, end-user or agent user. It does not carry authorization decisions. Why?

Because authorization needs to happen in real-time, in the context of the operation, in the context of what data is trying to access, who's trying to access the data, why this data has been utilized into the process. So that's how you should consider authorization, to reduce the attack surface or to reduce the damage that can be done based on this statement. Authorization is not just the critical control plane for agents, it's the security control plane. You should a consider authorization eventually as a security decision.

It's not a matter if to implement yes or no, it's whether to have security, yes or no. That's what authorization is in the agentic space.

Yeah, you know, I think if you go back and look at how we've done authorization in the past for environments where it has been explicitly called out and not just left up to authentication and kind of hope for the best after that, you know, think about, you know, the old architecture of policy enforcement point, policy decision point, you know, the user might log into an application and then they've got permissions that'll be evaluated when they hit the policy enforcement point by the policy decision point.

And then, you know, they probably have a wide set of entitlements, you know, within a given application. But when you think about AI agents, you know, ideally we're looking at making an authorization decision for each action that the agent attempts to make. That's why, you know, we've said already and we'll probably say it again, you know, keeping the scope just as narrow as it needs to be for the agent to accomplish its tasks is really paramount.

So, yeah, authorization, I think we will see the need for more well-developed and fully implemented authorization systems the more AI agents start to proliferate, which they already are. Yes.

You know, one other thing is you talked about MCP earlier, that's another place where authorization can come into play. That's the part that understands, you know, where data lives, what agents might be able to retrieve.

So, this, the AI agent architecture introduces need for additional kinds or additional places where authorization needs to happen and other data sources that authorization engines need to consider. Yes, absolutely. I agree with you.

It's, if we consider how MCP makes a very easy path to utilize tools, absolutely, this is another important area to apply authorizations as well. Next poll, nice.

Yeah, once an AI agent is authenticated, how is its access typically controlled today? Is it by static roles and entitlements, inherited access from a human user, hard-coded logic in the app, dynamic policy-based authorization, or we're not really sure.

So, yes, feel free to take the poll and we will talk about it. Yeah, I think that's also an interesting question. I experienced at least that with my customers.

So, let's talk about point number two, inherit access from human user. I mean, people tend to think that can solve a lot of the challenges we are talking about. Let the agent inherit access from the human. The human access is already defined, solved, problem solved. Let's move on, right? I think it's very challenging to rely just on inherit access. Why is that? First of all, because we are seeing autonomous agents, not necessarily he would have a human there executing the agent itself, right?

And authorization access control should be considered also when the agent operates by its own or operates on behalf of another agent, right? The chain of agents.

Second, whenever we are talking about inherit access, delegated access, whatever, federation, we have a lot of terms to describe that pattern. Eventually, it all relies on having a well-defined, well-implemented authorization mechanism at the source of data or at the source of tools, APIs, whatever, which is not always the case. We struggled with that for years, having those controls in place. If you have everything already set and perfect, then maybe, fine. But according to my experience, it's not always the case.

You don't have your identities well-defined and well-managed and true authorizations implemented at all the data sources, at all the applications, at all the whatever tools and APIs. So, I would say that you can't rely just on that. When it works, it works. But it doesn't provide full coverage.

And still, it is our top vote in the pool. Nice to see that.

Yeah, I think, you know, with emphasis on the word today, people are answering based on how they believe agents are authenticated and authorized today. And, yeah, I think it is probably either inherited access or maybe static roles and entitlements, even. But the better answer that we're pointing to already is dynamic policy-based authorization. I think that's the future.

But I think it may take a while to get there because people may not realize the dangers associated with just trying to let the agent act as if it is a human or thinking that, you know, static entitlements will get the job done. Well, they might get the job done, but they might get more than the job done, if you know what I mean.

So, yeah, the results, 45% inherited access from human user, 32% dynamic policy-based, 13% on static roles or entitlements, and then only about 6% on hard-coded logic or not sure. And not sure is definitely a valid answer here. Yes.

So, our next topic, static controls versus dynamic context-aware authorization. You can see where we're going with this. Agents operate in real time. Access decisions must also.

Yeah, absolutely. I think we touched a bit on the topic, but let's expand on it here now as well.

So, static controls are what we used to rely on. This is the traditional way of identity and access management. Let's pre-populate, pre-provision, define in advance, and let the application do what it understands it needs to do based on those predefined controls. This is no longer sufficient for agentic error. It doesn't work. Just the bottom line doesn't work. You cannot rely on static controls, predefined controls in your agentic flow because, you know what, just ask yourselves those questions, who will make the decision? Let's say I am relying on static controls, okay?

So, static controls means I'm going to have all those groups, roles, attributes, whatever, predefined and maybe submitted in an authentication token. Okay. Who's going to make the decision? Whose responsibility is it to make a decision whether the agent can now access this document or can access this tool or can do this operation?

The agent, we already spoke about why agents cannot make those decisions. They are designed to please. They are designed to do whatever they can. They would not apply boundaries for themselves, right?

So, static just doesn't work here. It needs to be dynamic. Not only dynamic. Dynamic is not sufficient as well. It needs to be context aware.

So, you need some solution, and yes, there are solutions in the market as, for example, that you need some solutions that can understand the context of access. The agent itself, the end user, if it exists, what is being tried to do, what data the agent is trying to access, what tools they are trying to currently utilize, the overall context, even day, time, location, whatever, right? Everything needs to be there because that's how agents operate. An agent can decide to go left or right now in a millisecond type of decision because that's what he thinks he needs to do.

And if he thinks he needs to do that, we need to support it with the right level of decisioning and enforcement layer. And that's only dynamic and context-aware authorization. What do you think, John?

You know, when I was preparing for this, I started thinking back in terms of, you know, again, PEP, PDP, how do you implement this? And, you know, some of the things I was thinking of here were, if you look at a token, I mean, the way we have become accustomed to looking at tokens is that they represent a human user in most cases. But we need to learn how to decouple the token lifetime from the authorization process itself.

So, I mean, just because an agent or a person arrives with a token, that may be good for granting, you know, one-time access, regardless of what the expiration date or time is on that token. And another thing about, you know, our older authorization architecture is decisions tended to be finite.

You know, you might make a request, you might get a response from the PDP that says, yes, this user has access to this resource. And it may not have been bound, you know, time-bound. But I think, you know, bringing back the notion of revocation as a way to maybe deal with agents presenting tokens, being able to apply logic at your application or your PDP that says this decision is only valid for a certain amount of time, regardless of how long the token lives.

Might be a way to, you know, put some boundaries on what they could do and force us to sort of move into this dynamic policy-based authorization world, even though some of our older applications aren't really designed to do that. There's ways we can add logic at different places in the authorization process to kind of help us deal with, you know, heritage solutions that are not AI agent aware yet.

Yeah, I agree with that. I think you touched a very important point. There are some applications which cannot apply those type of controls, but agents are greenfield. And that's important because if in the past it was very challenging to go to an application and ask the application to change, that's a very difficult request.

Here, at this point of time, you don't need to ask your agents to change. You only need to enable them access to sufficient security capabilities within the development framework they are working in, right? It's not out of scope. It's not do more. It's use what is there or, you know, what you're adding to as security tools in order to implement controls the right way, rather than trying to rely on all those static controls, which, again, are not sufficient. And another point you made, John, about PDP and PIP and all those three-letter language we like to speak of.

Anyway, it's important in a way to understand that when we talk about dynamic and context aware, two elements are participating here. One, what we call PDP decisioning. There needs to be a decision. A decision provides the dynamic aspects of what's happening. And then there's also the PEP, enforcement, right? There needs to be enforcement. It's not just enough to have decisioning without enforcement. It must have enforcement, but enforcement needs to be tied to decisioning.

So implementing dynamic context-aware authorization, besides having those policies in place, you need decisioning and you need to consider enforcement. There are many ways this can be done. This is not a new area, right?

Of course, there are many new solutions, but it's not a new area. So a lot of information can be found and solutions in the space. We have a couple of questions that have popped up here. Why don't we take a look at the first one that I see? Probably last in, first out. What about fail-safe authorization flows for agent access if a specific case has not been properly mapped?

Yeah, I think that's exactly what we're aiming at right here. Like we were talking about guardrails, early input filtering, trying to prevent something that shouldn't be authorized from getting into the flow in the first place.

Yeah, I agree. And on top of that, I would say typically the way a dynamic context-aware authorization operates, it's a white listing type of approach, which basically means to begin with, you have no access. And now let's start adding up what access you should have. So you can access, if you are an agent that operates in a space, let's say in HR space, you can have access to HR documents and to HR-related tooling. So utilizing this method to begin with, you have no access. And then approved policies, define what access you do have, reduces nearly to zero, I would say, those type of exposure.

But obviously, policies, you should govern your policies, you should make sure they are properly defined and properly implemented. So next, intent-aware authorization, keeping agents on mission. And there's a nice quote here, intent without enforcement is just hope. We don't want to hope in security, we need to enforce, right? Exactly.

So again, not to keep going on about PDPs, but it's kind of the model that I'm familiar with. And I think it still applies, but how can you get a PDP to understand the agent's intent? Are there any mechanisms for that? Or are we just hoping?

Yeah, well, we shouldn't hope, we should act Yeah, well, we shouldn't hope, we should act and enforce. A PDP is an engine, an engine that has the good PDPs, let's say they have the ability to digest existing information and make decisions accordingly. What do I mean by existing information? So information, think of a person who's trying to access a certain country. At the border, he's been asked a lot of questions with the border control, they are trying to understand the intent of why this person is trying to access a certain country.

So there's a list of questions with answers that according to that, the decision is made whether this is a go or no go. PDPs act very similarly, they can pull information. It's not just about the identity, intent is absolutely not just about the identity, it's not just about the who, it's also about on behalf of whom, why now, a lot of why needs to be asked here, how action is being done. And it's a collection of pieces of data that is what creates the intent.

Now, the question is, do we have all those pieces of data? In many cases, the answer would be, well, not always, but we do have some pieces of them, and we can grow the data that we are utilizing. You don't need to wait for data to be there in order to start building your policies, defining the intent into that context, and enforcing accordingly. You really don't need to wait for any of that. The PDPs of the world, they are designed to look at whatever information is there, you can build policies accordingly, based on any information, and make decisions accordingly.

Make decisions meaning enforce. Enforce access according to what you do know. If you don't know, you can choose if you want to block access or not.

So, this is really the path should consider. Another thing I want to add to that, I think this is an evolution of access control methods.

So, we spoke a lot about role-based access control, attribute-based access control, policy-based, relationship-based, now intent-based access control. Eventually, when we speak about a term, we need to understand what is behind that term, right? And intent captures a lot of context into a decision, which you can say the same thing, by the way, about policies, but still, it shows what data needs to be captured, what data.

So, it includes who the identity is, it includes what agent this is, what they're trying to access, and why now, why in this context, okay? Yeah, I think that's really interesting to talk about intent. We have problems with insider threat these days that are not addressed by authentication and authorization.

So, this is fascinating in discussion of trying to infer the intent of what an agent might be doing. I mean, I guess I could foresee having been involved with standards processes in the past, you know, maybe some sort of way to define domain-specific schemas around intent that could be passed as a parameter to the authorization engine.

I think, you know, maybe that's an interesting idea that might gain some traction. And if you're not looking forward on how to do that, then I guess really the only way to infer intent would be to analyze past actions, you know, sort of like we've been doing user behavioral analysis for many years to try to figure out, you know, what our normal usage patterns are for human users.

Obviously, we've got to do that for agents now. I mean, is this, do we need agent behavioral analysis? And how does that differ from UBA? And will that be sufficient, or does there need to be a good development effort around understanding intent, and how do you pass that intent along to an authorization engine for decision? Yeah.

So, I'll try to speed up here a little bit. Who do you control, human, agent, or both? You don't secure the agent or the user, you secure the interaction between them. I think that's a really good observation.

Yes, absolutely. We'll speak faster. We have only 10 minutes left.

But yes, absolutely. Consider both agent and user. I keep repeating that throughout this, you know, this chat. I think both should be controlled, right? It's not just one. You don't need just to control the agent. You don't need to control just a human identity. You cannot assume it's always agent acting on behalf. It's not sufficient.

So, consider both, bottom line. Yeah, I think we need to keep doing the things that we know can increase security already, you know, MFA, passwordless for the human users, but then, you know, user to agent binding, the prompt input validation.

I mean, these are still sort of getting off the ground. And then, something we probably need to mention a little bit more here in the last few minutes is the human-in-the-loop approval processes, you know, and some of the standards that are being used for that today, and when to engage the human-in-the-loop.

You know, I've heard others talking about the need for, or kind of a misunderstanding of how agents work, thinking that every time an agent tries to do something on behalf of its associated human user, there will be some, you know, human-in-the-loop decision process where they get involved. But that's not really how these things are designed.

So, at what point do you want to introduce logic that says, you know, if a certain threshold is set, then ask the human for verification? And what is that verification? It's an authorization process.

So, how, at what point do you want to bring a human in to authorize a specific action in the agentic AI flow? Okay, we've got another poll question. These are fun.

So, what do you think your biggest challenge is in enforcing security boundaries for AI agents? Our options are lack of centralized control, too much access embedded in the code, limited visibility into agent actions, organizational ownership and governance, or we're still figuring it out.

I think, you know, looking at the responses, a lot of, a lot of organizations are still struggling with understanding the agent before even understanding what the agent can actually do. It's very, yeah, it's very obvious here.

Also, from the reports and from discussions we are having, I agree, we need to figure out both, though, because, again, we don't want to be, we don't need, we don't, we don't want that to be left behind. We don't want this to be an after-the-fact type of solution.

Agents, agentic space presents a green field from security perspective to implement it right, to do, to do this right from beginning, not later. So, interesting answers.

Yeah, so our results are 39% organizational ownership, 33% limited visibility into agent actions, 17, no, it's not 17, actions, 17, no, it's changing, 15% on lack of centralized control, and 10% we're still figuring it out. Again, a very honest answer.

Yeah, I mean, because it could be multiple factors here. So, governing access to data, APIs, and tools. Every data and tool an agent can use is a security decision.

That, too, is a very valid point. Yeah, I think it goes back to what we mentioned before. Authorization is a security decision. You need to decide if you want to be secured or not. It's not whether you want to implement authorization or not. That's no longer a decision. It needs to be there if security is to be implemented. That's the way I see that. I believe it's very much aligned with what we are seeing today in the market across the board.

All the main security institute, you can see that in various reports, they call out the need for dynamic contextual best authorization to complete the overall security for the agentic flow. So, I think it is very much aligned with the way the market sees that as well. Just need to acknowledge that.

Yeah, I think there's some other tool areas that will probably come to prominence here. LLM or firewalls. There's still a role for DLP or data security platforms, particularly around preventing exfiltration, and this could apply to agents as well.

And then, real quickly, just ITDR. I think having ITDR systems become AI agent aware will definitely help with trying to secure them.

So, we have one more poll we want to ask you about, and that is, what statement best describes where you are today? Active governance, piloting, we're in the planning phase, or we're waiting? We have some interesting votes here. Cool. Yeah.

Right now, we're sitting at, most people are saying planning phase, followed by piloting, and about 12% on waiting. So, it sounds like there's more than just interest. There are people that are in the process of doing something or planning to address agentic AI.

Yeah, it seems like that, but it's good. I mean, anyone who's planning or piloting, that's where you absolutely need to be. At least you need to be in the planning phase. If your organization is currently deploying, implementing, or thinking about doing so with agentic AI, if you are actively working in security, you need to consider how to secure those agents, and authorization should be part of your planning. Agreed.

Oh, last slide here, from concept to implementation, what to do first? Yeah, I think this slide can fill up another full webinar. How to address, how to address, yeah, really in two minutes. First of all, add authorizations to your strategy, not just authentication. Consider what we spoke about here, at least as a guidance to where controls should be implemented.

Yes, there are solutions out there. There are many solutions, actually, out there.

Consider, obviously, what's best for you, but look at solutions that can provide that change from static roles into dynamic contextual enforcement, right? So, you should be looking at those type of solutions, and yeah, I think that's what's important to come out of this webinar.

Yeah, we do have one more question. I'll just quickly answer. Do you see future access by human identities to enterprise data being through agents only?

No, we're still going to have humans. Agents need access to enterprise data.

Yeah, not yet, yeah. Well, any parting thoughts?

No, I think this was a great discussion. The points we wanted to highlight, I hope they came through. You need to consider authorization as part of your overall strategy. Having a security strategy in place without authorization is not having a full strategy, is not really considering the full security of your agentic flow. Everyone today is doing agentic. Everyone is at some phase, and you need to really consider the overall security controls to implement agentic in the way it should be implemented. Do that today. Don't wait for that to be after the fact. Agreed.

Well, thanks. It was a lively discussion, and I hope everyone enjoyed it as much as I did. Please join us for our next one.

Thanks, and have a good rest of your day. Thank you, John. Bye.