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.
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:
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.
AiSOC does not hand every firewall log to an agent. It runs a correlation pipeline first:
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.
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.
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")
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.
AiSOC assumes the agent can be wrong or compromised. The approval workflow separates investigation from execution:
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.
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:
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.
A minimal AiSOC deployment runs on a single host:
For production, you scale horizontally:
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 Mode | Impact | Mitigation |
|---|---|---|
| Agent hallucinates a threat | False positive, wasted analyst time | Require multiple corroborating alerts before escalation; tune rule thresholds |
| Agent misses a real incident | False negative, undetected breach | Retroactive sweeps with updated threat intel; human review of dismissed incidents |
| LLM API timeout during triage | Incident stuck in queue | Retry with exponential backoff; fallback to rule-based triage if agent unavailable |
| Decision ledger corruption | Lost audit trail | Append-only ledger with cryptographic checksums; replicate to immutable storage |
| Agent proposes destructive action | Potential service disruption | Human approval gate; dry-run mode for new response types; rollback playbooks |
| Telemetry ingestion backlog | Delayed detection | Separate ingestion from rule execution; prioritize high-severity sources |
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.
Use AiSOC when:
Avoid AiSOC when:
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.
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.