The SOAR-to-Agentic Automation Journey

Security orchestration promised to end the era of tab-switching analysts and stale runbooks, yet a decade in, most SOAR deployments still top out as glorified playbook executors waiting on human clicks. The next leap is not a bigger playbook library — it is a shift from scripted automation to agentic systems that reason, decide, and act inside guardrails, closing the loop from detection to containment without a human in every step.

The runbook era and its limits

Every mature SOC has a shelf of runbooks: phishing triage, malware containment, brute-force lockout, insider-threat escalation. These documents encode institutional knowledge painstakingly, and SOAR platforms digitized them into if-this-then-that playbooks wired to SIEM alerts. The value was real — enrichment steps that took an analyst fifteen minutes of pivoting between a threat intel portal, an EDR console, and a ticketing system could run in under a second. But the architecture had a ceiling baked into it from day one.

A traditional SOAR playbook is a directed graph of static nodes: fetch indicator reputation, query asset inventory, open a ticket, wait for approval, isolate host. Every branch has to be anticipated at design time. The moment an alert deviates from the pattern the playbook author imagined — a slightly different process tree, an unfamiliar cloud API call, a hostname that does not match the expected regex — the automation stalls and hands back to a human with a half-finished case. Playbook sprawl follows: teams end up maintaining dozens of near-duplicate playbooks, one per alert-source variant, because the orchestration engine has no way to generalize.

The deeper limitation is that SOAR automates execution, not judgment. The decision of whether an indicator is truly malicious, whether a host is business-critical enough to warrant a phone call before isolation, or whether three seemingly unrelated alerts are actually one attack chain, still lives in an analyst's head. SOAR can retrieve the facts that inform that judgment faster, but it cannot make the judgment. That is precisely the gap agentic automation is built to close, and it is why forward-leaning teams are re-architecting around reasoning loops rather than adding yet another playbook.

What SOAR actually automated — and what it didn't

It is worth being precise about SOAR's real contribution, because the agentic transition is additive, not a repudiation. SOAR solved three problems well:

• Enrichment fan-out. Parallel calls to threat intel feeds, WHOIS, sandbox detonation, and asset/CMDB lookups, collapsed into one case timeline instead of a dozen browser tabs.
• Deterministic containment actions. Firewall rule pushes, EDR host isolation, account disablement — scripted API calls that are the same every time, gated behind an approval button.
• Case and ticket hygiene. Auto-creating tickets, attaching artifacts, and maintaining an audit trail that satisfies compliance reviewers.

What it did not solve, in almost every deployment we have examined, falls into three buckets:

• Alert correlation across weakly related signals. Rule-based correlation catches patterns someone thought to encode; it misses the novel combination of a low-severity DNS anomaly, a slightly unusual PowerShell invocation, and an off-hours login that together indicate a live intrusion.
• Context-dependent risk scoring. A playbook can check "is this asset tagged crown-jewel," but it cannot weigh ambiguous evidence the way a senior analyst does — reasoning about attacker intent, plausible alternative explanations, and organizational risk tolerance in the moment.
• Playbook maintenance debt. Every new detection rule, cloud service, or attacker technique requires someone to hand-author or update a playbook branch. This is the silent tax that turns "automation" projects into permanent engineering backlogs.

These gaps are why SOAR adoption studies consistently show automation coverage plateauing around 20–35% of total alert volume in mature programs — the deterministic, well-understood cases get automated, and everything with ambiguity routes to a human queue that keeps growing as alert volume grows. Platforms built for AI-driven alert triage exist specifically to attack that plateau by handling the ambiguous middle tier, not just the deterministic edges.

The agentic shift: from playbooks to reasoning loops

An agentic response system replaces the static decision tree with a reasoning loop: observe, hypothesize, act, verify, repeat — each cycle bounded by explicit policy. The mechanical difference matters. A playbook node says "if indicator reputation score > 80, isolate host." An agent instead holds a working hypothesis ("this host is likely compromised via a scheduled-task persistence mechanism"), pulls the specific evidence needed to test that hypothesis, updates its confidence, and only then decides on an action — and it can pull evidence types the playbook author never anticipated, because it is reasoning over a tool catalog rather than a fixed execution path.

Concretely, an agentic SOC investigator is built from four cooperating layers:

• Perception layer. Normalizes and streams telemetry from EDR, identity providers, network sensors, cloud control planes, and SIEM correlation output into a common event representation.
• Reasoning layer. A model (or ensemble of specialized models) that maintains case state, forms and revises hypotheses, and selects the next best action from an available tool set given the current evidence and confidence level.
• Tool/action layer. A registry of typed, permissioned functions — query EDR process tree, pull identity sign-in logs, isolate host, disable account, revoke OAuth token, open ticket — each with declared side effects and required approval tier.
• Governance layer. Policy engine that intercepts every proposed action, checks it against blast-radius rules, asset criticality, business hours, and prior approval history, and either auto-executes, queues for human sign-off, or blocks it outright.

The critical architectural distinction from SOAR is that the reasoning layer is not compiled into the workflow ahead of time. It is invoked at runtime with the current case context and decides, step by step, what evidence to gather next and what action follows from it. This is what lets one agentic investigator handle a phishing case, a lateral-movement case, and a cloud misconfiguration case without three separate playbooks — the tool catalog and governance rules are shared; the reasoning adapts to the situation. This pattern underlies how agentic SOC platforms replace playbook sprawl with a smaller number of composable investigative agents.

It is also important to be honest about what "agentic" does not mean here. It does not mean an unsupervised model with unrestricted API access improvising incident response. Every credible agentic architecture we have implemented is a reasoning loop wrapped tightly in deterministic guardrails — the model proposes, the governance layer disposes. The autonomy is in the investigation, not in the blast radius of the actions.

Reference architecture for closed-loop response

Closing the loop — detection through containment through verification — requires more than swapping a playbook engine for a language model. It requires an architecture that treats detection, reasoning, action, and feedback as a continuous pipeline rather than four separate tools glued together with webhooks. In production deployments we design around five layers.

Data and telemetry fabric

Everything downstream depends on a normalized, queryable event store. EDR telemetry, identity logs, network flow data, cloud audit trails, and vulnerability scan results need a common schema and consistent entity resolution — the same "host," "user," and "asset" identifiers across every source. Without this, the reasoning layer wastes cycles reconciling identity mismatches instead of investigating. This is the layer where a unified data foundation such as MoxDB earns its keep: agentic investigation is only as fast as the joins it can run across historical and live telemetry.

Detection and correlation

Traditional correlation rules still matter — they are cheap, explainable, and catch the well-understood 60–70% of malicious activity efficiently. What changes is that correlation output becomes an input to the agentic layer rather than a terminal alert. A rule fires, and instead of routing directly to a human queue, it seeds an investigation case with an initial hypothesis and confidence score.

Agentic reasoning and case management

This is the layer described above: the reasoning loop that owns a case from open to close, calling tools, revising hypotheses, and tracking a running confidence score against a defined threshold matrix. Case state needs to be durable and inspectable — every hypothesis revision and tool call is logged as a first-class artifact, because that log is the audit trail regulators and incident reviewers will ask for.

Action and enforcement plane

A typed tool registry, each entry declaring its side effects, reversibility, and required approval tier, sitting in front of the actual enforcement points — EDR isolation APIs, identity provider session revocation, firewall/SASE policy pushes, cloud IAM changes. This plane is intentionally "dumb" — it executes exactly what the governance layer approves and nothing more, and it reports back success/failure so the reasoning layer can verify outcomes rather than assume them.

Governance, feedback, and metrics

Policy engine, approval routing, blast-radius controls, and the metrics pipeline that turns every case into a data point for tuning confidence thresholds. This layer also feeds back into detection: cases closed as false positives should demonstrably suppress similar future alerts, and cases closed as true positives should sharpen the hypotheses the reasoning layer forms next time.

Figure 2 — Reference stack for closed-loop agentic response, from raw telemetry to governed action.

This layered separation matters for a practical reason: it lets you replace or upgrade the reasoning layer — swap in a better model, add a specialized sub-agent for cloud incidents — without touching the enforcement plane or the governance rules that your compliance team has already signed off on. Coupling reasoning tightly to action, as some early agentic products do, means every model change becomes a re-audit of your entire control set. Keep them separate.

Playbook patterns that survive the transition

Not everything about the SOAR era should be discarded. Certain playbook patterns remain the right tool even inside an agentic architecture, and recognizing which ones is a design skill in itself.

Deterministic containment for confirmed threats

Once an agent's confidence crosses a defined threshold on a well-understood threat class — a known ransomware binary hash, a confirmed compromised credential with matching impossible-travel signal — there is no value in further reasoning. A deterministic playbook (isolate host, disable account, revoke tokens, snapshot for forensics) executes faster and more predictably than an agent re-deriving the same steps. Agentic systems should invoke these playbooks as one of their available tools rather than replace them.

Approval-gated escalation chains

The human-in-the-loop approval step from SOAR — Slack/Teams message with approve/deny buttons, on-call paging, ticket assignment — remains essential. What changes is what triggers it: instead of every action requiring approval, only actions above a defined blast-radius or below a confidence threshold do.

Enrichment fan-out

Parallel evidence-gathering across threat intel, sandbox, and asset inventory is still best modeled as a fan-out/fan-in pattern, because it is embarrassingly parallel and has no real decision logic. The agent decides which enrichment to fan out to based on the hypothesis; the fan-out mechanics themselves stay a simple orchestration primitive.

Compliance and audit playbooks

Regulatory reporting timelines (breach notification windows, evidence preservation requirements) are fixed by law, not by risk judgment. These stay as rigid, deterministic playbooks precisely because you do not want a model's variable output determining whether a 72-hour notification clock was respected.

The practical takeaway is that agentic automation is a superset of SOAR capability, not a replacement architecture. The reasoning layer decides when and whether to invoke a deterministic playbook, a piece of enrichment, or a novel investigative path. Teams that try to throw away their existing playbook library when adopting agentic tooling end up rebuilding functionality they already had working reliably.

Safe automation: guardrails, approval tiers, and blast radius control

The single biggest objection to agentic response, and the correct one to take seriously, is: what stops the agent from taking a wrong, high-impact action autonomously? The answer is not "trust the model." It is a governance architecture that makes autonomous action safe by construction, independent of how good the underlying model is on any given day.

Tiered autonomy by action class

Every action in the tool registry gets classified into an autonomy tier, and the tier — not the model's confidence alone — determines whether it executes automatically:

• Tier 0 — read-only. Query logs, pull process trees, check reputation. No approval needed, fully autonomous, unlimited rate.
• Tier 1 — reversible, low blast radius. Isolate a single non-critical endpoint, disable a low-privilege account, add an IOC to a watchlist. Autonomous execution allowed, but logged with a rollback window and a notification, not a blocking approval.
• Tier 2 — reversible, moderate blast radius. Isolate a server, disable a privileged account, push a network segmentation rule. Requires async approval from an on-call analyst within a defined SLA (for example, 10 minutes), with a documented fallback if unanswered.
• Tier 3 — irreversible or high blast radius. Wipe a device, terminate a cloud workload, revoke domain admin, notify customers or regulators. Requires synchronous, named human approval every time, no exceptions, regardless of model confidence.

This tiering should be a static configuration owned by security leadership and audited quarterly — not something the agent itself can adjust. It is the single control that lets an organization say, credibly, that automation cannot exceed a defined blast radius no matter what the model does.

Confidence calibration, not confidence theater

Agent-reported confidence scores are only useful if they are calibrated against outcomes, not self-reported by the model in a vacuum. Build a feedback loop that tracks, per hypothesis type, how often a "high confidence" call was later confirmed true positive versus false positive, and recalibrate the threshold that gates Tier 2/3 escalation accordingly. A model that says 90% confidence but is right 60% of the time on a specific alert class is more dangerous than one that honestly reports 60%, because the governance layer is calibrated to trust the number.

Blast radius simulation before deployment

Before granting an agent write access to a new tool (say, cloud IAM policy modification), run it in shadow mode — propose actions without executing them — against historical incidents and live traffic for a defined period, and have analysts review every proposed action. Only promote a tool from shadow to live once the false-positive-action rate on that specific tool is below an agreed threshold, tool by tool, not blanket-approved for the whole agent.

Kill switches and circuit breakers

Rate-limit autonomous actions per time window per action type (no more than N host isolations per hour without escalation, for instance), and wire in a global and per-tenant kill switch that reverts the entire system to read-only/advisory mode instantly. This is the same discipline SREs apply to automated remediation in production infrastructure, and it applies identically here — a runaway automated response to a false positive can cause an outage indistinguishable from the attack it was meant to stop.

Immutable audit trail

Every hypothesis, every tool call, every governance decision (approved, denied, auto-executed, rate-limited) needs to be logged to an append-only store with the evidence available at decision time attached. This is not optional compliance overhead; it is what lets you debug why an agent did something six weeks after the fact, and it is what regulators and cyber-insurance underwriters will require before they accept autonomous response as a control in your risk posture. It is also the foundation of programs built around continuous threat exposure management, where every autonomous validation and remediation action needs a defensible record.

Worked example: credential compromise to contained incident

Walk through a concrete case to see the pattern end to end. At 02:14 local time, identity telemetry flags an impossible-travel event: a successful MFA-satisfied login for user jsmith from an IP geolocated to Singapore, eleven minutes after a login from the same account in Chicago. A correlation rule fires and opens a case with an initial hypothesis: credential compromise, moderate confidence (0.55), seeded from base rates for impossible-travel alerts at this organization.

The agent's reasoning loop begins:

1. Evidence gathering, round one. It queries the identity provider for the full session history of jsmith over the past 30 days (Tier 0, autonomous), checks whether the Singapore IP appears on any threat intel feed as a known VPN exit node or prior malicious source (Tier 0), and pulls MFA method used for both logins (Tier 0). Result: the Singapore login used a push-approval MFA method, not a phishable OTP fallback, and the IP has no prior reputation hits. Confidence adjusts down slightly to 0.48 — push-approval MFA is harder to compromise remotely, but not impossible (MFA fatigue attacks are a known technique).
2. Evidence gathering, round two. The agent forms a secondary hypothesis — MFA fatigue/push-bombing — and checks the push notification log for jsmith's account in the prior 24 hours (Tier 0). It finds six push prompts in the eight minutes preceding the Singapore login, five denied and one approved, all originating from the same authentication attempt pattern. Confidence on compromise jumps to 0.86.
3. Evidence gathering, round three. To distinguish a compromised session from a false positive (e.g., a legitimate travel scenario with a fumbled approval), the agent checks jsmith's calendar/travel-system integration (Tier 0, read-only) for any indication of scheduled travel, and pulls the device fingerprint of the Singapore session against jsmith's known device inventory. No travel record exists, and the device fingerprint does not match any previously enrolled device. Confidence rises to 0.93, now above the Tier 2 escalation threshold configured for this organization (0.85).
4. Action proposal. The agent proposes a Tier 2 action bundle: revoke the active session token, force password reset, temporarily suspend the account pending review, and isolate any endpoint that authenticated with that session in the interim. Because this bundle includes account suspension for a real user (moderate blast radius, reversible), it routes to the on-call SOC analyst via paging integration with a 10-minute SLA and the full evidence chain attached inline — not just a raw alert, but the entire hypothesis history.
5. Human decision. The analyst reviews the evidence in under two minutes (versus an estimated 20–30 minutes to manually pull the same evidence across four different consoles) and approves. The action plane executes: session revoked, password reset forced, account suspended, and — because the agent's earlier query found the compromised session had authenticated to a VPN concentrator — that specific VPN session is also torn down.
6. Verification. The agent does not close the case on action execution. It re-queries the identity provider two minutes later to confirm the session is actually terminated (not just that the API call returned success), checks for any new login attempts on the account, and monitors for lateral movement indicators from the device that held the compromised session for the next 60 minutes. Only after this verification window closes clean does the case move to "contained, pending investigation" rather than "closed."
7. Feedback. The case, with full evidence trail, is logged as a true positive for the MFA-fatigue hypothesis pattern. This updates the base confidence rate the agent uses the next time an impossible-travel alert with dense push-notification activity occurs, and it also feeds a recommendation to the identity team to move jsmith and similarly-scoped accounts to number-matching MFA rather than simple push-approval, closing the underlying weakness rather than just the incident.

Total elapsed time from alert to contained account: under four minutes, with a single two-minute human decision point instead of the 20–40 minutes a fully manual investigation typically takes for this alert class. Note what did not happen: the agent did not autonomously suspend a real employee's account without human sign-off, because the tiering rules said moderate-blast-radius actions on real user accounts require approval regardless of confidence level. This is the safe-automation discipline in practice, and it is the same pattern that underpins identity-centered detection and response workflows for privileged and standard accounts alike.

Measuring the journey: metrics that matter

SOAR programs were often measured on the wrong things — number of playbooks built, percentage of alerts touched by automation — metrics that reward breadth over outcome. An agentic program needs a different scorecard, one that measures whether the loop is actually closing faster and more accurately, not just whether more steps are automated.

Two of these deserve emphasis because they are the ones most programs skip. The automated action reversal rate is your ground-truth safety metric — it is the only number that tells you whether the governance layer's blast-radius controls are actually calibrated correctly. If this number is not being tracked, the organization cannot honestly claim its automation is safe, regardless of how sophisticated the model is. The false-positive escalation rate is the inverse quality signal on the reasoning layer — a program with excellent MTTT but a high false-positive escalation rate has just built a faster way to waste analyst time, not a better SOC.

It is also worth tracking these metrics segmented by alert source and threat class, not just in aggregate. An agentic system might achieve excellent MTTC on identity-based threats (well-instrumented, clear evidence chains) while performing poorly on cloud misconfiguration cases (sparser telemetry, more ambiguous ground truth). Aggregate metrics hide exactly the information you need to decide where to invest tuning effort next.

Migration roadmap: a phased approach

Organizations that attempt a wholesale rip-and-replace of SOAR with an agentic platform in one project cycle consistently struggle — not because the technology fails, but because the governance and trust-building work cannot be compressed. A phased approach, typically spanning two to four quarters depending on SOC maturity, works better in practice.

Phase 1 — Shadow reasoning (weeks 1–6)

Deploy the agentic reasoning layer in advisory-only mode against live alert traffic, wired to read-only tools exclusively. It forms hypotheses and proposes actions, but every proposal is logged and compared against what the human analyst actually decided, with no execution authority. This phase is purely about measuring agreement rate between agent and analyst, and surfacing where they diverge and why.

Phase 2 — Tier 0/1 autonomy (weeks 6–14)

Grant execution authority for read-only and low-blast-radius reversible actions only — enrichment, watchlist additions, single-endpoint isolation on non-critical assets. Keep everything above that gated to human approval, but route the approval requests through the agent's evidence packages instead of raw alerts, which alone often cuts analyst review time by half even before autonomy expands.

Phase 3 — Tier 2 autonomy with tight SLA approval (months 4–6)

Expand to moderate-blast-radius actions gated by fast async approval (the 10-minute SLA pattern from the worked example). This is where the reversal-rate metric becomes critical — do not advance past this phase until reversal rates on Tier 1 actions have been under 2% for at least a full month.

Phase 4 — Cross-domain expansion (months 6–12)

Extend the same reasoning-and-governance pattern beyond the initial alert source (often identity or endpoint) into network, cloud, and exposure management domains, and begin connecting agentic response to proactive exposure validation — using the same agent architecture to continuously test whether defenses actually hold against the techniques seen in recent cases, closing the loop between detection and prevention rather than treating them as separate programs.

Throughout all four phases, keep the existing SOAR playbook library running in parallel as the deterministic action layer described earlier — you are not migrating away from it, you are putting a reasoning layer in front of it and gradually shifting which decisions require a human. Retiring specific playbooks only makes sense once their trigger conditions are fully subsumed by agent-driven hypothesis paths with equal or better accuracy, which for compliance-fixed and irreversible-action playbooks may never fully happen, and that is fine.

Figure 3 — A four-phase rollout builds trust incrementally instead of granting broad autonomy on day one.

Common failure modes and how to avoid them

Having implemented and reviewed a number of these migrations, a handful of failure patterns recur often enough to call out specifically.

Over-scoping tool access early

Teams excited about agentic capability frequently grant broad tool access (full EDR isolation rights, full IAM write access) before the reasoning layer has proven itself on read-only tasks. This inverts the trust-building sequence and is the single most common cause of a damaging false-positive action that sets a program back months in stakeholder confidence.

Treating confidence scores as ground truth

A model's self-reported confidence is a starting point for calibration, not a finished product. Programs that wire governance thresholds directly to raw model confidence without calibrating against actual outcome data end up with either an overly cautious system that escalates everything, or an overly trusting one that autonomously executes on miscalibrated certainty.

Ignoring alert sources the agent cannot yet reason about well

Reasoning quality varies significantly by domain based on training data and tool coverage — an agent might be excellent at identity and endpoint reasoning but weak on OT/ICS anomalies or novel cloud service abuse. Blanket-deploying agentic triage across all alert sources without domain-specific validation produces inconsistent results that undermine trust in the system as a whole, even where it performs well.

Underinvesting in the verification step

Many implementations stop the loop at action execution and assume success. Verification — confirming the action actually had the intended effect and that no new risk emerged — is what separates a genuinely closed loop from an open one that merely looks closed. Skipping it means the first time an isolation API call silently fails, nobody notices until the attacker has moved laterally.

Letting the audit trail become an afterthought

Retrofitting proper logging after a program is live is far more expensive than building it in from the start, and the gap shows up exactly when it matters most — during a post-incident review or a regulator's inquiry into why an autonomous system took a specific action.

Static governance rules that never get revisited

Blast-radius tiers and approval thresholds set at project kickoff and never revisited drift out of alignment with the organization's actual risk posture as infrastructure, staffing, and threat landscape change. Schedule a quarterly governance review as a standing process, not an ad hoc one.

Where agentic automation is headed

The trajectory from here runs in a few concrete directions. First, multi-agent collaboration within a single case is becoming standard practice — a specialized identity-reasoning agent, a specialized endpoint-forensics agent, and a specialized network-behavior agent contributing evidence to a shared case rather than one generalist agent trying to reason across every domain equally well. This mirrors how human SOCs already specialize analysts by domain, and it produces measurably better hypothesis quality than a single monolithic reasoning pass.

Second, the boundary between detection-and-response and proactive exposure management is dissolving. An agent that investigates a credential-compromise case can, in the same reasoning loop, check whether the technique that succeeded would also work against other accounts with similar privilege and MFA configuration, and open a proactive remediation case before those accounts are ever targeted. This is the practical convergence of reactive SOC work with continuous exposure validation, and it is where the return on agentic investment compounds fastest — each incident makes the whole environment more resilient, not just that one account safer.

Third, agentic response is expanding beyond pure security operations into the broader IT operations boundary, where an agent investigating a security alert and an agent investigating a performance degradation increasingly need to share context — a security-driven account lockout and a service outage ticket opened five minutes later are very often the same event seen from two different consoles. Unified reasoning across the historically separate NOC/SOC boundary, rather than two parallel automation stacks that never talk to each other, is the direction platforms spanning both IT operations and security operations domains are converging toward, and it is reflected in integrated operating models built around converged NOC/SOC workflows and a shared AI-native platform stack underneath both.

Finally, the agentic workforce model itself is maturing from single-purpose response agents toward broader, coordinated digital labor that spans investigation, remediation, reporting, and even proactive hardening as distinct but cooperating roles — the pattern that underlies agentic AI workforce platforms like Norra, where different agent roles specialize the way human team members do, coordinated through the same governance discipline described throughout this piece rather than each acting as an unsupervised silo.

Frequently asked questions