AI SOC Vs SOAR: Playbooks, Agents And How They Work Together
Skip to content

AI SOC vs SOAR

SOAR automates defined workflows. AI agents investigate by querying evidence and adapting to what they find. Together, they combine flexible investigation with controlled execution.

What is SOAR?

SOAR stands for security orchestration, automation, and response. It connects security tools and runs playbooks that collect context, evaluate conditions, route cases, and execute response actions. The steps and decision branches are configured in advance.

A phishing playbook, for example, can extract URLs, check reputation, search for other recipients, and quarantine matching messages under approved conditions.

Predictable execution

Defined logic makes workflows straightforward to review and test. Given the same inputs and external results, the playbook follows the same path.

Fast, repeatable actions

Routine enrichment, ticket routing, and established response procedures run consistently with minimal manual effort.

Visible decision logic

Teams can inspect conditions, branches, and approval points before deployment, then trace execution through workflow logs.

Coordination across tools

Playbooks connect systems through APIs, moving evidence and triggering actions across email, endpoint, identity, and ticketing tools.

These capabilities may sit within a SIEM, a dedicated SOAR product, or another automation platform. This comparison focuses on predefined playbooks and adaptive AI investigation, which can operate together.

Where playbooks reach their limits

An unfamiliar result is easy to route to an analyst. Teaching a playbook what to do with every unfamiliar result is harder.

A sign-in comes from a trusted country, but the device is new. The user is traveling, but their mailbox has started forwarding messages externally. Each detail changes the investigation. A playbook can handle these conditions when someone has anticipated them and built the branches.

As tools, threats, and customer environments change, those branches need maintenance. More complex playbooks can become difficult to test, while scenarios outside their coverage still land with an analyst.

Playbooks remain valuable for established procedures. AI adds flexibility where the evidence determines which questions need answering.

How AI investigates beyond the playbook

AI agents can query live security data and follow connections that were not defined as individual workflow branches. They combine the alert with account history, endpoint activity, network evidence, and customer context to establish what happened and how far it extends.

Consider a risky sign-in. An approved location and clean IP reputation may support a legitimate explanation. An agent can investigate further: was the device expected, were authentication methods changed, and what did the account do afterward? An unexpected mailbox rule and unusual message access could change the assessment and prompt a wider search.

The distinction is how follow-up work is selected. A playbook follows configured conditions; an agent chooses relevant queries as findings emerge. Both depend on reliable integrations, sufficient evidence, and well-defined permissions.

The agent records its findings, source evidence, query history, proposed verdict, and response recommendations in the case. Analysts can validate the assessment and approve material actions without rebuilding the investigation from scratch.

For more detail, see AI SOC agents.

AI SOC vs SOAR compared

SOAR and AI agents can use the same security tools and perform many of the same tasks. The main difference is how the work is directed: playbooks follow predefined logic, while agents select investigative steps based on evidence and instructions.

AreaSOAR playbooksAI SOC agents
WorkflowExecute configured steps and conditional branches.Select queries and follow-up tasks as findings emerge.
InvestigationPerform the checks built into the workflow.Explore related activity within available tools, skills, and permissions.
Unexpected findingsFollow an existing branch or escalate.Assess the finding, gather more evidence, or escalate.
Environment contextApply context through configured lookups and rules.Interpret retrieved context alongside investigation evidence.
ResponseExecute defined actions and sequences, with configured approvals.Propose or invoke authorized actions, with required approvals.
ConsistencyFollow the same logic for the same inputs and external results.May take different investigative paths; outputs require ongoing quality checks.
Audit recordsPreserve workflow versions, execution steps, results, and approvals.Preserve agent configuration, tool calls, evidence, assessments, and approvals.
MaintenanceUpdate connectors, conditions, branches, and response procedures.Update tools, skills, and policies; test investigation quality after changes.

Neither approach guarantees a correct outcome. A playbook can reliably execute flawed logic, and an agent can misinterpret evidence. Both need testing, access controls, approval rules, and operational review.

Putting them together

Automate established procedures

Use playbooks for routine lookups, routing, ticket updates, and approved response sequences. These tasks benefit from explicit, repeatable execution.

Give agents room to investigate

Use agents to examine varied alerts, connect evidence across tools, and pursue findings that need additional context. Their scope should reflect the data and capabilities available to them.

Control actions at the point of execution

Whether a request comes from a playbook, an agent, or an analyst, the platform must enforce target scope, permissions, approvals, and execution limits.

Keep one investigation record

Bring workflow results, agent findings, and analyst decisions into the same case. This lets the team review the evidence, understand what ran, and continue the investigation without losing context.

One alert, two investigation approaches

A finance user grants an unfamiliar application, pdf-review-online, permission to read their mailbox and maintain access through refresh tokens. The consent could support a legitimate document service or expose company email to an attacker. The alert alone does not settle that question.

The following is an illustrative scenario.

With a SOAR playbook

The playbook performs its configured checks: retrieve the publisher details, inspect permissions, compare the application against an approved list, and identify the consenting user.

CheckFinding
Approved application?No
Verified publisher?No
Permissions granted?Mail.Read and offline_access
Existing approval record?None found
OutcomeEscalate for investigation

The playbook quickly establishes why the consent needs attention. If email tracing and application activity checks are included, it can collect those too. Its coverage depends on the workflow the team has built.

With an AI investigation

The agent uses those findings to investigate the application’s purpose, how consent was obtained, and what happened afterward.

01
Trace the consentSearch email records for messages linking to the application’s consent request. In this example, the user received a document-sharing lure shortly before granting access.
02
Examine application activityQuery available application and mailbox telemetry for activity associated with the app. The evidence shows mailbox access following consent, inconsistent with the claimed document-review purpose.
03
Establish the scopeSearch for other users who received the message, granted the same application access, or show related activity. Record confirmed exposure separately from recipients who merely received the lure.
04
Prepare the responseProduce an evidence-backed assessment of suspected consent phishing and prepare actions to disable the application and revoke its consent grant. Account containment is considered separately if evidence also indicates account compromise.

Where the difference matters

A comprehensive playbook could perform these same checks. AI adds the ability to select and extend them as findings emerge, reducing the need to predefine every investigative branch.

Both approaches need the correct response procedure. A password reset alone does not remove an illicit application consent grant; remediation must address the application’s access directly.

From investigation to controlled action

AI agents can establish what happened and recommend a response. Execution needs a separate set of checks: is the target correct, is the action permitted, could it disrupt a critical service, and does it require approval?

An AI SOC can use existing SOAR playbooks or dedicated response tools to carry out those actions. Established procedures remain useful, while agents supply the case-specific evidence and proposed targets.

ActionChecks before executionRecovery considerationExample mode
Revoke sessionsConfirm identity, protect emergency accounts, and limit affected users.Revoked sessions cannot be restored; users must reauthenticate.Approval required
Remove an inbox ruleConfirm the exact rule and preserve its configuration and evidence.Recreate an authorized rule if removal was incorrect.Approval required
Isolate an endpointConfirm the device, business role, dependencies, and permitted scope.Release isolation; assess any operational disruption separately.Approval required
Create an incidentCheck evidence, severity, ownership, and existing cases.Merge or close duplicate records while preserving history.Autonomous within policy

The execution layer validates every request, whether it comes from an agent, analyst, or playbook. It enforces tenant permissions, target exclusions, approval requirements, and rate and scope limits, then records the result and checks whether the action succeeded.

Automation can expand for specific actions after testing and approval. Changing the operating mode does not remove the execution checks or make an irreversible action reversible.

What to keep, adapt, or retire

Existing playbooks contain valuable integrations, response procedures, and operational knowledge. Introducing AI starts with understanding which parts still work well and where investigation needs more flexibility.

Keep

Retain reliable enrichment, routing, and response workflows. Agents can invoke these through controlled interfaces, preserving existing checks and approvals.

Adapt

Review playbooks whose investigation logic has become difficult to maintain. Move suitable evidence gathering and analysis to agents while retaining useful rules, response steps, and escalation requirements. A single playbook may contain both.

Retire

Remove obsolete or duplicate workflows after checking dependencies and coverage. Low execution frequency alone is not a reason to retire a playbook: rare incidents may still need a tested response. Disable candidates first and preserve their configuration and history.

Introducing AI alongside SOAR

Start with a focused investigation use case while existing automation continues operating. Your SIEM, integrations, and proven response workflows can remain in place.

1
Map existing automationRecord each playbook’s purpose, trigger, data dependencies, actions, approvals, and owner. Identify investigation bottlenecks and select an initial use case.
2
Connect evidence and actionsGive agents scoped access to the required security data. Expose retained playbooks as callable workflows where appropriate, keeping execution controls intact.
3
Validate without actingRun agents in recommend-only mode on representative cases. Compare evidence quality, conclusions, escalations, and analyst effort. Prevent duplicate response actions during parallel operation.
4
Transition one workflowMove the selected investigation workflow into production once acceptance criteria are met. Define ownership, monitor results, and retain a clear fallback.
5
Authorize specific actionsEnable approved response actions individually, with target restrictions, execution limits, and recovery procedures. Independent execution requires separate validation and authorization.
6
Simplify the old workflowsRemove superseded branches after confirming coverage and dependencies. Preserve the version history and continue reviewing the combined AI and SOAR workflow as tools and threats change.

The ThreatDefence AI SOC platform

ThreatDefence connects AI agents to the security tools you already use, providing one operational layer for triage, investigation, response, threat hunting, and detection engineering. The platform supports self-managed, managed, co-managed, and white-label delivery.

The ThreatDefence Auto Triage dashboard showing AI-investigated alerts, automatically resolved benign cases, evidence-backed escalations, and verdict distribution

The platform integrates with your existing security stack and provides native capabilities you can add as your needs grow:

Operating modes

Workflows support recommend-only, approval-required, or autonomous operation within approved limits. Customers authorize increases in autonomy, every change is recorded, and individual workflows can be suspended immediately.

Agent runtime

Agents run in isolated sandboxes based on OpenShell, governed by declarative policies maintained in version control. Network access is restricted to approved destinations, and credentials are represented to agents as placeholders rather than exposed secrets.

Data regions

The platform operates in Australia and the United States, with customer data and AI processing remaining in the designated region. Model requests are filtered and anonymized before submission. Enterprise model terms exclude training on customer data, and customer data is never used to train shared models.

Compliance support

The platform supports security operations aligned with applicable SOCI Act obligations. Essential Eight reporting provides visibility into assessed controls and areas requiring improvement.

Quality reporting

Senior analysts review investigation quality and sample AI-closed alerts. Monthly reporting tracks analyst agreement, verdict overrides, incorrect closures, and reversed automated actions, with metrics also available in the portal’s SOC performance views.

Tools for analysts and partners

Analyst AI assistants

Analysts can use their own AI assistants to investigate through the platform. Plugins for Claude and OpenAI connect to tenant data and tools through the ThreatDefence SOC MCP server, enforcing authorized roles and tenant access while logging every tool call.

Skills library

The updatable skills library covers endpoint behavior, persistence, Microsoft 365 investigations, data exfiltration, network anomalies, exposure, leaked credentials, and threat hunting. Authorized MSP and MSSP analysts can also search across client tenants within their assigned permissions.

White-labeled for partners

MSPs and MSSPs can deliver the platform under their own brand, with shared case access for co-managed investigations and procedures and autonomy configured per client. Investigation skills developed by a partner remain that partner’s intellectual property.

See the ThreatDefence AI SOC in action

Faster investigations. Clear evidence. Coordinated response.

    I'm an MSP, MSSP, or reseller

    By submitting this form, you accept the terms in our privacy policy.

    Frequently Asked Questions

    What is the difference between an AI SOC and SOAR?

    SOAR automates predefined workflows. An AI SOC uses agents to query evidence and adapt investigations as findings emerge. Both can connect to the same tools and support response.

    Does an AI SOC replace SOAR?

    It can take over some investigation workflows while retaining useful playbooks. Agents can investigate varied activity, then invoke established procedures for enrichment, routing, or approved response.

    Can AI agents use my existing SOAR playbooks?

    Yes, where the platform supports calling them through APIs or workflow interfaces. Existing permissions, checks, and approval requirements should remain enforced.

    When is a playbook the better choice?

    When a task has clear inputs and established steps, such as updating a ticket or executing an approved containment sequence. Agents add value when findings require interpretation and further investigation.

    Are AI agents less predictable than playbooks?

    Their query choices and assessments can vary, even with similar inputs. Permissions and execution limits constrain what they can do, while testing and ongoing review assess the reliability of their conclusions.

    How are AI-recommended actions controlled?

    The execution layer checks permissions, targets, approvals, and scope before an action runs. It records the outcome and verifies success. A recommendation alone does not authorize execution.

    How do I introduce AI alongside SOAR?

    Start with one investigation workflow in recommend-only mode. Validate evidence quality, conclusions, escalations, and analyst effort before production use. Authorize response actions separately.

    Which playbooks should I keep, adapt, or retire?

    Keep reliable automation, adapt investigation workflows that need greater flexibility, and retire obsolete or duplicate content after checking dependencies. Rarely used incident procedures may still be essential.