AI in the SOC: orchestrating specialized agents

Artificial intelligence (AI) is already transforming security operations, but its value does not lie in a universal tool. For Security Operations Center (SOC) teams, the most robust model combines multiple specialized agents, each integrated at a precise step in incident response.

This article presents an orchestration architecture applicable to environments combining SIEM, incident management, sandbox and SOAR. It also details the prerequisites, security controls and a generic PowerShell script for chaining these capabilities without giving a single agent an excessive scope.

Why a single AI is not enough in a SOC

Incident response covers very different tasks: ingesting millions of events, qualifying an alert, reconstructing a timeline, analyzing a malicious file, and then executing a containment measure. These operations do not rely on the same data, the same models, or the same levels of criticality.

A generalist AI can summarize an event or propose a hypothesis, but it should not simultaneously have the rights necessary to query all telemetry, modify tickets and isolate workstations. This concentration increases the blast radius of a model error, injected prompt, or compromised account.

The specialized agent approach instead makes it possible to:

• limit the data accessible at each step;
• assign different permissions according to the function;
• replace a component without rebuilding the entire chain;
• require human validation before irreversible actions;
• measure the quality of each agent separately.

Four agents to cover the incident response cycle

SIEM agent: detection and triage

The agent connected to the security information and event management (SIEM) system processes telemetry streams, correlates weak signals and reduces noise before presentation to an analyst.

Its role is not necessarily to automatically close alerts. It can first enrich each signal with a confidence level, the entities involved, the rules triggered and the reasons for the correlation.

Useful outputs are structured rather than written solely in natural language:

• alert identifier and timestamp;
• users, hosts, IP addresses and resources involved;
• detection hypothesis;
• confidence score and justification;
• indicators to transmit to subsequent steps.

Case management agent: context and investigation

The second agent works on the incident file. It gathers associated events, reconstructs a timeline, detects similar historical incidents and updates ticket fields.

This step is particularly useful when multiple apparently independent alerts concern the same user, workstation or cloud workload. The agent must, however, maintain the distinction between observed facts, correlations and hypotheses.

A quality operational summary must answer four questions:

• What happened and when?
• Which identities or resources are affected?
• What evidence supports the current hypothesis?
• What action is recommended, with what level of confidence?

Sandbox agent: analysis and intelligence

The sandbox agent analyzes suspicious files, URLs or payloads in an isolated environment. It can extract indicators of compromise (IOC), observe triggered behaviors and transmit results to the incident file.

Separation is essential: a sandbox should only receive elements necessary for analysis. Sensitive data present in a file should not be exported to an external AI service without control of classification, retention and residency.

Results must remain machine-exploitable: hashes, domains, IP addresses, paths, registry keys, observed processes and verdict. The human summary complements this data, not replaces it.

SOAR agent: response and remediation

The final agent transforms validated results into response actions via a security orchestration, automation and response (SOAR) system. It can prepare a playbook, request approval or execute an authorized action such as revoking a session or containing a host.

SOAR should not interpret free text alone to decide on a critical action. Actions should be selected from a controlled list, with validated parameters, complete logging and a possibility of rollback where it exists.

Comparing agent responsibilities

The following breakdown helps assign permissions and define validation criteria before integration.

Data contracts and operational safeguards

Orchestration becomes fragile when each agent produces different text. Define a common contract, ideally in JSON, with mandatory fields and controlled values. The confidence field must be accompanied by a justification; an isolated score does not constitute proof.

Minimum prerequisites are as follows:

• a stable identifier for the alert and case;
• a clock and common date format;
• a data classification before transmission;
• distinct authentication for each webhook or API;
• service accounts without global admin privileges;
• logging of requests, responses, errors and human decisions;
• a correlation mechanism to trace all execution.

Propagation time depends on each product: SIEM ingestion, case creation, sandbox analysis and SOAR execution can be asynchronous. The workflow must therefore handle statuses accepted, running, completed and failed, rather than considering a successful HTTP response as the end of processing.

Implementation

The following example provides a PowerShell 7.4 orchestrator compatible with internal webhooks. It does not depend on any proprietary API: each security tool must expose an adapter complying with the JSON contract defined by your team.

Prerequisites and minimal permissions:

• PowerShell 7.4 or later; no additional modules are required;
• HTTPS network access to all four endpoints;
• a token limited to the operations provided by these endpoints;
• read permissions on the local alert file;
• write permissions on the output directory;
• application permissions specific to each product, without tenant-wide role if the publisher allows a more restricted scope.

By default, the script runs in simulation mode. It produces a JSON traceability file and displays the payloads that would be sent. Actual execution requires the -Execute switch.

1[CmdletBinding()]
2param(
3    [Parameter(Mandatory = $true)]
4    [ValidateScript({ Test-Path -LiteralPath $_ -PathType Leaf })]
5    [string]$AlertPath,
6 
7    [Parameter(Mandatory = $false)]
8    [string]$OutputPath = '.\soc-orchestration-result.json',
9 
10    [Parameter(Mandatory = $false)]
11    [switch]$Execute
12)
13 
14Set-StrictMode -Version Latest
15$ErrorActionPreference = 'Stop'
16 
17# The URIs are provided by the environment to avoid recording secrets in the script.
18$endpoints = [ordered]@{
19    Siem     = $env:SOC_SIEM_WEBHOOK
20    Case     = $env:SOC_CASE_WEBHOOK
21    Sandbox  = $env:SOC_SANDBOX_WEBHOOK
22    Soar     = $env:SOC_SOAR_WEBHOOK
23}
24 
25foreach ($name in $endpoints.Keys) {
26    if ([string]::IsNullOrWhiteSpace($endpoints[$name])) {
27        throw "Environment variable SOC_$($name.ToUpper())_WEBHOOK is missing."
28    }
29}
30 
31$token = $env:SOC_WEBHOOK_TOKEN
32if ($Execute -and [string]::IsNullOrWhiteSpace($token)) {
33    throw 'SOC_WEBHOOK_TOKEN is required with -Execute.'
34}
35 
36function Invoke-SocAgent {
37    param(
38        [Parameter(Mandatory = $true)]
39        [string]$Name,
40 
41        [Parameter(Mandatory = $true)]
42        [string]$Uri,
43 
44        [Parameter(Mandatory = $true)]
45        [hashtable]$Payload
46    )
47 
48    $json = $Payload | ConvertTo-Json -Depth 10
49 
50    if (-not $Execute) {
51        Write-Host "[SIMULATION] $Name -> $Uri"
52        Write-Output ($Payload | ConvertTo-Json -Depth 10)
53        return [pscustomobject]@{
54            agent  = $Name
55            status = 'simulated'
56            data   = $Payload
57        }
58    }
59 
60    $headers = @{
61        Authorization = "Bearer $token"
62        Accept        = 'application/json'
63    }
64 
65    try {
66        $response = Invoke-RestMethod -Method Post -Uri $Uri -Headers $headers -ContentType 'application/json' -Body $json
67        return [pscustomobject]@{
68            agent  = $Name
69            status = 'completed'
70            data   = $response
71        }
72    }
73    catch {
74        throw "Agent $Name failed: $($_.Exception.Message)"
75    }
76}
77 
78# Read the alert and create a stable correlation identifier.
79$alert = Get-Content -LiteralPath $AlertPath -Raw | ConvertFrom-Json
80$correlationId = [guid]::NewGuid().ToString()
81$receivedAt = [DateTime]::UtcNow.ToString('o')
82 
83$triage = Invoke-SocAgent -Name 'siem' -Uri $endpoints.Siem -Payload @{
84    correlationId = $correlationId
85    receivedAt    = $receivedAt
86    alert         = $alert
87}
88 
89$case = Invoke-SocAgent -Name 'case-management' -Uri $endpoints.Case -Payload @{
90    correlationId = $correlationId
91    triage        = $triage.data
92}
93 
94$sandbox = Invoke-SocAgent -Name 'sandbox' -Uri $endpoints.Sandbox -Payload @{
95    correlationId = $correlationId
96    case          = $case.data
97    indicators    = $alert.indicators
98}
99 
100# SOAR receives previous results. The adapter must apply its own approval policy.
101$soar = Invoke-SocAgent -Name 'soar' -Uri $endpoints.Soar -Payload @{
102    correlationId = $correlationId
103    case          = $case.data
104    sandbox       = $sandbox.data
105    executionMode = if ($Execute) { 'execute' } else { 'simulate' }
106}
107 
108$result = [ordered]@{
109    correlationId = $correlationId
110    executionMode = if ($Execute) { 'execute' } else { 'simulate' }
111    startedAt     = $receivedAt
112    completedAt   = [DateTime]::UtcNow.ToString('o')
113    agents        = @($triage, $case, $sandbox, $soar)
114}
115 
116$result | ConvertTo-Json -Depth 20 | Set-Content -LiteralPath $OutputPath -Encoding utf8
117Write-Host "Result written to $OutputPath"

The input alert can comply with this minimal contract. Field names must remain consistent between adapters so that agents can be replaced independently.

1{
2  "alertId": "INC-2026-0001",
3  "severity": "high",
4  "title": "Suspicious sign-in followed by unusual process activity",
5  "createdAt": "2026-09-04T08:15:00Z",
6  "entities": [
7    {
8      "type": "user",
9      "value": "analyst@example.com"
10    },
11    {
12      "type": "host",
13      "value": "WS-042"
14    }
15  ],
16  "indicators": [
17    {
18      "type": "ip",
19      "value": "203.0.113.10"
20    }
21  ]
22}

Configure the endpoints and first run a simulation. Expected return values are status = simulated for all four agents and executionMode = simulate in the output file.

1$env:SOC_SIEM_WEBHOOK = 'https://soc-adapter.example.invalid/siem'
2$env:SOC_CASE_WEBHOOK = 'https://soc-adapter.example.invalid/case'
3$env:SOC_SANDBOX_WEBHOOK = 'https://soc-adapter.example.invalid/sandbox'
4$env:SOC_SOAR_WEBHOOK = 'https://soc-adapter.example.invalid/soar'
5 
6.\soc-orchestrator.ps1 -AlertPath .\alert.json -OutputPath .\simulation.json

After validating the payloads, execution mode transmits the Bearer token to the adapters. Each endpoint must return a JSON document; HTTP errors or non-exploitable responses should fail the workflow rather than trigger silent remediation.

1$env:SOC_WEBHOOK_TOKEN = Read-Host 'SOC adapters token' -AsSecureString
2$plainToken = [System.Net.NetworkCredential]::new('', $env:SOC_WEBHOOK_TOKEN).Password
3$env:SOC_WEBHOOK_TOKEN = $plainToken
4 
5.\soc-orchestrator.ps1 -AlertPath .\alert.json -OutputPath .\execution.json -Execute
6 
7Get-Content -LiteralPath .\execution.json -Raw | ConvertFrom-Json |
8    Select-Object correlationId, executionMode, startedAt, completedAt

For production verification, check for the same correlationId in the logs of all four adapters, compare the statuses returned by the tools and confirm that no SOAR actions were executed during simulation. Full propagation must be measured on your environment as it depends on queues, asynchronous analyses and throughput limits of each product.

Troubleshooting common errors

The script reports a missing environment variable

All four URLs are mandatory, even in simulation, as they are part of the orchestration contract. Check their presence in the same PowerShell process with Get-ChildItem Env:SOC_* and verify that no names have been mistyped.

Execution fails with a 401 or 403 error

The token is missing, expired or insufficiently authorized. Check the audience expected by the adapter, its validity duration and its scope. Do not fix the issue by assigning a global admin role: instead create a separate service account for each integration.

An agent responds but the workflow remains incomplete

A successful HTTP response does not guarantee that the analysis is complete. The adapter must return a processing identifier and an exploitable status if the operation is asynchronous. Then add a polling step or event callback with the same correlationId.

The AI summary contradicts the evidence

Treat generated text as a hypothesis. Go back to raw events, sandbox results and identity logs. Block any automatic action when required evidence is missing, contradictory or classified with insufficient confidence.

What the team should implement Monday morning

Start by mapping the four functions to already deployed tools, then define a common JSON schema and correlation identifier. Separately measure the noise reduced by triage, time to constitute the file, quality of IOCs and rate of approved SOAR actions.

Then deploy orchestration in simulation mode, on a representative set of historical incidents. Only activate containment actions after validating false positives, permissions, audit logs and rollback process.

If your SOC already has multiple specialized automations, the next step is probably not to add another AI. It is to formalize their contracts, reduce their privileges and circulate verifiable results between them rather than isolated summaries.