AI SOC Agents vs SOAR Playbooks: Choosing the Right Automation for Each Alert

SOAR playbooks do exactly what they were written to do, AI SOC agents decide what to do at run time, and most SOC automation failures come from giving one of them a job that needs the other. A playbook is a fixed workflow: a trigger, a set of steps, conditions and actions that run the same way every time. An AI SOC agent is a large language model wrapped with tools, memory and instructions that reads an alert, chooses which lookups to run and proposes or takes an action. This guide compares the two as approaches, not products: determinism and auditability, coverage of novel alerts, the credentials and response rights each needs, hallucination and prompt injection risk, failure modes and a hybrid design that uses both. It is for SOC managers, detection and automation engineers, and security architects deciding where each belongs.

Key takeaways

• Determinism is the dividing line. A playbook produces the same steps for the same input and can be reviewed line by line before it runs; an agent's reasoning path can differ between two runs on the same alert, so its evidence has to be captured at run time.
• Agents earn their place on the long tail. Playbooks cover known, high-volume alert types well; agents add value where alerts are novel, poorly documented or need open-ended investigation across many data sources.
• Response rights belong to deterministic code. Let the agent investigate and recommend; route containment such as host isolation or credential revocation through a playbook step or approval gate that checks the request against policy.
• Both are privileged non-human identities. The SOAR and the agent hold API credentials for EDR, identity, email and firewall tools; an agent also reads attacker-controlled text, which makes least privilege and complete mediation in downstream systems mandatory.
• Hybrid beats either alone. The mature pattern is playbooks for intake, enrichment and action execution, with an agent in the middle for triage reasoning and case narrative, each measured on its own metrics.

The short answer

Use SOAR playbooks wherever the alert type is well understood, the correct response can be written down in advance and the action needs to be repeatable and provable to an auditor: phishing report handling, known-bad indicator blocking, account lockout workflows, ticket creation. Use AI SOC agents for the parts of triage that resist being written down: summarising a noisy alert cluster, deciding which of twenty enrichment sources matter for this case, writing a case narrative, or investigating an alert type nobody has built a playbook for yet. Keep the authority to change production systems with deterministic, policy-checked steps, whichever component proposed the action.

The joint ASD's ACSC and CISA guidance on implementing SIEM and SOAR platforms states that a SOAR is usually not suitable for immature environments and that the SIEM must be implemented and alerting accurately first. The same prerequisite applies with more force to agents: an agent reasoning over unreliable alerts and incomplete logs produces confident conclusions from bad evidence. See the SOAR vs SIEM guide for that sequencing decision.

Side-by-side comparison

SOAR playbooks in depth

Architecture in words

A SOAR platform receives an alert or case from the SIEM, EDR or email gateway, matches it to a playbook and runs the steps through connectors that call each tool's API. The open OASIS CACAO Security Playbooks Version 2.0 specification (Committee Specification 01, November 2023) is a useful neutral model of what a playbook is: a workflow of typed steps (start, end, action, playbook action, parallel, if condition, while condition and switch condition), commands such as HTTP API, PowerShell, SSH, OpenC2, Sigma and Yara, eight playbook types from detection and investigation through mitigation and remediation, version identifiers, digital signatures and TLP data markings. Each of those properties supports audit: you can show a reviewer exactly which version ran and that it was not altered.

Threat model

• Connector credential theft: the SOAR holds standing API keys or OAuth clients for every tool it orchestrates. Compromise of the platform is compromise of all of them. See Securing the SOAR platform itself.
• Playbook tampering: an attacker or careless insider edits a playbook to suppress alerts or add an exfiltration step. Signed, version-controlled playbooks and change approval counter this.
• Trigger abuse: an attacker who learns that a given alert causes automatic isolation can raise that alert against a critical server to cause an outage.

Failure modes

The practitioner guidance from ASD's ACSC warns that a misconfigured SOAR may treat normal user or system behaviour as an incident and isolate systems, disrupting service delivery, and that a SOAR bought without the skills to maintain it may sit unused. In practice the commonest breakage is quiet: a vendor renames an API field, a connector token expires, the playbook stops enriching and nobody notices until an investigation finds blank fields.

Decision criteria

Choose a playbook when you can write the response as a decision tree on one page, the alert type arrives often enough to repay the build effort, and the action must be identical and provable each time.

AI SOC agents in depth

Architecture in words

An AI SOC agent combines a language model, a system prompt describing its role, a set of tools (SIEM search, EDR query, threat intelligence lookup, ticket update, and sometimes containment actions), short-term memory for the case and often retrieval over runbooks and past cases. For each alert it plans a set of queries, reads the results, iterates and writes a verdict with reasoning. The live AI SOC Guide covers autonomy levels and evaluation; this section concentrates on what differs from a playbook.

Threat model

• Prompt injection through evidence: the agent reads email bodies, file names, process command lines and web content written by the attacker. The NCSC describes an LLM as an inherently confusable deputy that does not separate instructions from data, and says prompt injection may never be fully mitigated, only reduced in likelihood and impact. See MITRE ATT&CK T1698 Indirect Prompt Injection.
• Excessive agency: OWASP LLM06:2025 names three root causes (excessive functionality, excessive permissions and excessive autonomy). An agent given a generic "run query" or shell tool, broad write scopes and no approval step has all three. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide.
• Confabulation: NIST AI 600-1 defines confabulation as generative AI systems generating and confidently presenting erroneous or false content. In a SOC that looks like a cited log line that does not exist or a benign verdict justified by evidence the agent never retrieved.
• Automation bias: NIST AI 600-1 also lists human-AI configuration risks, including automation bias and over-reliance. Analysts who approve agent verdicts all day stop checking them.

Failure modes

Agent failures are rarely loud. The agent closes a true positive as benign with a fluent explanation, skips a data source because a query timed out, or follows an instruction embedded in a phishing email to mark the message as safe. Model or prompt updates can change behaviour across every alert type at once, which a single playbook change never does.

Decision criteria

Choose an agent when the alert type is variable, the investigation path depends on what the first lookups return, the output is a recommendation a human or a playbook will act on, and you can afford to sample and grade its verdicts.

Determinism, auditability and evidence

Auditors and incident reviewers ask two questions: what happened and why. A playbook answers "why" before the incident, in its definition; an agent answers it only through what was recorded during the run. Treat agent runs as evidence-generating events and capture the following for each:

Stored this way, an agent run can be replayed for review even though re-running it would not reproduce it. The AI Agent Audit Log Schema Template gives a field-level starting point.

Agent credentials and response rights

Both approaches act through the same EDR, identity provider, email and firewall APIs, so the identity design is where most risk is decided. The SOAR's connectors are already powerful non-human identities; an agent adds a decision-maker that can be talked into misusing them.

• Separate read and write identities: give the agent read-only credentials for investigation tools. Containment actions run under the SOAR's connector identity, invoked by a playbook that validates the request.
• Complete mediation downstream: OWASP LLM06 recommends enforcing authorisation in downstream systems rather than relying on the model to decide what is allowed. A protected-asset list (domain controllers, payment systems, executive mailboxes) should be enforced by the action playbook, not by instructions in the prompt.
• Privileges follow the data: the NCSC's principle is that when an LLM processes information from a party, its privileges drop to that party's. An agent reading an external email has, in effect, the privileges of the sender, so it should not hold rights that sender should never have.
• Short-lived, scoped tokens: issue per-task tokens where the tool supports it, rotate connector secrets from a vault and log every privileged call (SP 800-53 AC-6(9)).

See the Agent Identity and Access Guide and the AI Agent Permission Matrix Template.

Worked scenario: one suspicious login, two approaches

An identity provider raises "impossible travel" for a finance user, followed ten minutes later by a new inbox rule that forwards invoices externally.

1. Playbook path: the playbook matches the impossible-travel alert, enriches the IP with reputation and geolocation, checks whether the user is on a travel exception list, and opens a case. It has no branch for the inbox rule because that arrives as a separate alert, which a second playbook handles in isolation. Each step is predictable, but nobody correlates the two until an analyst picks up the case.
2. Agent path: the agent receives the case, queries sign-in logs, notices the inbox rule alert for the same user, pulls the rule definition and recent sent items, and writes a narrative: likely account takeover with business email compromise intent. It recommends revoking sessions, removing the rule and resetting credentials. It has also read the forwarded invoice text, which could contain injected instructions, so its recommendation is treated as untrusted input.
3. Hybrid path: the agent's recommendation is posted to a "contain account" playbook. The playbook checks the user is not on the protected list, confirms the session revocation API target matches the user in the case, requests one-click analyst approval because the user is in finance, then executes and records every call. Investigation used the agent's flexibility; the action used the playbook's control.

When to use each

Small organisations usually get more from tuning detections and using managed services than from either option. Large SOCs should expect to run both and to staff an automation engineering function that owns playbooks, prompts, tool manifests and evaluation sets as code. The Security Automation Maturity Model helps place the team.

Designing the hybrid, step by step

1. Stabilise detection first: confirm the SIEM alerts accurately and that the alert types you plan to automate have low false positive rates.
2. Codify the known: build playbooks for the five to ten highest-volume alert types, enrichment first, actions later. The SOAR and Security Automation Guide covers what to automate first.
3. Introduce the agent in shadow mode: let it triage the same alerts analysts handle, with no write access, and compare verdicts for several weeks on a labelled evaluation set that includes true positives and injected content.
4. Promote to recommend: the agent drafts verdicts and narratives into cases; analysts accept or override, and every override is captured as training data for evaluation.
5. Wire actions through playbooks: expose containment only as playbook calls with policy checks, protected-asset lists, rate limits and approval steps for high-impact actions. See the Human-in-the-Loop for AI Agents Guide.
6. Test continuously: run exercises with known techniques and new attack paths to confirm automation acts on alerts as intended, as the ASD's ACSC guidance recommends, and re-run the agent evaluation set after any model, prompt or tool change.
7. Keep a rollback: every agent integration needs a switch that returns its alert types to the playbook or human queue in minutes, and every playbook change keeps the previous version deployable.

Detection and measurement

• Agent verdict agreement rate: share of sampled agent verdicts that a senior analyst agrees with, tracked per alert type.
• False negative rate on seeded cases: true positives (including red team and purple team cases) that the agent closed as benign. This matters more than raw accuracy.
• Playbook execution success rate: runs completing without connector errors; a drop usually means an API or schema change.
• Coverage: percentage of alert volume handled by a playbook, by an agent, or by humans only, reviewed monthly to decide what to codify next.
• Action override and reversal count: containment actions reversed as wrong, split by whether a playbook or an agent proposed them.
• Mean time to triage: per alert type, before and after each change, alongside analyst hours spent reviewing agent output.

Monitor the automation itself: alert on agent tool calls outside the expected set, failed or denied calls (which the NCSC notes may indicate an attacker refining an injection), playbook definition changes and connector credential use from unexpected hosts.

Common failure patterns

• Giving the agent the SOAR's credentials: one identity for investigation and containment means a single injected instruction can reach production systems.
• Guardrails in the prompt only: "never isolate domain controllers" written in a system prompt is a request, not a control; enforce it in the action layer.
• Measuring agents on accuracy alone: a high agreement rate on easy alerts hides missed true positives; grade on seeded hard cases.
• Letting playbooks rot: no owner, no tests, no alert on connector failure, so enrichment silently stops.
• Re-platforming instead of hybridising: replacing working playbooks with an agent loses determinism where it mattered and adds model cost to alert types that were already solved.
• Rubber-stamp approvals: approval gates that analysts click through hundreds of times a shift recreate the automation bias NIST AI 600-1 describes. Keep approvals for actions that warrant them.

Framework mapping

NIST SP 800-61 Rev. 3 places incident response within CSF 2.0 risk management and is the reference for the response process both approaches serve.

Decision checklist

• Is the alert type well understood with a written response? Playbook.
• Does the investigation path depend on what early lookups return? Agent, recommending only.
• Does the action change production systems or user access? Playbook with policy checks, approval for high impact.
• Will an auditor or regulator ask why a decision was made? Playbook logic, or full agent run records.
• Does the input contain attacker-controlled text? Treat agent output as untrusted and restrict its rights.
• Can you grade agent output on a labelled set before go-live? If not, keep it in shadow mode.

Practitioner checklist

• Confirm SIEM alert fidelity for every alert type before automating it with either approach.
• Store playbooks, prompts, tool manifests and model versions in version control with review.
• Give agents read-only investigation credentials; route all containment through playbooks.
• Enforce protected-asset lists and rate limits in the action layer, not the prompt.
• Capture model version, prompt version, tool calls, retrieved data and approvals for every agent run.
• Build an evaluation set with seeded true positives and injected content; re-run it after every change.
• Alert on playbook failures, connector errors and unexpected agent tool calls.
• Review coverage monthly and turn recurring agent investigations into playbooks.
• Keep a tested switch to return any alert type to playbook or human handling.

Standards and references

• OASIS: CACAO Security Playbooks Version 2.0
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: AI 600-1, Generative Artificial Intelligence Profile
• ASD's ACSC: Implementing SIEM and SOAR Platforms, Practitioner Guidance
• ASD's ACSC: Implementing SIEM and SOAR Platforms, Executive Guidance
• CISA: Guidance for SIEM and SOAR Implementation
• OWASP: LLM06:2025 Excessive Agency
• NCSC: Prompt injection is not SQL injection (it may be worse)

Related NHI Mgmt Group resources: AI SOC Guide · SOAR and Security Automation Guide · SOC Analyst Career Guide · SOC Analyst Interview Questions and Answers · Alert Fatigue Reduction Guide