AiSOC: An MIT-Licensed AI Security Operations Center You Can Self-Host

AiSOC, a new open-source project at beenuar/AiSOC, packages a security operations center (SOC) into something you can run with make up: detection rules, alert correlation, LLM-agent triage, a console and an MCP server for Claude, Cursor and Continue. It is MIT licensed, self-hostable and, by default, runs a small local model so no alert data leaves your machine. GitHub showed it trending with about 436 new stars in a day and roughly 5.9k in total. This guide covers what is in it, how to start it, and where the README itself says to be careful.

TL;DR

Agents that act on your behalf need rules. See how explainx helps secure your agents →

What does AiSOC actually do?

A SOC takes a flood of logs, decides which events matter, groups them into incidents, and has analysts investigate. AiSOC's README describes each stage.

Detection. It reports 2,530 executable rules out of a 7,015-rule library, plus 76 sliding-window rules, with tenant-specific tuning on top.

Correlation and investigation. Related alerts are grouped into incidents. AI agents then triage and investigate using typed tools rather than raw SQL, which limits what a misbehaving agent can query.

Audit. An Investigation Ledger records prompts, tool calls, citations, verdicts and token costs, and investigations can be exported as signed evidence bundles in OCSF 1.9.0 format. This "replayable decision ledger" is the feature that most separates it from a chatbot bolted onto a log viewer: you can see why the agent called something benign.

Threat intelligence. It polls the public CISA Known Exploited Vulnerabilities catalog with no API key, and re-sweeps historical telemetry when new intel arrives (retro-hunts).

Connectors and migration. There are 87 click-and-connect connectors plus collectors for CloudTrail, GCP Pub/Sub, Azure Event Hubs and syslog/CEF. A package named aisoc-migrate translates Splunk SPL, Sentinel KQL and Elastic EQL, and the README says it refuses to translate rules it cannot carry faithfully; of 2,005 bundled Splunk rules, 1,734 translate, though the page notes 1,711 of those are partial translations.

Response. Playbooks preview by default, approval steps survive restarts, and vendor actions require human approval unless a tenant explicitly grants autonomy.

How is it built?

The pipeline runs ingest, normalize, Kafka, detection, correlation, alert, AI triage, console. Postgres is the core store; the full profile adds ClickHouse as an event lake and Neo4j as an entity graph. A local model gateway based on Ollama handles inference. The repo is a pnpm and Turbo monorepo with apps, services, packages, detections, playbooks and infra directories.

How do I try it?

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

According to the README, make up starts the core profile (about 16 services, roughly 8 GB RAM), make smoke verifies it, make doctor diagnoses problems and make demo loads labelled synthetic data. make up-full adds the heavier services. If you do not want Docker, pip install aisoc-sandbox && aisoc-sandbox demo runs an offline demo, and there is a GitHub Codespaces option. The first run downloads a model of roughly 2 GB.

The README also offers one-line install scripts for Windows and Linux/macOS. As with any curl | bash, read the script before running it, particularly on a machine that will hold security telemetry. A demo in a throwaway VM or Codespace is the safer first step.

What are the honest limits?

The project is unusually direct about these, and they matter more than the feature list.

1. The default model is small. The README calls it "not a frontier model". It reports usable triage output on 44 of 50 alerts before JSON-constrained replies and 50 of 50 after. That measures format reliability on a test set, not investigative accuracy.
2. No hosted provider has been tested. The maintainers say they had no funded key, so bring-your-own-provider setups are supported but unverified by them.
3. Benchmarks are self-consistency. The README says its numbers measure substrate self-consistency, not live agent accuracy.
4. Not a SIEM replacement. No long-term retention or compliance search, and it cannot see telemetry you have not connected.
5. Two rules cannot fire yet and are waiting on a behavioral baseline.
6. Distribution is beta. PyPI packages install, but npm packages still need a first upload. There were 3 open issues and 14 open pull requests when we read it.

How does it compare to other AI-for-security work?

AI triage is a crowded idea. Cognition's Devin handles on-call alerts in the engineering world, which we covered in Devin on-call and auto-triage: what is claimed. A fine-tuned small model beat a frontier model on alarm triage in Exowatt's edge-alarm case, and the open Security One 27B decision model targets prompt-injection triage. AiSOC takes a different bet: rather than one specialised model, it ships the whole pipeline around a replaceable one and focuses on auditability.

On the MCP side, an agent that can query a SOC is also an agent with sensitive access. Our post on a reverse-engineering MCP server and agent security and the top open and closed MCP servers are useful context before you connect an assistant to production telemetry.

What does a sensible evaluation look like?

A trending repo is a starting point, not a verdict. A practical one-week plan for a security team:

1. Day one: demo only. Run make up, make smoke and make demo in a disposable VM. Open the console and follow one synthetic incident from raw event to alert to AI verdict. The aim is to understand the shape of the data, not to judge accuracy.
2. Day two: read the ledger. Pick five investigations and read each prompt, tool call and citation in the Investigation Ledger. Check whether the cited evidence actually supports the verdict. A confident wrong answer with real-looking citations is the failure mode to look for.
3. Day three: feed it your own logs. Connect one low-risk source, such as a test cloud account's audit trail, through one of the 87 connectors or the CloudTrail collector. Note which fields are parsed and which are dropped.
4. Day four: test migration. Run aisoc-migrate on a sample of your Splunk, Sentinel or Elastic detections. The README says it refuses rules it cannot translate faithfully, so the refusal list tells you how much manual work remains.
5. Day five: attack the agent. Put a harmless instruction string into a log field, such as a user agent, and see whether the triage output changes. This is a cheap prompt-injection check, and the answer should shape how much autonomy you ever grant.
6. Day six and seven: compare with humans. Have an analyst triage the same alerts blind and compare. Measure agreement, time saved and the cases the model missed.

Treat the 50 of 50 figure in the README as what it is: a statement about formatted output on a test set. Your own comparison is the only number that tells you about your environment.

What are people likely to ask?

Is this a Claude product? No. It is an independent project that exposes an MCP server so assistants such as Claude, Cursor and Continue can query it. The default model is a small local Llama variant.

Why a 3B model by default? So it runs on a CPU with no key or GPU, which makes the first demo easy. The README is candid that it is not a frontier model, and the design assumes you may swap it out.

What is the catch with MIT and corporate backing? The README says Cyble supports development and that nothing is gated or telemetry-laden. That is a claim about the repository; verify it by reading the code and network calls in your own lab before trusting it with sensitive logs.

Does 5.9k stars mean it is production ready? No. Stars measure interest. The version badge reads 21.0.0, yet the releases page was empty and package distribution is marked beta, so inspect the changelog and test coverage yourself.

Should you deploy it?

For a lab, a homelab, a university course or a small team that wants to learn how detection, correlation and agent triage fit together, yes: it is a complete, inspectable system with a demo dataset. For a production SOC, treat it as a reference architecture and evaluation target. Run it beside your existing tooling, compare its verdicts to your analysts', and read the Investigation Ledger entries for the cases it gets wrong.

Before connecting real data, think about the agents themselves. An LLM that reads attacker-controlled log fields can be steered by them. Typed tools and human approval, both in AiSOC's design, reduce that risk, but they do not remove it. If you run AI agents that can take actions, tools such as AgentBeam, the agent security platform from the explainx.ai team, exist to stop agents before they take dangerous actions.

Questions to ask before adopting

• Who maintains it? The README names Cyble as supporting development; read the repo's security policy and changelog and decide whether that fits your vendor rules.
• Where does data go? By default nowhere outside your host. If you add a hosted model, alert content including usernames and IPs goes to that provider.
• What happens when the model is wrong? Check the ledger, the approval gates, and whether you can disable autonomy tenant-wide.
• Can you keep your rules? Test the migration package on a sample of your own detections and see which ones it refuses.
• What are the costs of running it? Eight to twelve gigabytes of RAM for the stack, plus storage for telemetry, is modest for a lab and non-trivial for a busy environment.

Related reading

• Devin on-call and auto-triage: what is claimed
• Exowatt fine-tuned Qwen3 for alarm triage
• Security One 27B open decision model
• Reverse-engineering MCP server and agent security
• Top 10 open and closed-source MCP servers
• Self-hosted open-source MCP newsletter tool

Repository details, star counts and feature numbers come from the README and GitHub page as of November 1, 2026 and may change.