AiSOC: The Free Open-Source AI SOC That Shows Its Work

A security operations center has one job that never ends: look at every alert your firewalls, laptops, cloud accounts, and login systems produce, and decide which ones are real. The sorting, called triage, is the bottleneck of the whole operation. It is repetitive, it is relentless, and every security team is short-staffed for it. That is exactly the job AiSOC, an open-source AI security operations center, is trying to take off the analyst's desk, and it is doing it on GitHub Trending: the project picked up more than a thousand stars in roughly two days, crossing 6,545 stars on November 2, 2026.

AiSOC is a self-hosted SOC platform under the MIT license. It ingests your security telemetry, detects and correlates threats, investigates them with AI agents whose reasoning is fully recorded, and proposes responses that a human must approve. The hook that separates it from the usual "AI for security" pitch is auditability: every prompt, every tool call, every citation, and every verdict lands in an Investigation Ledger that exports as a signed evidence bundle. You do not have to trust the agent's summary, because you can replay its reasoning step by step.

This article covers what AiSOC actually does, what the free price tag really costs you, how to run it today, and the catches the project's own documentation is refreshingly upfront about.

What AiSOC actually is

AiSOC is not a single model or a chatbot bolted onto a log viewer. It is a full pipeline that runs as a set of containers on your own server. Telemetry arrives from your security tools through 91 click-and-connect connectors (Splunk, Sentinel, Elastic, CrowdStrike, Okta, AWS, and Kubernetes audit are among the ones with vendor-specific normalization), or through an ingest API, or through four real collectors that read the surfaces a cloud estate actually emits to: CloudTrail trails on S3 notified over SQS, GCP Pub/Sub, Azure Event Hubs, and a syslog/CEF listener.

Ingest normalizes events to a common shape, then Kafka carries everything downstream. Fusion runs the detection engine: 2,538 executable rules drawn from a 7,023-rule library, plus 76 sliding-window rules, with your tenant's own tuning layered on top. Related alerts get grouped into incidents, and that is where the agents come in.

The agents read the alert, its correlated siblings, entity context, and prior verdicts for the same signature. They call typed tools (lake queries, graph traversals, enrichment lookups) and never write SQL. Everything is logged to the Investigation Ledger, and grounding is checked: a verdict that cites an indicator the evidence never contained gets demoted to human review instead of auto-closing. Prompts are validated before they are sent, and raw logs or secret-shaped values are refused, not redacted after the fact.

Then comes the part that matters most in security: nothing touches a vendor system without a human. A playbook triggered by an alert starts in preview. Three switches must agree (the deployment, the tenant, the playbook), and every default is off. An approval step is a durable pause that survives a restart and expires with a recorded outcome rather than hanging. Separately, new threat intelligence sweeps the history you already collected, so a fresh indicator re-scans old telemetry for sightings.

The numbers, read carefully

Per the project's README, verified live on November 2: 6,545 stars, 671 forks, 38 open issues. Independent coverage put the count at 5,489 stars on October 31, which means the project gained more than a thousand stars in about two days. It sat at number 10 on GitHub Trending on November 2 with 446 stars for the day. Star counts measure attention, not production installs, and this project is only six months old (created May 2, 2026).

The detection-engine numbers need the same careful reading the project itself asks for. "2,538 executable rules" does not mean 2,538 proven threat detections. A rule joins the compiled ruleset only after a vendor-shaped event is replayed through the real connector and engine and that rule is watched firing, and the README says plainly that "reachable" is not the same as "detects an attack." Two rules still cannot fire at all and are waiting on a behavioural baseline. That is an unusually honest denominator for a security product.

The triage reliability figure is the most important number in the repo. The bundled model is a pinned Llama 3.2 with 3 billion parameters (llama3.2:3b-instruct-q4_K_M), served by Ollama on CPU, downloaded once at about 2 GB. Over 50 alerts, the project measured usable triage output 44 times before constraining the reply to JSON, and 50 times after. That is the real ceiling of the default install: a small local model doing first-pass triage, not a frontier model doing analyst-grade reasoning. For serious work, you plug a larger provider in from the console, and the project's tables mark hosted-provider performance as "not measured" rather than inventing a number.

How to run it today

The quick start is two commands:

git clone https://github.com/beenuar/AiSOC && cd AiSOC
make up

On Windows, or a machine with nothing installed, one line handles prerequisites (iwr -useb https://raw.githubusercontent.com/beenuar/AiSOC/main/install.ps1 | iex). On Linux and macOS it is the equivalent shell one-liner. With no Docker at all, pip install aisoc-sandbox && aisoc-sandbox demo walks one alert through the agent funnel offline in under 30 seconds. With no machine at all, you can open the repo in GitHub Codespaces and run make up in its terminal.

Requirements: Docker Compose v2 with 8 GB of memory and 20 GB of free disk inside the Docker VM, plus Python 3.9 or newer and bash. make doctor checks all of it before you start. make up generates a .env with fifteen secrets, creates an administrator, and prints its password once, shown once and stored nowhere. Three deployment profiles cover the range:

Core is the smallest deployment that takes a real event and produces a real alert, and it needs no credentials to do it. Then prove it works: make smoke posts one real event to the ingest API and follows it through Kafka, detection, correlation, and Postgres, reporting PASS or FAIL at ten stages. The project's docs also ship a 27-page technical guide (v1.2, October 31) covering server sizing, failure modes, the REST API, and MCP.

What "free" actually costs

AiSOC costs nothing in license or seat fees. The MIT license means you can read, modify, and run it commercially without paying the project. The real costs are the ones the README does not hide:

• Hardware. The floor is a Docker host with 8 GB of memory and 20 GB of free disk. The full profile wants about 12 GB. That is a modest VM, not a laptop afterthought.
• Operations time. Self-hosting a 16-to-22-service stack means you own upgrades, backups, and the occasional broken container. make doctor helps, but it is still your pager.
• Model bills, if you upgrade. The bundled 3-billion-parameter model runs locally at zero marginal cost and produces real triage verdicts with real token counts in the ledger. If you connect a commercial model from the console, you pay that provider's rates, and the project has never exercised a hosted provider itself, so expect to measure performance yourself.

One funding detail worth knowing: development is funded and supported by Cyble, the threat-intelligence company, whose CEO and co-founder Beenu Arora publishes the repo from his own GitHub account. The credits file says Cyble pays for the engineering time and releases everything under MIT with no Cyble-only features and no telemetry flowing back. Independent coverage also notes a separate closed commercial Cyble product built on the same platform, which is not part of the free repository. That is the standard open-core arrangement, and it is not a flaw, but you should know who shapes the roadmap before you build an internal process on the tool.

The part worth stealing: the honesty engineering

Most security tools bury their limitations. AiSOC publishes a document called Repository Reality, a self-audit dated September 23, 2026, that reads like a confession. It admits the quick start of the time was broken: the install script handed off to a nine-service compose file with no ingest and no fusion service, while a seeding script wrote 15 fabricated incidents straight into the database. A new user followed the README, saw a populated console, and concluded the platform worked, having never run the platform. The audit also caught a user-behavior module reading a Kafka topic nobody fed, and a component classified as dead code that was actually in use. Everything is reported fixed in later versions, but writing "the quick start proved nothing" in black and white is not a showroom move.

The same candor shows up in the security record. On May 27, 2026, a researcher filing issue 220 showed that a prompt injection in the classification agents could make them close an alert automatically. The fix landed in under 15 hours. In a SOC, attacker-controlled text is everywhere (a filename, a user agent string, a commit message), so how a tool handles hostile text matters more than how many alerts it closes. The README also states its limits plainly: not a drop-in SIEM replacement, cannot see telemetry you never connected, not autonomous by default, and its benchmark numbers are "substrate self-consistency measures, not live agent accuracy."

Where it fits, and where it doesn't

The honest comparison is not AiSOC versus a commercial SIEM. It is AiSOC on top of a collector you already run.

If you already collect logs, AiSOC is the agent layer that sorts and investigates them. If you collect nothing, start with a free SIEM like Wazuh and put AiSOC on top. If you need compliance search and multi-year retention, this is not that product, and it says so itself.

The catches

• The bundled model is a 3-billion-parameter local model. It is fine for first-pass triage on CPU, and the project's own measurement says so. Do not expect frontier-model judgment from it.
• Two detection rules still cannot fire, two of 7,023, waiting on a behavioural baseline. Tiny, but it tells you the counts are real.
• The npm packages are not published yet; the first upload needs a registry token. The five PyPI packages, including the sandbox, work today.
• It cannot see telemetry you have not connected. There is no discovery, no magic.
• Version numbers are racing: the September audit referenced v8.1.0, October 31 shipped v20.4.0, and the README now shows v21.0.0. A fast version counter says nothing about maturity.
• Copies of the repository exist under other GitHub accounts. Check that the owner is beenuar before running any install script.
• There is no independent review and no external security audit on record. The stars measure attention, and attention is a reason to inspect, not to deploy to production.

Pro tips and common mistakes

Do run make smoke before connecting anything real. Do start with the sample-data scenarios in the setup wizard before pointing it at production telemetry. Do save the admin password when make up prints it; it is shown once. Do read the Repository Reality audit if you are evaluating the code seriously.

Don't grant any playbook autonomy until you have watched it in preview; approver and requester cannot be the same person. Don't treat the demo incidents as evidence of detection quality; they are synthetic by design. Don't connect a paid model without a spend cap and your own accuracy measurement. Don't lose the generated .env; fifteen credentials are minted per deployment and are not committed anywhere.

Is AiSOC really free?

Yes. The license is MIT, with no license fee and no seat count, and you can use it commercially. The real costs are the hardware (a Docker host with at least 8 GB of memory) and any paid-model API calls if you choose not to use the bundled local model.

Who builds AiSOC?

The project lives on the GitHub account of Beenu Arora, CEO and co-founder of the threat-intelligence company Cyble. Cyble funds the engineering time and releases it all under MIT. There is also a separate closed commercial Cyble product on the same platform that is not part of the free repository.

Does it replace my SIEM?

No, and the project says so plainly. It correlates and investigates; it does not do long-term log retention or compliance search, and it cannot see telemetry you never connected. The natural spot is on top of a collector you already run, such as a free SIEM like Wazuh.

What hardware do I need?

Docker Compose v2 with 8 GB of memory and 20 GB of free disk, plus Python 3.9 or newer. The core profile runs 16 services; the full profile with the event lake, entity graph, and full-text search runs 22 and wants about 12 GB. The first run downloads a roughly 2 GB local model.

Does it work without an OpenAI or Anthropic API key?

Yes. A quantized Llama 3.2 (3 billion parameters) ships with the install and produces real triage verdicts with token counts in the ledger, all on CPU. The one external feed in a fresh install is the public CISA Known Exploited Vulnerabilities catalog, which needs no key.

Can it close alerts or act on its own?

Not by default. Every response action needs a human approver, playbooks start in preview, and the three enable switches (deployment, tenant, playbook) are all off. A tenant can grant autonomy for specific verbs, but a verdict that cites evidence that does not exist gets demoted to human review instead of closing.

Is it production-ready?

For the lab, yes. The core pipeline has end-to-end tests and a self-audit, and the honesty about limits is rare. For production, the project is six months old, the bundled model is small, hosted-provider performance is unmeasured, and there is no external security audit on record. Trial it on your own data before trusting it with real incidents.

The takeaway

AiSOC is the rare security tool that tells you where it is weak: a small local model, two rules that cannot fire yet, benchmark numbers it labels as self-consistency rather than accuracy, and a self-audit that once admitted the quick start proved nothing. What it offers in return is a free, self-hosted SOC that triages alerts with agents and keeps a signed, replayable receipt for every verdict, with humans holding every response action. For a lab or a team that wants to watch an AI agent reason about alerts without handing it the keys, that is an interesting proposition. Just do what the project's own docs keep telling you to do: verify it on your own data before you believe it.

This is general information, not procurement or legal advice.

Sources

• AiSOC repository and README (official; star/fork/issue counts verified on the live repo page, November 2, 2026)
• AiSOC documentation portal (official)
• AiSOC Technical Guide v1.2 (official, 27-page PDF, released October 31, 2026)
• Repository Reality self-audit (official, dated September 23, 2026)
• Pasquale Pillitteri, "AiSOC launches on GitHub, an open source SOC with AI agents" (October 31, 2026; independent launch coverage, 5,489-star count)
• AI Understanding, "AiSOC launches open source AI agent security operations center" (independent coverage)
• OpenSourceDex, "AiSOC: Open Source AI Security & Privacy" (registry data: 6,344-star snapshot, ranked #8 of 48 in AI Security & Privacy)
• Cyble (funding company)

Related reading on AI Core Updates: Cognition's free Devin plugin patches PHP2Shell, Node.js, and GitLab, PHP2Shell: the critical PHP flaws and the patch every site needs, and Walmart lets AI agents shop for you, with spending limits built in.