Most "AI SOC" architectures are just this:
SIEM → LLM → Response
That is not an AI-native SOC.
It is an LLM connected to security infrastructure.
The difficult problem is not getting an LLM to investigate an alert.
The difficult problem is deciding what the agent can observe, what it can infer, what it can execute, and who controls those boundaries.
A useful architecture separates four planes:
┌──────────────────────────────────────────────┐
│ SECURITY DATA PLANE │
│ SIEM • EDR • IAM • Cloud • Network • Email │
└──────────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ EVIDENCE PLANE │
│ Events • Entity Graph • RAG • Threat Intel │
└──────────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ REASONING PLANE │
│ Triage • Hunt • Malware • Identity • Cloud │
└──────────────────────┬───────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ CONTROL PLANE │
│ IAM • Policy • Approval • Audit • Sandbox │
└──────────────────────────────────────────────┘
The LLM lives in the reasoning plane.
It should not be the control plane.
1. Agents Should Investigate, Not Own the SOC
A monolithic SOC Agent quickly becomes an excessive-privilege problem.
Instead:
Orchestrator
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Triage Hunt Identity
│ │ │
▼ ▼ ▼
Malware Network Cloud
│ │ │
└─────────────────┼─────────────────┘
▼
Correlation
│
▼
Response Planner
Each agent should have:
- A narrow responsibility
- Its own identity
- Explicit tool permissions
- Independent evaluation
- Separate audit trails
A hunt agent shouldn't be able to disable an account.
A malware agent shouldn't be able to modify firewall policy.
Agent boundaries are security boundaries.
2. Give Agents Evidence, Not Just Context
RAG alone isn't enough.
Consider:
PowerShell executed
↓
Suspicious parent process
↓
Encoded command
↓
Outbound connection
↓
Known malicious infrastructure
A vector database may retrieve:
"PowerShell is commonly abused by attackers."
Useful context.
But it is not evidence.
An AI SOC should maintain an evidence graph:
User
│
└──► Host
│
├──► Process
│ └──► Network Connection
│ └──► IOC
│
└──► File
└──► Hash
The agent can then reason over relationships rather than isolated documents.
3. Separate Facts From Hypotheses
An investigation should produce structured claims:
{
"finding": "Potential endpoint compromise",
"confidence": 0.84,
"evidence": [
"evt-1829",
"evt-1932",
"evt-1941"
],
"observations": [
"WINWORD spawned PowerShell",
"PowerShell used encoded arguments",
"Host contacted suspicious infrastructure"
],
"unknowns": [
"Initial access vector",
"User intent"
]
}
This is much safer than:
"This is definitely malware."
The important distinction is:
confidence is not evidence.
4. Tool Calling Is the Real Attack Surface
The dangerous part of an AI SOC isn't the chat interface.
It's this:
Untrusted Input
↓
LLM
↓
Tool Selection
↓
Security API
↓
Production
Imagine an agent has:
isolate_host()
disable_user()
block_ip()
reset_password()
delete_file()
A malicious email, ticket, document, or RAG entry could attempt to manipulate the agent into invoking those tools.
Therefore:
Agent
│
▼
Tool Request
│
▼
┌────────────────┐
│ Policy Engine │
└───────┬────────┘
│
┌─────────┴─────────┐
▼ ▼
Allow Require
Approval
│ │
└─────────┬─────────┘
▼
Execute
The model proposes.
The policy engine authorizes.
5. Treat Untrusted Data as Hostile
SOC agents consume enormous amounts of attacker-controlled content:
- Emails
- URLs
- Files
- Malware
- Tickets
- Web pages
- Threat reports
- Log messages
Any of these can contain prompt injection.
Therefore the system should maintain a strict distinction:
SYSTEM INSTRUCTIONS
≠
SECURITY DATA
Retrieved text should never gain authority merely because it appeared in the model context.
A useful hierarchy is:
System Policy
↓
Agent Policy
↓
Tool Policy
↓
Security Data
Never reverse it.
6. RAG Needs Provenance
Security knowledge should carry metadata:
{
"document": "EDR-Investigation-Runbook",
"source": "SOC",
"owner": "Security Engineering",
"version": "4.2",
"trust": "approved",
"expires": "2027-08-12"
}
This allows the agent to distinguish:
Approved Runbook
>
Analyst Note
>
External Report
>
Untrusted Content
RAG without provenance becomes a potential knowledge-poisoning layer.
7. Autonomy Should Be Risk-Bounded
Not every action deserves the same autonomy.
A useful model:
| Action | Example | Autonomy |
|---|---|---|
| Read | Search SIEM | Automatic |
| Enrich | IOC lookup | Automatic |
| Investigate | Process-tree collection | Automatic |
| Low impact | Create case | Automatic |
| Security control | Block IOC | Policy-dependent |
| High impact | Isolate production server | Approval |
| Critical | Disable privileged identity | Approval |
The important metric isn't:
"How autonomous is the SOC?"
It's:
"What is the maximum damage an agent can cause without human authorization?"
That should be explicitly bounded.
8. Agents Need Identity
Don't give every agent a shared SOC service account.
Use:
triage-agent
↓
SIEM:READ
hunt-agent
↓
SIEM:READ
EDR:READ
response-agent
↓
EDR:ISOLATE
CASE:WRITE
Use:
- Short-lived credentials
- Scoped permissions
- Tool-level authorization
- Rate limits
- Expiration
- Full audit trails
An AI agent should be treated like a workload identity, not an administrator.
9. The Response Agent Should Plan Before Acting
Instead of:
Alert → AI → isolate host
use:
Alert
↓
Evidence Collection
↓
Hypothesis
↓
Investigation
↓
Response Plan
↓
Policy Evaluation
↓
Approval
↓
Execution
↓
Verification
Example:
Response Plan
1. Preserve endpoint evidence
2. Collect process tree
3. Search fleet for IOC
4. Search related authentication activity
5. Isolate endpoint
6. Revoke sessions
The policy engine might automatically permit steps 1–4 while requiring approval for 5–6.
10. Verification Is Part of the Action
An agent should never assume its action succeeded.
Bad:
isolate_host()
"Host isolated."
Better:
isolate_host()
↓
query_isolation_status()
↓
status == isolated
↓
record evidence
Every high-impact action should follow:
PLAN → AUTHORIZE → EXECUTE → VERIFY → AUDIT
11. The AI SOC Control Loop
Putting the architecture together:
┌─────────────┐
│ Telemetry │
└──────┬──────┘
▼
┌─────────────┐
│ Detection │
└──────┬──────┘
▼
┌─────────────┐
│ Triage │
└──────┬──────┘
▼
┌─────────────┐
│ Hypothesis │
└──────┬──────┘
▼
┌─────────────────────┐
│ Evidence Collection │
└──────────┬──────────┘
▼
┌────────────┐
│ Correlation│
└─────┬──────┘
▼
┌────────────┐
│ Decision │
└─────┬──────┘
▼
┌────────────┐
│ Policy │
└─────┬──────┘
▼
┌────────────────┐
│ Human Approval │
└───────┬────────┘
▼
Execute
▼
Verify
▼
Audit
This is closer to an autonomous security control loop than a chatbot.
12. What Should Be Measured?
Traditional SOC metrics aren't enough.
Evaluate agents on:
Detection accuracy
Investigation completeness
Evidence correctness
Tool-selection accuracy
False-positive rate
Unauthorized-action rate
Mean investigation time
Human escalation rate
One metric deserves special attention:
Unauthorized destructive actions = 0
A system that investigates 30% faster but occasionally performs an unauthorized production action is not demonstrating useful autonomy.
13. Start Smaller Than You Think
Don't begin with 20 agents.
Start with:
SIEM
↓
Triage Agent
↓
Evidence Collection
↓
Threat Intelligence
↓
Investigation Report
↓
Human
Then introduce:
Hunting
↓
Correlation
↓
Response Planning
↓
Controlled Execution
Autonomy should be earned through evaluation.
The Architecture in One Diagram
AI-NATIVE SOC
│
┌─────────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
DATA PLANE REASONING PLANE CONTROL PLANE
│ │ │
SIEM / EDR Agents IAM
Identity RAG Policy
Cloud Graph Approval
Network Correlation Audit
Email Planning Sandbox
│ │ │
└─────────────────────┼─────────────────────┘
▼
SECURITY ACTIONS
The key architectural rule is:
Let AI reason broadly, but let it act narrowly.
An AI SOC should be capable of investigating thousands of events, correlating identities, endpoints, network activity and cloud telemetry, and constructing an evidence-backed incident narrative.
But its ability to change the environment should remain explicitly bounded by identity, policy, authorization and verification.
The future SOC isn't:
Human → Chatbot
It is:
Human
↕
Agentic Investigation
↕
Policy-Controlled Security Infrastructure
That is the difference between adding AI to a SOC and building an AI-native SOC.
Top comments (0)