Here I am, sitting at 4:20 am, staring at the line above, thinking, given this ungodly hour, AI can just “do it”. Then I think of the alerts I just manually triaged; would I want AI making decisions and acting on them? Probably not, so here we are!
There is no doubt that, with the sheer veracity the frontier models are running at, most SOCs that are not backed by a platform vendor (think SentinelOne and CrowdStrike) are already dabbling in the big, brave world of “should I pass this to AI for assistance?”
If the SOC is platform vendor-based, this functionality is already starting to trickle down. You are likely seeing enhancements within the GUI. But as to whether or not they’re useful… well, time will tell on that one.
The crux of the topic is: how far are you willing to let AI go in an automated stance? Who should be doing what?
The core is AI should be an accelerator, nothing more, nothing less – at this point.
We’ve recently been looking at significant AI advancements within the Tarian SOC. One of the limitations we quickly identified is the AI workload needed to query the data more effectively to define better triage assistance and recommendations. This is where the red flag appears.
We have an AI workload with guardrails, fed highly controlled telemetry. Now it needs access to the client Sentinel instance for additional KQL querying… ok… oh, but that needs to happen for each client. Enter the chaos.
Considerations we need to overcome, not overserve, overcome…
- Access boundaries – how are we going to control access effectively?
- Data exposure risks – KQL queries might drag back sensitive data we didn’t want.
- Prompt-to-query risk – what if we get a query loop and hammer the SIEM instance = $.
- Tenant boundary risk – this is the big one; there is a risk of cross-contamination/hallucination due to parallel data pulls.
And these are just the top four (of about twenty) considerations to overcome to safely enrich data in an impactful way in our current setup. Sure, there are other ways, and more tech is trickling down, but we are chasing something in the special differentiation space.
So what should AI be doing?
- Initial alert enrichment & triage support – assist the analyst by dragging in relevant context and potentially summarising what is going on, helping those 3 am “what the hell is this?” moments.
- Detection engineering refinement – KQL drafting, explain existing queries, suggest additions or pivots and summarise the query results.
- Development accelerations – develop internal processes, Wiki articles/playbooks, or even platforms to help with security operations.
What you should avoid with AI (at the moment)
- No final calls – just go do a thing – generally a bad idea.
- Client interaction – client communication carries commercial, legal, and reputational risk.
- Disable accounts, isolate endpoints, block infrastructure, or delete data autonomously – these actions can disrupt business operations.
- Close incidents without human review – AI may miss context, business impact, or chained activity.
- Retain sensitive telemetry in uncontrolled memory, logs, prompts, or embeddings – security data often includes personal, privileged, and incident-sensitive material.
What you need to be doing as a human, at 4 am (just like me):
- Own the accountability – humans remain responsible for investigation quality, client advice, escalation, and response decisions.
- Validate the outputs – analysts must challenge AI-generated summaries, KQL queries, severity recommendations, and conclusions.
- Make the judgement calls – humans assess business impact, client context, operational risk, intent, and escalation sensitivity.
- Interact with the client/business – humans understand the client’s risk appetite, crown jewels, business constraints, escalation preferences, and politics.
- Lead the response – incident command, containment strategy, stakeholder communication, evidence handling, and recovery decisions should remain human-led.
- Tune the outcomes – AI can suggest improvements, but analysts should validate whether changes reduce risk or just suppress noise.
- Generally, improve the operating model – humans decide which automations are safe, which workflows need control gates, and where AI should or should not be used.
So, for the moment, in July 2026, you, as a human, are very much needed; until AI can take legal responsibility, this will remain the case.
But you can absolutely see where I’ve touched on this before: the junior analyst role no longer exists… but… the junior automation engineer was just born.
Trust nothing, validate everything, then do it again.
