AiSOC: An Auditable Open-Source AI Security Operations Center
An open-source AI SOC for security teams that audits every step with a replayable ledger instead of replacing SIEM retention.
GitHub beenuar/AiSOC Updated 2026-11-02 Branch main Stars 6.2K Forks 643
Python TypeScript Go Security Operations MITRE ATT&CK Kafka Postgres Docker Compose MCP

🧭 Decision Guide

Why trending now: Unable to determine from the provided material

Try it if you

  • You need a self-hosted security operations platform, alert correlation, and auditable AI investigations, and can run Docker Compose.
    The README calls it “An open-source, self-hostable AI Security Operations Center”; Quick start requires Docker Compose v2.
  • You want to verify an end-to-end ingestion path made of Kafka, detection, correlation, and Postgres.
    The “Then prove it works” section says make smoke verifies ingest, Kafka, detection, correlation, and Postgres.
  • You need rule-based and sliding-window detection rather than relying only on an AI model.
    How it works describes 2,538 executable rules, 76 sliding-window rules, and a 7,023-rule library.
  • You need to retain agent prompts, tool calls, and investigation evidence for reviewing AI conclusions.
    What AiSOC does says every prompt and tool call is recorded; Every answer carries its receipts describes signed evidence bundles.
  • You want to test a local model and CISA KEV threat intelligence without API keys.
    What it looks like running explicitly mentions the local model and the real CISA KEV catalog with no API key.

Skip it if you

  • You want to replace an existing SIEM’s long-term log retention or compliance search.
    What AiSOC is not explicitly says it is not a drop-in SIEM replacement and does not replace long-term log retention or compliance search.
  • Your data sources are not connected, but you expect the system to discover and read all telemetry automatically.
    What AiSOC is not explicitly says it cannot see unconnected telemetry and has no discovery.
  • You require automatic response after an alert without policy authorization or human approval.
    What AiSOC is not says the system is not autonomous by default; response requires explicit policy authorization and a human approver.
  • Your environment cannot provide 8 GB memory and 20 GB free disk to the Docker VM.
    Quick start requirements specify 8 GB memory and 20 GB free disk in the Docker VM.
  • You would treat sample incidents or benchmark numbers as real-incident accuracy.
    What AiSOC is not says demos and sample incidents are not real incidents, and benchmarks are substrate self-consistency measures.

Requirements

  • Docker Compose v2
  • 8 GB memory and 20 GB free disk in the Docker VM
  • python3 3.9+
  • bash
  • The first run downloads an approximately 2 GB model; the volume is cleared only by make clean
  • make doctor checks host tools, memory, disk, ports, and datastores

First step (verbatim from README)

make up

Watch out

  • The first make up run generates fifteen secrets in .env and shows the administrator password only once.
    Quick start says make up generates fifteen secrets; the administrator password is generated locally, shown once, and stored nowhere.
  • If 5432 or 11434 is already in use, installation continues but the console moves to a free port.
    Quick start says an occupied port does not stop installation and reports 64 seconds to a console when both ports are occupied.
  • make demo loads a fixed dataset where every row is marked is_synthetic = true, not a customer or real incident.
    The sample-data section says make demo uses a synthetic dataset and labels every row.
  • A playbook executes only when the deployment, tenant, and playbook switches all agree; otherwise it stays in preview.
    How it works says three switches must agree, all defaults are off, and insufficient conditions run in preview.
  • A rule earns executable status only after replay through a real connector and an observed firing, not from an enabled field.
    Executable is earned, not declared says a rule must receive a vendor-shaped replay and be watched to fire.

Not stated in the README

  • The README excerpt does not list supported real data sources, connector names, or configuration procedures for each connector.
  • The README excerpt does not identify the bundled local model, its version, or hardware performance.
  • The README excerpt does not state production replica counts, concurrency limits, or supported telemetry throughput.
  • The README excerpt does not provide the AI agent model configuration, context limits, or failure-retry behavior.
  • The README excerpt does not include the complete evaluation data or metric definitions from the Evaluation section.
  • The README excerpt does not expand the Security section, so authentication, isolation, key rotation, and vulnerability-response details cannot be assessed.
  • The README excerpt does not specify the complete MCP server tool list or version requirements for Claude, Cursor, and Continue.

💡 Deep Analysis

6
No We already rely on an existing SIEM for long-term log retention, compliance search, and enterprise-wide search. We want to replace it completely with AiSOC while retaining AI investigation and automated response. Is that replacement strategy viable?
For: A compliance security architect who already has long-term log retention and compliance search, but wants one system to replace the existing SIEM across all enterprise search scenarios

No; AiSOC is positioned as an auditable AI-enhanced SOC orchestration and investigation layer, not as a mature full-scale SIEM replacement.

  • The project insight explicitly states that it does not provide long-term log retention, comprehensive compliance search, or every enterprise search scenario, so it cannot assume the existing SIEM boundary.
  • AiSOC depends on connectors for telemetry and does not automatically discover organizational assets, data sources, or security tools. It cannot analyze telemetry that was never connected.
  • Rule count is not equivalent to comprehensive detection coverage: 2,538 of 7,023 rules are verified executable, while actual effectiveness depends on field completeness, connector quality, tenant tuning, and data coverage.
  • It is better used above existing logging, asset-management, endpoint-detection, and compliance-storage systems as an investigation and orchestration layer. Replacing the SIEM outright would leave explicit capability gaps.
  • Project insight: It cannot replace a complete SIEM and does not provide long-term log retention, comprehensive compliance search, or every enterprise search scenario
  • Project insight: It cannot analyze unconnected telemetry and does not automatically discover organizational assets, data sources, or security tools
  • Project insight: 2,538 of 7,023 rules are verified executable
  • Project insight: It should work with long-term logging, asset management, endpoint detection, and compliance storage systems
make doctor
Not stated in the README：The README does not specify bidirectional synchronization interfaces or migration tools between an existing SIEM and AiSOC；The README does not provide replacement-validation results for your retention period, search-latency, or event-volume requirements
Yes I am deploying on Windows, ports 5432 and 11434 are already occupied, and the machine lacks the full prerequisite set. I want the installer to handle prerequisites and expose the console without manually changing ports. Can AiSOC meet this requirement?
For: A security platform engineer deploying AiSOC on a bare Windows machine where ports 5432 and 11434 are already occupied, with GitHub Codespaces or an installer available for quick validation

Yes; the README explicitly covers Windows prerequisites, occupied ports, and validation paths without a prepared local environment.

  • On Windows, the README provides a PowerShell installer that handles prerequisites. Alternatively, the repository can be opened in GitHub Codespaces and started with make up.
  • Occupied ports 5432 and 11434 do not stop installation. AiSOC selects a free port, identifies what held the old one, and moves the console address; the README reports a signed-in console in 64 seconds on a bare clone.
  • Installation still requires Docker Compose v2, Python 3.9+, bash, and at least 8 GB of Docker VM memory plus 20 GB of disk. make doctor checks these conditions.
  • For an offline alert-path demonstration, aisoc-sandbox demo can run without Docker.
  • Quick start: On Windows ... `iwr -useb https://raw.githubusercontent.com/beenuar/AiSOC/main/install.ps1 | iex`
  • Quick start: A port already in use does not stop the install
  • Quick start: 64 seconds to a signed-in console on a bare clone with 5432 and 11434 both taken
  • Quick start: Without Docker at all, `pip install aisoc-sandbox && aisoc-sandbox demo`
iwr -useb https://raw.githubusercontent.com/beenuar/AiSOC/main/install.ps1 | iex
Not stated in the README：The README does not provide a detailed compatibility matrix for Docker Desktop, Hyper-V, or WSL2 on Windows；The README does not explain how the automatically selected free port integrates with enterprise proxy, firewall, or reverse-proxy policies
Yes I maintain 7,023 rules, but project data confirms only 2,538 as executable. I also need tenant-specific thresholds, rule disabling, and sliding-window rules for cross-event behavior. Can AiSOC support this validation workflow?
For: A detection engineer responsible for 7,023 detection rules, verified executability, tenant thresholds, and suppression settings

Yes; AiSOC directly supports replay-based rule validation, tenant tuning, and cross-event matching, but the total rule count must not be treated as production coverage.

  • Project data lists 7,023 rules, with 2,538 verified as executable. Executability requires replay through a real connector and the detection engine with an observed trigger; file presence or an enabled flag is insufficient.
  • There are also 76 sliding-window rules for cross-event counting or ordered-sequence matching, which supports behavior-chain validation rather than single-event matching.
  • Tenant-level tuning includes disabling rules, changing thresholds, and configuring suppression, and those settings are applied to the detection engine.
  • New threat intelligence can rescan historical data, but that mode is labeled re-hunting and cannot be counted as a prediction at the original event time.
  • Project insight: The rule library contains 7,023 rules, of which 2,538 are verified executable
  • Project insight: 76 sliding-window rules support cross-event counting or ordered-sequence matching
  • Project insight: Tenant-level detection tuning includes rule disabling, threshold adjustment, and suppression
  • Evaluation, reflex and replay: Replay is time-frozen; re-hunting is labelled
make smoke
Not stated in the README：The README does not provide the exact mapping coverage between your log fields and the existing rule fields；The README does not specify detection-engine limits for your event throughput and tenant count
Yes I need AI triage results to include the model verdict, confidence, rationale, and evidence citations, export investigations as signed evidence packages, and preserve response approvals across service restarts. Is AiSOC suitable for my incident-response workflow?
For: A blue-team incident responder who needs exportable, reviewable AI triage records with evidence citations and approval continuity after restarts

Yes; AiSOC makes both the AI investigation process and response approvals traceable state rather than storing only a final conclusion.

  • The project displays the model verdict, confidence, and rationale, while the Investigation Ledger records prompts, tool calls, investigation steps, and results for replay.
  • Investigation results can be exported as signed evidence packages in OCSF 1.9.0 format, with ledger references bound to verifiable conclusions.
  • Playbook responses default to preview mode. Deployment, tenant, and playbook switches plus human approval control actions; approval state is persisted in Postgres, survives restarts, and records expiration.
  • The boundary is important: a complete ledger proves what evidence and steps the model used, but it does not automatically prove that the AI conclusion is correct.
  • Project insight: The AI agent displays the model verdict, confidence, and rationale
  • Project insight: The Investigation Ledger records prompts, tool calls, and investigation steps for replay, audit, and evidence tracking
  • Project insight: Investigation results can be exported as signed evidence packages in OCSF 1.9.0
  • Project insight: Approval state is persisted in Postgres and survives restarts
make smoke
Not stated in the README：The README does not specify the key-management, rotation, or verification tools used for signed evidence packages；The README does not state field compatibility between OCSF 1.9.0 exports and existing forensic or compliance systems
It depends I need to ingest real security telemetry into a self-hosted SOC without external API keys. Our Docker VM has only 8 GB of memory and 20 GB of disk, and we do not want to maintain a full SIEM. Should we adopt AiSOC?
For: A small-business SOC lead who needs self-hosting, can run Docker Compose v2, and has about 8 GB of Docker VM memory and 20 GB of free disk

It depends; AiSOC fits as a self-hosted AI investigation and orchestration layer, but not as a complete SIEM when resources are tight or full retention and compliance search are required.

  • The README requires Docker Compose v2, at least 8 GB of Docker VM memory, and 20 GB of free disk. The first run also downloads an approximately 2 GB model, so your host is exactly at the stated floor.
  • It supports a local-model path without API keys and combines alert triage, MITRE ATT&CK investigation, and response recommendations.
  • The project explicitly does not provide long-term log retention, comprehensive compliance search, or every enterprise search scenario, so an existing log platform or SIEM must remain in place.
  • Real connectors must be configured; without them, the console represents an empty or sample environment rather than production detection capability.
  • Quick start: Needs Docker Compose v2 with 8 GB memory and 20 GB free disk in the Docker VM
  • Quick start: The first run downloads a ~2 GB model
  • Project insight: It cannot replace a complete SIEM and does not provide long-term log retention or comprehensive compliance search
  • Project insight: It does not automatically discover or connect an organization's existing security data
make doctor
Not stated in the README：The README does not provide resource curves for your specific connector types, daily event volume, or retention period；The README does not state actual local-model latency for your CPU, memory, or GPU configuration
It depends I plan to connect AiSOC to Claude, Cursor, and Continue through MCP. Our organization requires local data handling, restricted client permissions, and human approval for every high-risk action. Does this integration boundary meet those requirements?
For: A security engineer who needs to connect SOC investigations to Claude, Cursor, or Continue without allowing external AI clients to execute high-risk response actions

It depends; AiSOC provides a suitable local audit and approval boundary, but MCP itself does not solve external-client permissions, context leakage, or network governance.

  • The project description explicitly provides an MCP server for Claude, Cursor, and Continue, while the self-hosted deployment path does not require external API keys.
  • The Investigation Ledger records prompts, tool calls, investigation steps, and results, giving client-initiated investigations replayable audit evidence.
  • Responses default to preview mode and require deployment, tenant, and playbook switches plus human approval. Approval state is persisted in Postgres and survives restarts.
  • The project insight also states that MCP expands the entry point and increases requirements for permission management, context-leakage control, and action-boundary governance, so client credentials and network isolation remain separate responsibilities.
  • Project description: Ships an MCP server for Claude, Cursor and Continue
  • Project insight: The Investigation Ledger records every agent step, prompt, tool call, and result
  • Project insight: Response actions default to preview mode and are controlled by deployment, tenant, and playbook switches plus human approval
  • Project insight: MCP adds requirements for external AI-client permissions, context-leakage control, and action-boundary governance
make up
Not stated in the README：The README does not specify least-privilege configurations or concrete MCP authorization templates for Claude, Cursor, or Continue；The README does not quantify client-visible context scope, network-isolation methods, or data-redaction capabilities

✨ Highlights

  • 2,538 executable rules from a 7,023-rule library
  • Every AI investigation records prompts and tool calls
  • The Kafka-to-Postgres path is verified by make smoke
  • Runs CISA KEV threat intelligence without an API key
  • The first run downloads an approximately 2 GB local model

🔧 Engineering

  • Normalizes telemetry, then uses Kafka, rules, and correlation to create incidents
  • AI agents write their investigation process to the Investigation Ledger
  • Playbooks default to preview, while approval pauses persist in Postgres
  • Evidence exports are signed, byte-identical OCSF 1.9.0 bundles

⚠️ Risks

  • It is not a SIEM replacement and does not provide long-term retention or compliance search
  • Unconnected telemetry is invisible; the README explicitly says there is no discovery
  • Response is not autonomous by default and requires policy authorization and human approval
  • Demo data is synthetic and does not represent real incidents or live accuracy
  • The Docker VM needs 8 GB memory, 20 GB disk, and an approximately 2 GB model download

👥 For who?

  • Security teams needing a self-hosted SOC and auditable AI investigations
  • Engineering teams using Docker Compose, Kafka, and Postgres
  • Developers wanting MCP integration with Claude, Cursor, or Continue
  • Teams needing MITRE ATT&CK investigations and signed evidence bundles