A global professional services firm is hiring a Manager to lead the transition from a human-led Security Operations Center into an "AI-assisted and increasingly autonomous SOC." They want someone hands-on with SIEM, SOAR, EDR, threat intelligence, LLM platforms, and detection engineering — someone who can look at a room full of tier-1 analysts and see a to-do list. Every responsibility listed is an instruction manual for replacing the person who will sit in that seat.
Alert Triage: The First to Go
The bulk of SOC work is triage. An alert fires. An analyst checks the user, the endpoint, the destination IP, the process lineage, and decides: benign, suspicious, or malicious. Most of the time it is benign. The analyst closes the ticket. This is the part of the job that everyone wants to automate because it is the part that makes everyone miserable.
An AI pipeline replaces it cleanly. Alerts from the SIEM and EDR flow into a function that pulls enrichment data — threat intel feeds, endpoint telemetry, identity context, recent user behavior — and feeds the bundle to an LLM. The prompt is straightforward: "Given this alert, this context, and this enrichment data, classify as benign, suspicious, or malicious. Provide your reasoning and a confidence score." A second model reviews the first model's reasoning. If they disagree, the alert goes to a human. If they agree and confidence is high, the alert auto-closes with the reasoning attached.
The person who used to triage that alert becomes the person who reads the auto-closed tickets and audits the reasoning. Then they stop auditing because the reasoning is consistently fine. Then they stop reading.
Investigation: The Middle Collapses
When an alert is actually suspicious, the investigation begins. This is where senior analysts earn their salaries — correlating events across multiple data sources, building a timeline, understanding the attack chain, figuring out what the adversary was trying to do.
This is also automatable, and the job description says so explicitly: "AI-assisted security investigation and decision-support workflows." The LLM receives the initial alert, pulls the related logs from the SIEM (authentication events, network flow, EDR process trees), queries the threat intel platform for indicators, and constructs an incident timeline. It produces an incident summary: what happened, what systems were affected, what data was accessed, what the likely next steps of the attacker would be.
The job description asks for "incident summarisation, threat intelligence analysis, and response recommendations." An LLM does all three in one pass. The summarization is a structured output. The threat intel analysis is a RAG pipeline pulling from your intel feeds and MITRE ATT&CK mappings. The response recommendation is a classification problem — isolate host, disable account, block IP, escalate — with a confidence threshold and a human approval gate for anything destructive.
Detection Engineering: The Creative Part, Mostly Automated
Detection engineering is the part of the job that feels most human. You study how attackers operate, write rules to catch them, tune those rules to reduce false positives, and test them against known attack simulations. It requires creativity, adversary knowledge, and patience.
Most of it is pattern matching. A detection engineer reads a threat report, identifies a new technique, maps it to ATT&CK, writes a query in Splunk or Sentinel or Elastic, tests it against a dataset, tunes the logic, and deploys it. An AI system does this by ingesting threat reports, mapping techniques to ATT&CK, generating candidate detection rules, running them against historical data to measure false positive rates, and proposing tuned versions. The human reviews the proposed rule, validates the logic, and approves it.
The job description asks for "improving detection quality" and "translating SOC use cases into scalable production capabilities." That is a pipeline, not a craft. New threat report arrives → AI proposes detection → AI tests it → AI tunes it → human reviews → deployed. The human is a reviewer, not an engineer.
Orchestration and Response: Where the Human Clings On
Here is where it breaks. The job description asks for "human-in-the-loop controls, approval gates, guardrails, and escalation mechanisms for autonomous security actions." This is the part that is genuinely hard to automate — not because the AI cannot decide what to do, but because the consequences of being wrong are severe.
If an AI auto-isolates a CEO's laptop because it detected suspicious PowerShell activity, and it turns out to be a legitimate administrative script, the analyst who approved that action is getting a phone call. If an AI auto-disables a service account and takes down a production system, someone has to explain why a machine made that decision. The technology to do this exists. The organizational tolerance for it does not.
So the human stays — as an approver. A person sitting at a desk, looking at AI-generated recommendations, clicking "approve" or "reject." This is what remains of the SOC: a few people in an approval queue, doing the thing that The Employment Theater of AI Code Review describes — a role that survives as ritual after the work is automated.
The Manager Automates Themselves
The job description is a roadmap. It describes a SOC that progressively needs fewer people. The Manager builds the alert triage pipeline — tier-1 analysts go. They build the investigation workflow — tier-2 analysts go. They build the detection engineering pipeline — detection engineers go. They build the orchestration and response workflows with approval gates — tier-3 analysts become approvers.
Then the Manager looks around. The SOC is running. The pipelines are built. The AI is generating detections, triaging alerts, investigating incidents, and recommending responses. The approval queue is staffed by a couple of senior analysts who review the AI's work. The roadmap is complete. The level of automation has been progressively increased across security operations, exactly as the job description asked.
The Manager's job was to build the machine. The machine is built. The job is done.
The professional services firm will not fire the Manager immediately. They will keep them on for maintenance, for tuning, for the next round of AI models that need integration. But the role has changed from builder to caretaker, and caretaker roles have a short half-life. The next hire will be a more junior person who maintains the pipelines the Manager built. The hire after that will be an AI agent that maintains them.
The Catch
There is one thing that does not automate cleanly, and it is the thing the job description barely mentions: stakeholder communication. When a real incident happens — a genuine breach, a real adversary in the network — the SOC has to talk to people. The CISO needs an explanation. Legal needs a timeline. The executive team needs to know if customer data was accessed. The AI can generate all of these documents. It can produce a polished incident summary, a legal-ready timeline, an executive briefing. But someone has to stand in front of the executives and answer the question that no LLM can answer in the moment: "Are we safe?"
That is the last job in the SOC. Not engineering, not analysis, not detection. Communication. Judgment. The willingness to look a human being in the eye and say "I think we're okay" or "we have a problem." The AI can write the words. It cannot stand in the room.
But the Manager who built the autonomous SOC is not the person standing in that room either. That person is the CISO. The Manager is the person who built the system that feeds the CISO their answers. And that system does not need a Manager anymore.
If you take this job, build fast. The window between "I built the autonomous SOC" and "the autonomous SOC does not need me" is about 18 months. Make sure you have the next role lined up before the roadmap completes. The roadmap always completes.
