By Findlay Whitelaw, Field CISO, Exabeam
AI is beginning to do more in security operations than analyse alerts and suggest what an analyst might look at next. Some systems can investigate, use tools and act. That changes the question security leaders need to ask, who decides how far they are allowed to go?
It is easy to see why teams are interested. The volume of alerts, identities and activity they manage has grown beyond what people can realistically examine on their own. AI can help connect signals and move an investigation forward. Yet there is a significant difference between helping an analyst reach a decision and making a change to a live environment.
We have spent years debating whether the human should be in the loop or on the loop. Those descriptions are useful, but they only take us so far. As AI takes a larger role in the SOC, I think the more important question is who sets its objectives and limits, which decisions it can make on its own, and who has the authority to step in.
Where should humans sit?
Human in the loop generally means a person approves an action before it happens. Human on the loop means a system works within set parameters while people monitor it and step in when needed.
I do not think a SOC can choose one model and apply it to everything. An analyst should not have to approve every step of an investigation, particularly when speed matters. But the ability to act quickly is not, by itself, a reason to give a system broad authority. The likely consequence of a mistake matters, as does whether the action can be reversed.
Take an agent investigating a suspicious sign-in. It could gather related events, check recent activity and bring the evidence together for an analyst. Within agreed limits, it might also take a narrow, reversible action. Disabling a critical account or isolating a production system calls for a different level of scrutiny. If the evidence is incomplete and the disruption could be serious, a person may need to make that call.
This is what I mean by keeping humans in the lead. People decide what the agent is there to achieve and where its authority ends. They determine which actions can happen automatically and which require approval, then remain accountable for reviewing how those decisions work in practice. It does not mean placing a human approval step in front of everything the system does.
Seeing what actually happened
None of that works unless the team can see how an investigation unfolded. If an agent acts, analysts need to know what it was asked to do, what evidence it used, which tools it called and what changed. They also need to know which identity and permissions it used.
That record gives the team something concrete to examine and it can show whether an action stayed within the agent’s authority and help reconstruct an incident if something goes wrong. It may not fully explain why a model arrived at a particular judgement, however, a plausible explanation after the event should not be mistaken for evidence that the decision was sound.
Behavioural monitoring can add another view, as an agent may have legitimate access to a tool but begin using it in an unexpected way. A change in the timing, volume or sequence of its activity might warrant a closer look. That does not automatically make the action unauthorised. The analyst still needs the context of the task and the boundaries the agent was given.
Making it work in a real SOC
Talk of an autonomous SOC can make this sound like one large choice, either we allow AI to act or we do not. In practice, security leaders must make a series of much more specific decisions. Which investigative steps can run without approval? Which responses might affect customers or a critical service? At what point should the system pause?
Other industries that rely on complex automation have faced the problem of supervising systems that people cannot follow step by step. The lesson for security operations is to design oversight around the moments when human judgement can make a difference. An approval prompt is of little use if the analyst cannot see the relevant evidence, or if the action has already caused the harm it was meant to prevent.
Those arrangements will need to change as teams gain experience. They should be able to examine whether an agent did what was intended, stayed within its permissions and produced any unexpected effects. If a boundary proves too loose, or an approval step adds delay without improving the decision, there should be a way to adjust it.
This also matters for resilience, if an automated action has an unexpected effect, the team needs to recognise it quickly, limit disruption and keep operating. That’s harder to do when nobody can see what the system changed or has the authority to stop it.
The future SOC may not need a human in every loop, however it does need people who can say what each system is allowed to do, see what it has done and intervene when the consequences warrant it. That is what keeping humans in the lead should mean.
About the author
Findlay Whitelaw, Field CISO, Exabeam
Findlay Whitelaw is Field CISO at Exabeam, where she works with security leaders on insider risk, security operations and the safe adoption of AI agents in the SOC. Her career spans hands-on security operations, consultancy and leadership roles. A published author and award-winning practitioner, Findlay focuses on human-centric cyber risk and on helping organisations use advanced technologies to build resilience and manage insider threats.
