Disclaimer: Opinions expressed are solely my own and do not reflect the views or opinions of my employer or any other affiliated entities. Any sponsored content featured on this blog is independent and does not imply endorsement by, nor relationship with, my employer or affiliated organisations.
Is your SecOps toolset changing because the roles are changing? Or is it the other way around?
Most vendors promise the same thing today: triage is fully automated, so your team can focus on what matters. But your team was already focusing on what matters. The low severity alerts were bulk closed anyway. The high and critical alerts got looked at. The low severity alerts? They were bulk closed, suppressed, or left in the queue until someone wrote a rule to close them.
So what changed? You have a bit more of the boring tasks automated. And maybe better coverage on the low and medium severity alerts you used to ignore. That’s a real improvement I wont argue that we all know attackers hide in the noise (not every time, but when we catch ones that does we turn that into a marketing story)
My take: the big shift is in the roles. Not because you don’t do triage anymore :) But because building got a lot easier.
Product Updates
Fig sits above your existing stack and maps how data flows from source to detection. It works with any data source, SIEM, pipeline, or data lake. One read-only API, live in days.
Catch, Trace, and Fix Breaks
Fig checks every change before it ships and keeps checking in production. If a log source, schema, or parser change breaks a detection, Fig alerts you in Slack, email, or Jira, with the root cause and a fix.Build, Test, and Ship Changes
Tell Fig what you want to change or know. It returns a detection, parser, query or configuration that’s ready for production and tuned, tested, and validated against your environment. All in minutes, not weeks.Don’t break for a change.
Sekoia Elevate is the AI agent layer of the Sekoia agentic SOC platform. It investigates every alert and case end to end, starting the moment it’s created.
Investigation and Verdict
The agent pulls raw logs, detections, runbooks and Sekoia’s in-house threat intel, then pivots through the context and tests hypotheses. Analysts get an audit-ready verdict with confidence, findings, reasoning and the queries behind each finding, and can override it.Runbooks and Sovereignty
Generates investigation runbooks for every detection rule, including custom ones. AI runs on Sekoia-hosted infrastructure, with no data sent to external LLM providers. Built for enterprise SOCs and multi-tenant MSSPs.Every alert investigated. Every decision explained.
People build machines, machines do the job
Anton Chuvakin sums up SecOps maturity in his blog:
Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.
The building part got easier. You don’t need a months and a dedicated SOAR engineer to ship couple of workflows. So you will build more stuff that runs automatically, and some of it autonomously. And that means many roles that were pure SOC analyst will move to security engineering.
Yes, if you go with a vendor, some of this comes pre-built. You don’t build or manage the triage agents yourself. But someone still has to fine-tune them, feed them context, and check if they’re right. That’s engineering work too.
So what does that work look like? Let’s break it down with the SecOps AI Shift Map: left is data and detections, middle is investigation, right is response.
Far left: the data
Your job here is to make sure you connected the right sources. In other words, you have the right data and you monitor it. Connecting tools, building data pipelines, writing parsers, normalizing fields. There’s a ton of good tooling out there for this.
Why does this matter more now? Because an agent can only investigate what it can reach. If your identity logs aren’t there, the agent doesn’t say “I’m missing identity logs.” It gives you a verdict anyway. Garbage in, machine speed AI-powered garbage out.
The basics still win here. Tag every event with an asset and a user. Know which sources support detection and which are only good for investigation after the fact. And expect parsers to break, because some vendor will change their log format on a Tuesday without telling anyone.
Left: detections and context
Detection engineering is a whole category on its own. Writing rules, testing them, tuning them, retiring the ones that only produce noise. No news there. What’s new is that AI triage now gives you feedback on every detection, including the low severity ones nobody looked at. So you finally know (easier and faster) which rules are noisy. The question is whether someone has time to fix them.
Next to it is context. The enrichment sources for your SIEM, your TIP, your CMDB, your IAM. Who owns this machine? Is this a service account or a human? Is this asset critical? Is there an SOP attached to this detection? How you manage and structure all of this is becoming its own job.
I think this becomes a responsibility on its own, and in some cases a full role, most likely in large enterprises and MDRs. Let’s call it Security Context Engineering. (Yes, another term. It’s a cybersecurity tradition at this point.)
Also some great read on the context piece discussed by Alankrit Chona
Why a role? Because agents reason on context. Good context, good verdict. Bad or missing context, and you get a confident wrong answer. Someone has to own that context the same way someone owns the detections.
I’d also put building agents and automations here. Either you build them because your vendor doesn’t ship pre-packaged stuff, or you maintain the ones you already have. Deterministic playbooks for the steps that need to run the same way every time. Agents for the ambiguous stuff that needs reasoning. And please, version control them.
And in the end you need something that monitors your SecOps pipeline itself. A log source goes quiet. A parser starts dropping fields. A detection stops firing. An agent’s accuracy slowly drifts. None of these throw an error. They just quietly make everything downstream worse. Someone has to watch the plumbing.
This whole left side of the house becomes more and more important. Every problem you fix here, the agents in the middle don’t have to work around.
Middle: investigation
This is where most AI SOC vendors started, because it’s the easiest part to show value. And this is where the analyst job changes the most.
The engineering work here is tuning triage and investigation agents, and QA. A lot of QA. Pulling closed alerts and checking if the verdict was right. Reading the agent’s reasoning and asking “would I have closed this?” Tracking how often analysts reopen something the agent auto-closed. Maybe this is the new analyst work.
And the new role here is the Security Eval Engineer. This person builds test sets from real past alerts and incidents, runs them every time the model, the prompt, or the vendor version changes, and tracks if accuracy goes up or down. Pair it with breach and attack simulation and you can check if the whole chain works, from detection to verdict.
As I said many times, machine speed means nothing if you close alerts wrong, faster. Accuracy and reliability are your new top KPIs. Not MTTR. Not alerts closed per hour. That’s how you gain trust, and without trust nobody will let the agents move to the right side.
Right: response
Here you have the remediation and mitigation agents. This is the hardest part to automate, and not because of the tech. It’s processes, change management, and the fact that nobody wants to give an agent a service account with full write access. Fair enough.
So the engineering work is:
Aligning with your processes and procedures. The agent follows your IR process, not its own idea of what good response looks like.
Threshold management. Which actions can run automatically, and which need a human to approve. Disabling a user on a test laptop is not the same as isolating a production database server. Write these rules down as policy, not tribal knowledge.
Building reversible actions. Isolate a host, you can un-isolate it. Reset a password, the user gets a new one. Delete something, it’s gone. Start with the actions you can undo.
Making sure your feedback loop works. Every incident should send something back to the left side. A detection to tune, a log source to add, context that was missing. Most teams write the lessons learned report and never look at it again.
What this means for your team
If you run a SOC today, a few practical things:
Map who owns each part of the Shift Map. If nobody owns context or eval, that’s your gap.
Move analysts toward QA, eval, and context work. They already know what a good investigation looks like. That’s exactly the skill you need to check an agent.
Stop hiring for clicking through alerts. Hire for people who can build, test, and question the machines.
Final Thoughts
So yeah, this is how security engineering will work. Triage didn’t go away. The machines do it now, and your job is building, tuning, and checking those machines.
Machines do the job. People make sure it’s the right job.
Check out our SecOps Market Landscape tracker and evaluation frameworks