Name: How to Manage the Non-Human Insider: Securing the Age of Agentic AI
Uploaded: 2026-09-02T16:30:45.166Z
Duration: 50 min 44 s
Description: How to Manage the Non-Human Insider: Securing the Age of Agentic AI

Transcript for "How to Manage the Non-Human Insider: Securing the Age of Agentic AI": Hello, everyone. Thank you for joining us today for how to manage the nonhuman insider securing the age of agentic AI. My name is Brooke, and I'm on the Exabeam team. We are excited to have you with us today and are looking forward to a great discussion with our field CISO, Finley Whitelaw. If you have any questions throughout the presentation, please feel free to drop them in the Q and A chat. You can find that on the right side of your screen next to the docs tab, which includes some additional resources for you. If we cannot get to your question at the end of today's session, we'll be sure to get back to you via email. And with that, Finley, I will hand it over to you. Thank you, Rick, and good morning or good afternoon depending on where you are listening from today, and thank you for joining. I've called today's session been, how to manage the nonhuman insider because I wanted to challenge one of the assumptions that sits underneath many of our existing security programs. When we hear the term insider threat, we naturally think about a person, the malicious employee, the disgruntled employee, someone perhaps careless, or someone whose account has been compromised. But increasingly, the the identities operating inside our organization aren't at all human. We're introducing AI agents and digital workers that can be given identities, credentials, and permissions so they can access data, interact with applications, APIs, and increasingly take actions on our behalf. So I want to pose a question at the outset. If someone has trusted access to our environments, can interact with our data and systems, and has the ability to act, does it begin to exhibit some of the same risk characteristics that we traditionally associate with an insider? I think it does. Not because the agent is inherently malicious, but because the workforce because it's a workforce now, and therefore, the trust boundary is being pushed. And that's what we're trying to protect because it's changing. So as Brooke said, I'm Finley Whitelaw. I'm the field seesaw here at Exabeam. And rather than spend time going through my my bio, I want to give some context for the lens I'm bringing to this today. Because although we are going to talk about AI agents, this isn't really a presentation about AI technology. It's about something much more familiar to security practitioners. Identity, access, behavior, visibility, and control. And how those things need to evolve when an actor operating inside the environment isn't necessarily human or a person. Now my interest in this subject certainly didn't start with AI. It came from operating in financial services. I previously ran a joint security operation center for a large banking group in The UK, and I was responsible for the twenty four seven security operations protecting one of The UK's largest financial institutions. And across my career, I've also been responsible for areas including insider threat, investigations, data loss. And one of the challenges a lot of organizations face is quite simple. How do we know when legitimate access or activity becomes risky? Because an insider doesn't necessarily break through your perimeter. They may already have an identity. They may already be authenticated. They may have they may be using credentials that they are legitimately entitled to use. And an individual action might not look particularly suspicious. Someone's access file downloads, you know, some data or uses an application, connects with another systems. Those things happen thousands or millions of times across an organization. But what becomes interesting is the context. Has the behavior changed? Is the access unusual for that identity? And has the volume changed? Has the destination changed? And, critically, what happens when you stop looking at individual events and start looking at the sequence? That practitioner experience eventually became part of my research into insider threat and insider risk management, particularly around behavior, trust, and how we identify meaningful changes in activities. And now as a field seesaw, I'm having many of those conversations with security leaders, but we're starting to introduce a new threat actor, the digital worker. And that led me to question, if we already know how difficult it is to identify risky behavior when the insider is human, what changes when identity can act autonomously at machine speed across multiple systems. And that's when I think our existing insider risk thinking becomes useful. But it also exposes where some of our existing controls need to evolve. So what I want to work through today, is firstly, we'll look at how the insider landscape is changing and why the arrival of digital workers changes the scope of the problem rather than creating an entirely separate one. Then we'll look at what makes these identities operationally different. What happens when an agent has credentials and permissions and tools and can actually do things? From there, I want to get much more practical because there's already a huge amount of discussion about governance and principles and frameworks and policy. But, ultimately, somebody has to operationalize all of that. Someone has to answer what identity does the agent have? What can it access? What telemetry are we collecting? And do we know what's normal and what's not? Can we detect when behavior changes? And who owns that agent? And, ultimately, if something goes wrong, who has the authority to stop it? So what I will really want to do today is bridge that gap between CISO level AI risk strategy and what security practitioners need to implement and operate. And I'll finish with a practical control model. And some things organizations can start doing now because I'm not suggesting that we throw away our existing security programs and build an entirely new AI security function. In many cases, the capabilities already exist. The question is whether we've extended them to cover the digital workforce. Because when you look at most insider threat programs today, there's an obvious reason why there are gaps. And the gap is that they were primarily built for people. So let's dive in. When I talk about a digital worker today, I mean an AI enabled agent that has been given some combination of identity, access tools, and delegated authority to perform work on behalf of the organization. Not every chatbot. Not every use of generative AI. I'm talking specifically about something that can operate within a business process and take actions. And once you define it that way, something interesting happens. The questions we need to ask are actually very familiar. Who are you? What's your role? What systems and data can you access? What does normal look like for you? And has that behavior changed? What data are you accessing, moving, copying, or sharing? And if something does concern us, who owns the investigation, and who has the authority to intervene? Now those questions have driven how we've built identity controls, privileged access, DLP, behavioral monitoring, investigation, and response. And I want to make an important point here. None of those disciplines suddenly become irrelevant because the actor is an AI agent. In fact, I'd suggest the opposite. The controls still matter. What's changed is the workforce that we're applying them to. And that's happening at quite a pace. Most organizations I speak to aren't debating whether they're going to use AI anymore. They already are. The conversation has moved to where they're using it, how quickly they can scale it, and increasingly, where they can introduce agents and automation into business processes. And that's where we are beginning to see a gap. The adoption is moving faster than the govern governance and operational control. The exact numbers vary by study, but the direction is remarkably consistent. Organizations are adopting a giant AI faster than they're building the governance and visibility around it. And only around one in five company in the recent Deloitte research reported to having a mature governance model for autonomous agents. And separate research from APTEL found significant gaps in formal governance that even basic inventories of agents and their connections. But the precise percentages aren't really what's important for me. The important question as a security practitioner is, can you tell me today how many AI agents are operating in your organization? Who owns them? What identities are they using? And for many organizations, the answer to at least some of those questions is still no. And that creates an operational problem for security. So the controls that we need to to to look at, we will come on to. And this is and and the insider threats have evolved with AI, and this sits within a much broader evolution of insider risk. The traditional insider hasn't disappeared. We still have careless users, disgruntled employees, malicious insiders, and third parties. But we've already watched that landscape expand. Compromised credentials blurred the line between the external actor and trusted identity. We've seen nation state actors deliberately exploit exploit trusted access. We've seen insider as a service models, supply chain exposure, and risks introduced to, say, mergers and acquisitions. And AI now adds another layer. Some of it accelerates existing threats, and AI makes social engineering more scalable. It makes synthetic identities and deep fakes more convincing, and it can increase that speed and sophistication with which, an adversary operates. But there is another development that I think is particularly important. The AI itself can now become an actor inside the environment. An agent can be given that identity. It's been given access. It's been delegated a task. And depending on how it's designed, it can make decisions and take those actions in pursuit of an objective. Now that's different from simply using, say, chat GPT or Copilot to generate some content. We're moving from AI that primarily assists a human to AI that can increasingly act on behalf of one. And from an insider risk perspective, that creates a new actor inside that trust boundary. But here's the important point. The actor is changing. The need to understand identity, access, and behavior is not. Because when you put a human insider and an agent side by side, there's a very familiar pattern. So if we take the human example at the top here, someone resigns, their access legitimately continues during their notice period. They continue to authenticate normally and access systems they're entitled to use. Then perhaps we see a change, unusual downloads, different timing, increased activity, and eventually, their final day arrives. At that point, a delay in deprovisioning can create an obvious risk window, but think about those events individually. A resignation doesn't isn't, you know, a security incident. You know, logging in during a notice period isn't necessarily suspicious. Downloading a document you're entitled to access isn't necessarily suspicious either. It's the sequence. The change and the context tell us the story. So now if you look at the agent underneath, we provision an agent to perform a legitimate task. Initially, it operates with an expected scope. And over time, that scope expands. It accesses new data sources or systems. Its execution pattern changes. Its behavior starts to drift from a baseline. Again, any one of those actions may be completely legitimate. And critically, in both examples, valid credentials can be used throughout. So traditional authentication controls may tell us who or what authenticated, but they don't necessarily tell us what happened or whether it was appropriate. So for both the human and the agent, the risk may only become visible when we correlate identity behavior contact in context across the full sequence. But we shouldn't make the mistake of saying an AI agent is simply a human, insider in digital form. It's not. There are some important differences. With a human insider, we're often looking for human behavioral indicators, a changing working pattern, unusual access, increased activity. Perhaps we have HR context or other indicators that might help us understand what's happening. But, ultimately, there's a person to whom we can attribute those actions. An agent changes that model. It may be able to take actions without a human making a decision at every step. It may already be operating inside the environment using perfectly valid credentials, and there's no human psychology for us to interpret. So when something changes, the question isn't what's the person thinking. It's more likely to be what objective was the agent pursuing? What context did it have? What tools was it allowed to use, and what caused its execution path to change? Attribution changes too. An action might appear in a log under a service account or application identity, but that doesn't necessarily tell me which agent initiated it, what workflow it belonged to, or who authorized it, or what sequence of detections preceded it. So the fundamental security questions remain familiar, but the evidence we need to answer them changes. And operationally, I think there are three characteristics that security teams need to understand. The first is trusted credentials. An agent may operate using OAuth tokens, API keys, service accounts, or other del delegated identities. So from the perspective of the downstream system, the active the activity can look entirely legitimate. There's no failed login. There's no attacker necessarily trying to break through the perimeter. The second is autonomous execution. Once given an objective and the appropriate tools, an agent can potentially send an email, retrieve information, modify a record, call an API, or execute code with without asking a a human for permission at every individual step. And that's an important distinction. We're moving from AI that tells somebody what to do towards, as I said before, AI actually doing it. And thirdly, is distributed activity. The evidence of what happened may not exist in one place. Part of the story might be in the agent's instructions, another part in its memory, another in identity platforms, or in an API call. So if I'm sitting in a SOC looking for one authentication or event or one endpoint alert, I may only see one fragment or piece of the execution chain. And that creates a very practical security problem. How do we reconstruct what this agent actually did? Why it did it, and whether that behavior was expected. And that's really the principle that connects traditional insider risk with the agentic world. Many agent risks map to familiar behavior inside our behaviors. And accessing information, moving data, using privileges, calling systems, you know, attempting to achieve something outside the expected scope. We've dealt with those security problems for years. What's changing is how those behaviors can now be executed and coordinated. An agent can potentially execute them at machine speed across multiple systems and potentially coordinate activity across other agents and tools. And as I've just discussed, it does it it does that with without any human signals that we've historically reply relied on. So I'm not arguing, that we invent, entirely new taxonomy of insider behavior for AI. I'm saying that we extend the security disciplines we already understand to a new type of actor operating inside our trusted boundary. Identity still matters. Lease privilege still matters. Behavior still matters. Data protection still matters. Investigation and response also still matter. But we have to ask whether the way we've implemented those controls gives us sufficient visibility when the actor is no longer human. And that's where we start to find some gaps. So let's look at this from a from the perspective of somebody sitting in the sock. What we're actually going to see? The first challenge may be authentication. The agent could be using completely valid credentials. There may be no failed login, no unusual source IP, no credential stuffing, nothing that causes the authentication itself to look suspicious. Then look at the individual actions. An agent retrieves a document. That could be normal. Summarizes some content. Again, normal. Calls API, potentially completely normal. So we may not have an obvious behavioral anomaly in a single event. But when we have then we have the attribution. Perhaps the downstream application tells me that a service account made the API call. That's useful, but it doesn't necessarily tell me which agent initiated it, what objective it was pursuing, what prompted the action, or what happened earlier in that execution chain. And then there's, of course, speed. A human carrying a complex sequence of actions might take hours, potentially days. Whereas an agentic workflow may potentially execute a chain of activity in seconds. So our traditional concept of dwell of dwell time can become significantly compressed, And that's why I don't think the answer is simply more alerts. We need to be able to reconstruct behavior across identity, the systems, and time. Ask what happened first? What happened next? What's changed? What's the context? And what was the overall sequence? Is it consistent with that agent and what it's supposed to be doing? In other words, we need to move beyond monitoring individual events towards understanding the execution chain, and we've already seen why that matters. Now this example is well publicized, and it comes from cybersecurity evaluations involving open AI models in the hugging face, environment. And there's an important qualification before I go into it. This evaluation, the the this was an environment that was set up primarily for evaluation. Some of the normal production safeguards had deliberately been reduced so researchers could explore what the systems were capable of. So this isn't just simply a story about an AI spontaneously breaking out of a properly controlled production environment. But what happened is still extremely in instructive. The agents were given objectives that became difficult or effectively impossible to achieve through the expected route. And rather than simply stopping, some agents began looking for alternative ways to achieve that objective. They circumvented isolation controls, communicated to, unauthorized channels, exploited vulnerabilities, and and gained broader Internet access and access third party systems. There was also coordination across agents. Now that's about I find particularly interesting from a security perspective. They weren't necessarily instructed to perform each of those individual actions. They were pursuing an objective. And when the expected route wasn't available, the execution path changed. So if we just think of back to what I've discussed, identity can be valid. The individual system interactions can potentially look legitimate. But when you reconstruct the sequence and the context, the behavior tells you a very different story. And that's the lesson that I would take from this. This isn't really a story about agents going rogue. It's a story about what happens when objectives, constraints, authority, and controls stop lining up. Now governance tells us what should be allowed. Guardrails constrain what the agent is intended to do, but neither on their own proves what execution what the execution path can become or became. And that's why independent visibility matters. We need to be able to reconstruct what the agent actually did across identity tools, systems, and sequence, particularly when expected route changes. So for me, the key principle is very simple. Controls define intent. Behavioral telemetry verifies execution. And that takes us to the next question. What visibility would we need to see in that behavior emerging? And this is when I think the security cape I think security capabilities many organizations, you know, already have, and and that's important. And I want to be quite precise about what I'm seeing here. I'm not suggesting that Exabeam can see inside AI agents and understand its internal reasoning. What we can potent what what what we can potentially see is this security, relevant footprint that leaves in its, interactions within its environment, provided, of course, that the appropriate telemetry is available. So think back to the execution chain. What identity or service account is being used? Is its authentication or usage pattern unusual? Has its privilege or access scope changed? Has it started interacting with a new system or destination? Are we seeing a sequence of activity that is unusual for that identity? And when those things happen together, does the cumulative risk start to change? And that's where behavioral analytics becomes useful because we're not necessarily looking for one malicious event. We are correlating identity, access, privilege, behavior, and sequence to understand whether something has moved away from its expected baseline. And then importantly, for the analyst, we need to con reconstruct that activity into a timeline. What happened, in what order, what changed, and what else is happening around it? So isn't governing the agent itself. What we are providing is an independent security visibility layer around the activity the agent generates across the environment, and that distinction is important. And then that brings us back to the program. I'm not saying that every organization should build a separate AI security program. Some potentially will, particularly where AI adoption is large, maybe highly highly regulated, or centrally managed. Others will extend the security disciplines they already have, and many will land somewhere in between with a hybrid model. For me, the operating model question is secondary. The important question is whether somebody owns the risk and whether the the necessary controls actually cover the digital workforce. Identity governance still has to work. Privileged access still has to work. Monitoring still has to work, and DLP still has to work as does instant response. They may be accessing the same data, the same applications, and the same crystal business processes as human workers. So those capabilities sit under a dedicated IT, sorry, a dedicated AI security function or whether it's whether it's an existing, security program, the requirement is the same. The control environment has to evolve with the workforce. And that turns this into a very practical program question. What do we need to know? What do we need to see? And what do we need to be able to to control? I wouldn't try and solve all of this at once. What I would do is, set out an exercise, and I'd encourage organizations, if you're gonna take something away, I'd take away this. I would draw a gap analysis against the program you already have. So if I just take a couple, take identity governance. Do you actually have an inventory of your agents? Does every agent have an owner? Do we know which identity or service account it uses? And do we have a life cycle for the identity, including how we review review it or or retire it. Then we could behavioral monitoring. If our baselines are designed around human identities, what does normal actually mean for an agent? Then move into DLP. Are AI inputs and outputs even visible to the controls that we are currently operating? Privilege access even. Has the agent be given broad credentials because that's operationally convenient, or have we scoped its access to the task it's actually supposed to perform? And then telemetry and forensics. This is a big one. And if an incident happens tomorrow, could we reconstruct the execution chain? Do we have the identity activity, the API calls, tool interactions, and downstream events required to understand what actually happened? And finally, instant response and ownership. Who investigates an agent related incident? Security? Could it be the AI teams, business owners, an engineer, legal, risk? And perhaps the most important operational question, who has the authority to revoke its access or stop it? Because detection confidence and authority to act are not the same thing. A SOC might be highly confident that something is wrong, but if nobody has agreed the intervention threshold or decision rights beforehand, machine speed detection can still result result in a human speed response. So the gap analysis isn't about creating another enormous control framework. It's about finding where your existing program still assumes the actor is human and fixing those assumptions. So once we've identified the gaps, we come back to something I've talked about throughout the session, behavior. And that's an important distinction with agents. An agent is typically working towards an objective. We give it a go, some context, access to tools, and constraints around what it should be allowed to do. But we shouldn't assume that defining the objective and guardrails means we can predict every step of that execution path. Now we saw that in the evaluation we discussed earlier. If the expected route doesn't achieve their objective, an agent may seek another route. That's why policy and guardrails are essential, but they perform a very different function from monitoring. As I said, governance defines the boundaries. Behavioral visibility helps us verify what actually happened inside those boundaries. Then there's the visibility problem. We may have agents that are formally registered, owned, and governed, but organizations all to also need to think about agents or AI enabled workflows being created outside those processes. Because you can't govern an identity or an agent that you don't know exists. And then finally, context. One API call really really tells me very much. One authentication event really tells us very much either. It's the relationship between those events, identity, access, destination, volume, timing, and sequence that allows us to understand whether behavior has materially changed. So the objective isn't simply to monitor more AI. It's to understand enough about its behavior to determine whether it's operating as expected. And that makes behavioral visibility an important part of an effective AI governance program. And this is where I think we can make the whole conversation much simpler. If we are going to allow an agent to operate as a digital worker, there are four questions I think every organization should be able to answer. First, can you identify it? Which agent acted? Which identity did they use? Who delegated those permissions? Now that sounds basic. But if all I can see downstream is a generic service account, attribution becomes difficult. And then secondly, can you reconstruct why it acted? What objective was it pursuing? What instructions or context was it operating? Did something change? No. I'm not suggesting that security team needs access to an agent's private chain of thought. That's neither necessary or necessarily available. What what we need is sufficient execution, context, and auditability to understand that action. And thirdly, you you can recognize, when that behavior changes. Do we know what's normal for that agent? Do we have an baseline? Has its access changed? Has the volume of its access changed? Has its destination changed? Am I looking at isolated events or can I reconstruct the whole sequence? These are the questions we need to be asking. And, firstly, and I think this is, you know, frequently, one of the the governance questions that gets missed. Who owns it? Who is accountable for that agent? Who investigates when something goes wrong? And who has the authority to stop it? Because an agent without clear ownership isn't just an identity problem. It's an accountability problem. And if you can't answer those four questions, I'd suggest that we don't have sufficient operational control over that digital worker. So how do we turn all of that into something practical? I can reduce it into four things. So I've got no control, observe, intervene. So first, no. You need that inventory. What agents exist? Who owns them? What they're supposed to do? What identities do they use? As I said before, you can't protect what you can't see. Second, control. Applying this privilege. Scope the tools and permissions to the task. Set appropriate guardrails and thresholds. And crucially, make the level of autonomy proportionate to the consequence of the action. An agent summarizing an internal document is not the same risk as an agent capable of moving money or changing production code or modifying a custom customer record. And I always say that's not all agents are equal. Not all actions require the same level of human authority. Thirdly, observe. Establish what normal looks like. Monitor activity across the human to agent and agent to agent chain where relevant. Don't just monitor individual events. Look for changes in behavior, context, and sequence. And then finally, intervene. This is where governance becomes operational. Where do we require human approval? Where can we allow automated action with pre agreed thresholds? What happens when those thresholds are crossed? Can we rapidly revoke credentials, disable access, or stop the workflow? And we have retained enough evidence to investigate what happened afterwards because that's very important. Because being able to detect something isn't the same as having the authority to act on it. Those distinct those, decision rights and intervention thresholds need to be agreed before an incident. And if you're translating this into architecture, think for connected layers, identity and authorization, agent execution and tooling, telemetry and behavioral analytics, and intervention and response. The critical thing is being able to correlate those layers through the life cycle of the agent or workflow. In many respects, this is a zero in many respects, the zero trust applied to the digital workforce. Explicit identity, least privilege, continuous verification, and the ability to intervene is key. So the principle underneath this model is straightforward. The greater the potential consequence, the stronger the oversight. Visibility and intervention capability should be. And that gives us something that we can operationalize. So we've talked about identity, behavior, visibility, and control. But I think we can reduce quite a lot of that down to three simple questions. Who authorized the agent? Who can see its behavior when it changes? And who has the authority to stop it? The first is really an ownership question. Somebody may have commissioned or deployed the agent, but that doesn't translate into accountable ownership throughout its life cycle. Second is a visibility question. If the agent starts accessing different data using different tools, interacting with different systems, or behaving outside its expected pattern, who actually sees that? And the third is perhaps the most important operationally, who can intervene because detecting something and having the authority to act aren't the same thing. Your SOC may identify the risk. Your AI team may own the agent. The business may own the response. Legal or risk may have an interest in the decision. So before an incident occurs, organizations need to determine where those decision rights sit and what thresholds justify intervention. And I'd encourage you to take these three questions back into your organization. And if the answers aren't immediately obvious, then that might tell you something about, the governance or maturity. So if those questions expose gaps, what can we practically do, about them? But I deliberately wanted to finish on something practical because none of this requires organizations to solve agentic AI security overnight. Think about it as discover, extend, and exercise. In the first thirty days, discover. Find the digital workforce. Understand agent identities that are already operating inside your environment. Identify the business and technical owners. Understand what identities they use, what permissions they have, and what systems and data they can reach. And critically identify where you currently have no monitoring or clear ownership. And don't assume your formal AI inventory gives you the complete picture. Part of the exercise is finding things you didn't know were there. Then over the next, say, sixty days, extend. Take the governance, identity, monitoring, and insider risk capabilities you already have and determine where they need to accommodate agents. That means updating risk classifications, extending behavioral monitoring and telemetry, defining escalation and intervention points, and adapting your incident response playbooks. And then my day 90, exercise it. I'm an agent inside your scenario. Test whether you can contain it. Test whether you can refocus access quickly enough, and test whether you can reconstruct what happened and attribute the activity. Because a control that exists doesn't work during, a machine speed incident, So the sequence matters. First, get visibility and ownership, then extend its controls, then prove, your organization can respond. So I like to think of all this as a journey from trust to control. We started with security, historically with trust. So what or who are we trusting? Then identity became fundamental. Can I trust that identity? But with digital workers, identity alone isn't enough. We need to understand capability. What can this identity actually do? Then comes agency. Can I trust what it does when it makes a decision and execute actions without human approving every step? And that takes us back to behavior. How do I know if something has changed? Then finally, control. What are we prepared to do about it? And I think that's a shift AI agents force us to make. It isn't simply, is this a trusted identity? It becomes, is this trusted identity performing, authorized? Is it behaving within expected boundaries? And do I have the ability and authority to intervene when it doesn't? And that's a much richer definition of trust. And importantly, control shouldn't mean preventing autonomy. It means making autonomy proportionate to consequence. That takes us right back to the practical control model I've just discussed. So if I was to leave you with only three things, it would be the insider threat program hasn't become obsolete, but scope has expanded. We still care about trusted access, privileged data, behavior, and accountability, but the population operating inside that trust boundary is changing. It increasingly includes humans, machines, and autonomous digital workers. Second, digital workers need many of the same security fundamentals we've spent years developing for people. We need to know who or what they are and who owns them, what access to have, what normal looks like. But we also have to recognize what's different. Autonomy, machine speed, distributed execution, and potentially very little time between something, deviating to something with high consequences. And thirdly, and probably importantly, none of this should be about stopping AI adoption. Security can't become the department that simply says no. That's too risky. Our role is to make that innovation visible, governable, and safe to operate, and to give the business confidence that we can enable greater autonomy while keeping, the autonomy proportionate to the consequence. And knowing that when something does change, we can see it, understand it, and intervene. So perhaps the question, I would leave you with isn't simply, are we trusting AI agents? It's if AI agents are becoming part of our digital workforce, are our security programs ready to treat them like one? So that's everything from me. I'd just like to thank you all for, your time, and, I'll pass over to Brooke. Thank you, Finley, for a great presentation. Please leave any questions you have in the q and a chat. We have a question that came in through a different chat that is, are all AI agents equally Oh, are are all AI oh, are all AI agents, risky? risky? I would say absolutely not. And that's probably, an important point. An AI agent summarizing internal documents is very different from an agent that can modify, as I said before, production code or make payments or move money. I'd look at what it can access, what tools it can use, and how much autonomy it has, and, potentially, what are the consequences if something goes wrong. And that, for me, should determine the level of control and monitoring and hue and what human oversight should apply. So rather than treating every agent as a high risk, I advocate for a risk based approach. You know, that autonomy proportionate to consequence. Okay. Thanks, Finley. That concludes our session for today. We hope you found it helpful and informative. We appreciate you taking the time to be here and hope you have a great rest of your day. Thanks, everyone. Bye.