{"slug": "aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent", "title": "AiSOC: How an Open-Source AI Security Operations Center Audits Every Agent Decision", "summary": "An open-source project called AiSOC (6,106 GitHub stars, MIT licensed) provides a self-hosted security operations center that routes correlated security incidents to LLM agents, records every prompt, tool call and state transition in a replayable decision ledger, and requires human approval before any response is executed. The system runs 2,534 executable rules from a 7,015-rule library, maps investigations to MITRE ATT&CK, and exposes read-only security tools to Claude, Cursor and Continue through an MCP server, keeping the agent unable to block IPs, quarantine hosts or disable accounts on its own.", "body_md": "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?\n\nThe 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.\n\nTraditional 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.\n\nThe decision ledger captures:\n\nThis 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.\n\nAiSOC does not hand every firewall log to an agent. It runs a correlation pipeline first:\n\nOnly 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.\n\nAlert 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.\n\nAiSOC 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.\n\n``` python\n# Simplified LangGraph flow for incident triage\nfrom langgraph.graph import StateGraph\n\nworkflow = StateGraph()\n\nworkflow.add_node(\"assess_severity\", assess_severity_node)\nworkflow.add_node(\"lookup_mitre\", lookup_mitre_node)\nworkflow.add_node(\"query_threat_intel\", query_threat_intel_node)\nworkflow.add_node(\"propose_response\", propose_response_node)\nworkflow.add_node(\"await_approval\", await_approval_node)\n\nworkflow.add_edge(\"assess_severity\", \"lookup_mitre\")\nworkflow.add_edge(\"lookup_mitre\", \"query_threat_intel\")\nworkflow.add_edge(\"query_threat_intel\", \"propose_response\")\nworkflow.add_edge(\"propose_response\", \"await_approval\")\n\n# Decision ledger hooks into every node transition\nworkflow.add_middleware(decision_ledger_middleware)\n```\n\nThe MCP (Model Context Protocol) server exposes tools to Claude, Cursor, and Continue. Each tool is a security primitive:\n\n`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\nThe 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.\n\nAiSOC assumes the agent can be wrong or compromised. The approval workflow separates investigation from execution:\n\nThe 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.\n\nAiSOC 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.\n\nThe no-API-key constraint means you bring your own LLM:\n\nThe 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.\n\nA minimal AiSOC deployment runs on a single host:\n\nFor production, you scale horizontally:\n\nObservability 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.\n\n| Failure Mode | Impact | Mitigation | \n|---|---|---|\n| Agent hallucinates a threat | False positive, wasted analyst time | Require multiple corroborating alerts before escalation; tune rule thresholds | \n| Agent misses a real incident | False negative, undetected breach | Retroactive sweeps with updated threat intel; human review of dismissed incidents | \n| LLM API timeout during triage | Incident stuck in queue | Retry with exponential backoff; fallback to rule-based triage if agent unavailable | \n| Decision ledger corruption | Lost audit trail | Append-only ledger with cryptographic checksums; replicate to immutable storage | \n| Agent proposes destructive action | Potential service disruption | Human approval gate; dry-run mode for new response types; rollback playbooks | \n| Telemetry ingestion backlog | Delayed detection | Separate ingestion from rule execution; prioritize high-severity sources | \n\nThe 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.\n\n**Use AiSOC when:**\n\n**Avoid AiSOC when:**\n\nAiSOC 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.\n\n**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.\n\n**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.\n\nThe 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.", "url": "https://wpnews.pro/news/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent", "canonical_source": "https://dev.to/mech_app_ai/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent-decision-301m", "published_at": "2026-11-01 20:06:55+00:00", "updated_at": "2026-11-01 20:22:22.656446+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "agent-protocols", "ai-tools", "artificial-intelligence"], "entities": ["AiSOC", "LangGraph", "Model Context Protocol", "MITRE ATT&CK", "Claude", "Cursor", "Continue", "CISA KEV"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent", "markdown": "https://wpnews.pro/news/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent.md", "text": "https://wpnews.pro/news/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent.txt", "jsonld": "https://wpnews.pro/news/aisoc-how-an-open-source-ai-security-operations-center-audits-every-agent.jsonld"}}