AiSOC: How an Open-Source AI Security Operations Center Audits Every Agent Decision

AiSOC (6,106 GitHub stars, MIT licensed) is a self-hosted Security Operations Center that hands security alerts to LLM agents, records every reasoning step in a replayable ledger, and gates all responses behind human approval. It addresses the core trust problem in security automation: how do you verify an agent's decision when it's triaging a potential breach?

The project runs 2,534 executable rules from a 7,015-rule library, correlates raw telemetry into incidents, and investigates each one using MITRE ATT&CK mappings. Every prompt, tool call, and state transition goes into an audit log you can replay. The architecture assumes you cannot trust the agent's output until a human reviews the chain of reasoning.

Why a SOC needs a decision ledger

Traditional SIEM and SOAR platforms execute playbooks. AiSOC replaces the playbook with an agent that reasons over alerts, but security teams need to answer "why did the agent recommend blocking this IP?" six months later during an incident review.

The decision ledger captures:

• Every prompt sent to the LLM, including context from previous alerts
• Tool calls (MITRE ATT&CK lookups, threat intel queries, historical event searches)
• State transitions in the LangGraph orchestration flow
• Token counts and model selection per reasoning step
• Human approval or rejection timestamps

This is not observability for debugging. It is compliance evidence. When an agent proposes quarantining a host, the ledger shows which alerts triggered the investigation, which MITRE techniques matched, and which threat intel feeds influenced the decision.

Alert fusion: from raw telemetry to incidents

AiSOC does not hand every firewall log to an agent. It runs a correlation pipeline first:

1. Normalization: Ingest telemetry from SIEMs, EDR tools, and network sensors into a common schema
2. Rule execution: Apply 2,534 detection rules (Sigma, YARA, custom logic) to identify suspicious patterns
3. Grouping: Cluster fired rules by time window, affected assets, and MITRE technique into incidents
4. Prioritization: Score incidents by severity, asset criticality, and threat intel matches

Only after this pipeline does an agent receive an incident object. The agent's job is triage (confirm or dismiss) and investigation (gather context, map to ATT&CK, propose response). This keeps token costs manageable and prevents the agent from drowning in noise.

Alert fusion also enables retroactive sweeps. When new threat intelligence arrives (a fresh IOC feed, a CISA KEV update), AiSOC re-runs rules against historical telemetry and surfaces incidents the original rules missed.

Architecture: LangGraph orchestration with MCP tool boundaries

AiSOC uses LangGraph to model the agent workflow as a state graph. Each node is a reasoning step, and edges represent transitions based on agent output or external events.

# Simplified LangGraph flow for incident triage
from langgraph.graph import StateGraph

workflow = StateGraph()

workflow.add_node("assess_severity", assess_severity_node)
workflow.add_node("lookup_mitre", lookup_mitre_node)
workflow.add_node("query_threat_intel", query_threat_intel_node)
workflow.add_node("propose_response", propose_response_node)
workflow.add_node("await_approval", await_approval_node)

workflow.add_edge("assess_severity", "lookup_mitre")
workflow.add_edge("lookup_mitre", "query_threat_intel")
workflow.add_edge("query_threat_intel", "propose_response")
workflow.add_edge("propose_response", "await_approval")

# Decision ledger hooks into every node transition
workflow.add_middleware(decision_ledger_middleware)

The MCP (Model Context Protocol) server exposes tools to Claude, Cursor, and Continue. Each tool is a security primitive:

• search_alerts(query, time_range): Query normalized telemetry
• get_mitre_technique(technique_id): Fetch ATT&CK details and detection guidance
• lookup_ioc(indicator): Check threat intel feeds for IP, domain, or hash
• get_asset_context(asset_id): Retrieve asset criticality, patch status, and historical alerts

The MCP boundary enforces read-only access. The agent cannot execute responses (block an IP, quarantine a host, disable an account). It can only propose actions and write them to the approval queue.

Human-in-the-loop gate: preventing agent self-approval

AiSOC assumes the agent can be wrong or compromised. The approval workflow separates investigation from execution:

1. Agent completes triage and writes a response proposal (JSON object with action type, target, justification, and ledger reference)
2. Proposal enters a queue visible in the web console
3. Human analyst reviews the proposal, inspects the decision ledger, and approves or rejects
4. On approval, AiSOC executes the action via vendor APIs (firewall rule, EDR isolation, identity revocation)
5. Execution result appends to the ledger

The agent cannot approve its own proposals. The approval queue is outside the agent's state graph. This prevents scenarios where a compromised agent or a hallucinated reasoning chain triggers destructive actions.

Self-hosting and the no-API-key constraint

AiSOC runs entirely on your infrastructure. No telemetry, prompts, or incident data leave your network. This matters for regulated industries (finance, healthcare, government) where security telemetry is classified or subject to data residency rules.

The no-API-key constraint means you bring your own LLM:

• Local models: Run Llama, Mistral, or Qwen via Ollama or vLLM
• Private cloud: Deploy OpenAI-compatible endpoints on your VPC
• Air-gapped: Use quantized models on GPU nodes with no internet access

The MCP server adapts to any OpenAI-compatible API. You configure the endpoint, model name, and token budget. AiSOC tracks token usage per incident and surfaces cost in the dashboard, but it does not send data to third-party APIs.

Deployment shape and observability

A minimal AiSOC deployment runs on a single host:

• PostgreSQL: Stores normalized telemetry, incidents, and the decision ledger
• Redis: Queues incoming telemetry and agent tasks
• Web console: React app for incident review, approval queue, and ledger replay
• Agent runtime: Python process running LangGraph workflows
• MCP server: Exposes tools to Claude Desktop, Cursor, or Continue

For production, you scale horizontally:

• Multiple agent runtimes behind a task queue (Celery, Temporal)
• Read replicas for the PostgreSQL ledger
• Separate ingestion nodes for high-volume telemetry streams
• Prometheus metrics for rule execution latency, agent token usage, and approval queue depth

Observability focuses on the decision ledger. The web console lets you replay any incident investigation step-by-step, inspect the prompts and tool outputs, and verify the reasoning chain. This is not just for debugging. It is how you train new analysts and refine detection rules based on agent behavior.

Failure modes and mitigation

The most dangerous failure is silent: the agent dismisses a real incident because it misinterprets context. AiSOC mitigates this by requiring the agent to justify dismissals in the ledger and surfacing dismissed incidents in a weekly review queue.

Trade-offs: when to use AiSOC vs. commercial SOAR

Use AiSOC when:

• You need full audit trails for compliance (SOC 2, FedRAMP, GDPR)
• You cannot send security telemetry to third-party APIs
• You want to customize detection rules and agent reasoning logic
• You have the infrastructure to self-host and the team to operate it

Avoid AiSOC when:

• You need turnkey deployment with vendor support
• Your team lacks the capacity to tune detection rules and agent prompts
• You require integrations with niche security tools (AiSOC's connector library is growing but incomplete)
• You want a managed service with SLAs

AiSOC is not a drop-in replacement for Splunk Enterprise Security or Palo Alto Cortex XSOAR. It is a framework for building a SOC where agent reasoning is transparent and every decision is replayable.

Technical Verdict

Use AiSOC if you need a self-hosted SOC where every agent decision is auditable, you can operate LangGraph workflows, and you require full control over detection logic and LLM selection. The decision ledger and human approval gate make it viable for security-critical environments where agent mistakes have regulatory or operational consequences.

Avoid it if you need a managed service, lack the infrastructure to run PostgreSQL and agent runtimes at scale, or require integrations with dozens of security vendors out of the box. The project is MIT licensed and actively developed, but it assumes you will write connectors and tune rules yourself.

The core insight is sound: agents in security operations must be auditable, and auditability requires capturing every reasoning step in a replayable ledger. AiSOC shows how to build that ledger into the orchestration flow without breaking the agent's feedback loop.

Source Links

• Primary repository: github.com/beenuar/AiSOC
• Technical guide (PDF): 27-page architecture doc
• Documentation: beenuar.github.io/AiSOC