The industry has been promising automated response for a decade. Here is what it looks like when it actually works, what it looks like when it doesn’t, and where the line should be.
Securaa | July 2026 | 5 min read
In 2020, automated incident response meant a SOAR playbook that enriched an IP address and opened a Jira ticket. In 2023, it meant a playbook that could also isolate an endpoint if six conditions were met. In 2025, vendors started calling their AI agents automated response because the agent could recommend containment actions and sometimes execute them.
In 2026, the picture has clarified. Automated response is not one thing. It is a spectrum, and the teams getting value from it are the ones who understand where they sit on that spectrum and, more importantly, where they should not try to go.
The Automation Spectrum, Honestly
Every vendor uses the word automation. What they mean varies so widely that the term is almost useless without qualification. Here is the spectrum as it exists in practice, stripped of marketing language:
• Level 0 — Manual with enrichment. An alert fires. The platform auto-enriches the IOCs with threat intel, geolocation, and asset context. Everything else is manual. The analyst reads, decides, and acts. This is where 60% of SOCs still operate for most alert types, and there is nothing wrong with that for complex cases.
• Level 1 — Playbook-driven triage. The platform runs a predefined decision tree. If the enriched IOC matches a known benign pattern, auto-close. If it matches a known threat, escalate and assign. If neither, queue for manual review. This handles the predictable cases and leaves the ambiguous ones for humans.
• Level 2 — Conditional containment. The platform takes response actions when specific conditions are met. Block an IP if the TIP confidence score exceeds 90% and the source is external. Isolate a host if the EDR verdict is malicious and the asset is not in the critical infrastructure group. Every action has an explicit rule. Nothing happens that was not pre-authorized.
• Level 3 — Agent-driven investigation and response. An AI agent evaluates the alert, gathers additional context by querying multiple systems, builds an investigation narrative,
and recommends or executes response actions. The agent operates within defined autonomy boundaries but chooses its own investigation path. This is what the agentic SOAR vendors are selling in 2026. A small number of teams are running it in production. Most are piloting it.
The value of automated response is not at Level 3. It is at the boundary between Level 1 and Level 2, where you take the cases your analysts handle identically every time and remove the human from the loop for those specific, well-understood scenarios.
What Actually Works in Production
After watching teams deploy automated response across regulated environments in the UAE, Singapore, and India, the pattern is consistent. The automation that delivers measurable value is boring. It is not the AI agent handling novel ransomware investigations autonomously. It is the playbook that handles the same phishing alert pattern your analysts have closed 400 times this quarter without variation.
The high-value automation targets are cases where the decision is deterministic, the data is reliable, the action is reversible, and the blast radius of a wrong decision is contained. Phishing email quarantine when the sender domain matches a TIP blocklist. Brute force account lockout when the failed login count exceeds threshold from a non-corporate IP. IOC blocking when the hash is confirmed malicious by two or more sandbox verdicts. These are not impressive demos. They are the cases that reclaim 30-40% of analyst time without introducing meaningful risk.
What Doesn’t Work Yet
The automation that consistently fails or creates more problems than it solves shares a common trait: it requires judgment in ambiguous situations.
Automated containment of insider threats fails because the line between malicious and legitimate activity depends on context that no playbook can fully encode. An employee downloading 200 files from SharePoint at 11pm might be exfiltrating data or finishing a project before a deadline. Automated response to cloud misconfigurations fails because reverting a configuration change can break the application that depends on it. Automated investigation of novel attack techniques fails because the investigation path is not predetermined and the agent may pursue a plausible but wrong hypothesis for 15 minutes before an analyst catches it.
None of this means these problems are unsolvable. It means they are not solved by the same approach that works for deterministic cases. They need a different supervision model, tighter confidence thresholds, and a human checkpoint before any irreversible action.
Where to Draw the Line
The practical framework is four questions applied to each candidate for automation:
• Is the decision deterministic? If your analysts handle this case the same way every time with no variation, automate it. If they sometimes do different things depending on context, keep a human in the loop.
• Is the action reversible? Blocking an IP is reversible. Deleting a mailbox is not. Automate reversible actions more aggressively. Require human approval for anything destructive or irreversible.
• What is the blast radius of a mistake? Auto-closing a false positive that turns out to be a true positive is bad but recoverable. Auto-isolating a production database server on a false trigger causes an outage. Size the supervision level to the blast radius.
• Can you explain the decision after the fact? If the automation path is a playbook with explicit conditions, you can always reconstruct why it fired. If the automation path is an AI agent’s judgment, you need a reasoning chain. If neither exists, the action should not be autonomous.
Automated incident response in 2026 is not about removing humans from the SOC. It is about removing humans from the decisions they make identically every time so they can spend their judgment on the decisions that actually require it. That distinction sounds simple. Getting the boundary right is the entire job.
Frequently Asked Questions
What does the blog mean by calling automated response ‘a spectrum, not one thing’?
It argues the term automation gets used for very different levels of capability, from simple IOC enrichment all the way to an AI agent choosing its own investigation path. The blog lays out four levels, Manual with Enrichment, Playbook-Driven Triage, Conditional Containment, and Agent-Driven Investigation and Response, and says teams get value by knowing which level they’re actually operating at rather than trusting the marketing label.
What are the four levels of the automation spectrum described in the blog?
Level 0 is manual work with auto-enrichment, where the platform pulls in threat intel and asset context but a human decides everything else; Level 1 is playbook-driven triage using a fixed decision tree; Level 2 is conditional containment, where pre-authorized rules trigger specific response actions; and Level 3 is agent-driven investigation, where an AI agent gathers its own context and chooses its own investigation path within set boundaries.
Where does the blog say the real value of automated response actually sits?
Not at Level 3, despite that being what most agentic SOAR vendors are selling in 2026. The blog argues the real value sits at the boundary between Level 1 and Level 2, where cases analysts already handle identically every time get fully automated, rather than in novel, judgment-heavy investigations.
What kinds of automation cases does the blog say actually work in production?
Ones where the decision is deterministic, the data is reliable, the action is reversible, and a wrong call has a contained blast radius. Its examples are phishing email quarantine when a sender domain matches a threat intel blocklist, automatic account lockout after a brute-force login threshold from a non-corporate IP, and blocking a hash confirmed malicious by two or more sandbox verdicts.
What kinds of automation does the blog say still don’t work well, and why?
Cases requiring contextual judgment: automated containment of insider threats, where the same action (downloading many files late at night) can be malicious or perfectly legitimate depending on context a playbook can’t fully capture; automated reversal of cloud misconfigurations, which can break a dependent application; and automated investigation of novel attack techniques, where an AI agent can pursue a plausible but wrong hypothesis for a stretch of time before a human catches it.
What four questions does the blog recommend asking before automating any specific decision?
Whether analysts already handle the case identically every time with no variation (deterministic); whether the resulting action is reversible; what the blast radius of a mistake would be; and whether the decision can be explained after the fact, either through a playbook’s explicit conditions or an AI agent’s reasoning chain. If none of these hold, the blog says the action shouldn’t be autonomous.
What overall philosophy does the blog land on for how much of the SOC should actually be automated?
It frames the goal as removing humans specifically from decisions they already make identically every time, not from decision-making in the SOC generally, so their judgment gets reserved for the ambiguous cases that genuinely need it. It also notes this pattern held consistently across teams it observed deploying automated response in regulated environments in the UAE, Singapore, and India, and that these deterministic-case automations reclaimed roughly 30-40% of analyst time without adding meaningful risk.