Agentic SOC Platform: an agent-first case pipeline that sits in front of your SIEM

The problem ASP picks, and the teams it assumes

The README frames the problem in one line: security teams should move from alert fatigue to AI-assisted decision-making. The mechanism it offers is convergence. Modules stream SIEM and webhook alerts, extract IOCs, correlate related signals, and generate Cases, Alerts, and Artifacts, so what the README calls massive log volumes become a small number of actionable cases. That is a case-management claim, not a detection claim. ASP does not decide that a login is malicious. It decides that eleven alerts about the same host belong in one Case with one severity, one confidence, and one report. The intended user is a blue team that already owns a SIEM and already has alert rules it trusts, but lacks a place to put the resulting work. A one-person security team running a single cloud account will find the Case model heavier than the problem. A team with three analysts rotating through an inbox of raw Splunk alerts is the target. The topics list on the repository (soar, siem, blueteam) matches that reading. So does the README's own framing of the platform as something that orchestrates traditional SOAR workflows and AI analysis in the same Playbook system, which is an integration pitch rather than a replacement pitch.

Alerts in, Cases out: the data model that does the work

The architecture visible in the README is a pipeline with four named object types: Alerts, Cases, Artifacts, and IOCs. Alerts arrive from two directions. The first is SIEM streaming, with Splunk and ELK named as supported sources. The second is webhooks, which is how you attach alert sources that ASP has no built-in connector for. From there, Modules do the extraction and correlation work. The README describes Modules as the Python extension point for adapting new SIEM rules and alert sources, so the correlation logic is not fixed; it lives in code you can read and change. The output of that stage is a Case, and the Case is the unit everything else attaches to. Threat intelligence enrichment, CMDB enrichment, knowledge extraction and LLM investigation are all described as actions launched around a Case rather than as background daemons. That is a deliberate design choice with a cost: nothing gets enriched until a Case exists, so the quality of your alert-to-Case correlation determines how much context any downstream agent ever sees. If your correlation rules are wrong, the LLM is reasoning over the wrong bundle of evidence, and the structured report it produces will look confident and be useless. The README does not describe a feedback path from analyst verdicts back into correlation rules, so plan on tuning Modules by hand.

Playbooks, harness agents, and where the LLM actually sits

Two execution paths run against a Case. The first is Playbooks, which the README describes as orchestrating traditional SOAR workflows and AI analysis in the same system. The second is a set of one-click actions: LLM investigation, knowledge extraction, threat intelligence enrichment, and CMDB enrichment. The README's claim for the LLM path is that it compresses hours of manual analysis into seconds and produces severity, confidence, impact, priority, verdicts, and structured investigation reports. Treat that as a description of output shape, not a measured speedup. There is no benchmark in the material, and the real latency depends on the model you point it at and how much log context you feed it. The more interesting integration is the harness one. ASP exposes its capabilities to Claude Code, Codex, OpenCode and similar harness agents through a CLI and plugins, which means an agent running in your terminal can operate Cases, search logs, query threat intelligence, and write modules and playbooks directly. That is a real architectural commitment: the platform is designed to be driven by an external agent, not only by a human clicking buttons in a web UI. It also means the tool surface has to be stable enough for an agent to use reliably, and the README does not document how that CLI is versioned or what happens when a plugin call fails mid-investigation. The topics list mentions Dify, LangChain and LangGraph, but the README does not say which of these is load-bearing inside the shipped platform, so do not assume you can swap the orchestration framework without reading the source.

Getting it running: what the material actually specifies

The README links to a quick start at asp.viperrtp.com/asp/quick-start/deployment/ and does not inline the deployment commands. That is the honest state of the material, and it means the exact docker compose invocation, environment variables and port bindings are not verifiable from the repository description alone. What is specified: the backend is Python and the frontend is TypeScript, deployment is described as fully local, and login supports local accounts and LDAP. The configuration surface named in the README is Splunk and ELK for log sources, webhook ingestion for everything else, API Keys for programmatic access, and user roles for access control. Inbox notifications and an Audit Log are listed as built-in governance features. The extension points are Python Modules for new alert sources and Playbooks for orchestration. Two things to check before you commit: the license file, because the README says MIT while the repository metadata does not carry a license identifier, and the deployment guide's version requirements, because a Python backend plus a TypeScript frontend plus optional LLM and CMDB integrations is a multi-service stack and the guide is the only place the supported versions are stated.

The limitation that matters: ASP is not a detection engine

Read the pipeline again and the boundary is clear. ASP consumes alerts. It has no rule language, no log parsing pipeline of its own, no detection content library described in the README. If you do not already have Splunk or ELK producing alerts you trust, ASP has nothing to work on, and installing it will not improve your detection coverage by a single rule. The second limitation is correlation quality. Because enrichment and LLM investigation hang off Cases, and Cases are produced by Module correlation, a noisy correlation rule either fragments one incident into five Cases or merges five incidents into one. The README does not describe a deduplication or suppression mechanism, so that tuning is on you. The third is model dependency. Every AI feature in the README assumes you have an LLM available, and the private-deployment promise means you are hosting it. That is a GPU cost and an operational cost the README does not quantify. The fourth is maturity signal. The release history shows v0.5.0, v0.5.1 and v0.5.2 within roughly a month, which tells you the API and data model are still moving. If you need a stable schema for a multi-year deployment, that cadence is a warning, not a selling point.

Compared with n8n or Shuffle for the same job

The obvious alternative for a team that wants to wire alerts to enrichment and notifications is a general workflow engine such as n8n, or a SOAR-focused one such as Shuffle. The difference is the data model, not the connector list. In n8n or Shuffle you build a graph of nodes, and the incident exists only as the payload flowing through that graph; the run history is the record. In ASP the Case is a first-class object that persists, accumulates Artifacts and IOCs, carries severity, confidence, impact and priority, and can be reopened and re-investigated later. That is why knowledge extraction from closed Case records is even possible in ASP and awkward in a node graph. The trade is flexibility. A general workflow engine can automate anything you can write an HTTP call for, including tasks that have nothing to do with security operations. ASP's Modules and Playbooks are narrower by design, and the README positions them as the extension path rather than as a general automation surface. If your need is mostly notification routing and ticket creation, a workflow engine is less machinery. If your need is a durable investigation record that an LLM can read and a second analyst can audit six months later, the Case object is the reason to pick ASP.

Maintenance cost and the licence question

Three maintenance burdens are visible. First, Modules are Python code you own; when a SIEM changes its alert schema, you edit them. Second, Playbooks are the orchestration layer, and every change to an enrichment API or a CMDB field name is a Playbook edit. Third, the LLM path needs prompt and context maintenance, and the README does not describe a prompt versioning mechanism, so changes to investigation quality will not be traceable unless you build that yourself. The upgrade path is release-based, with three releases in the space of a month at the time of writing, so expect to read release notes before each bump. On licensing: the README states the project is MIT licensed, but the repository metadata supplied here lists the license as unknown. Those two statements conflict, and the licence file in the repository is the thing that governs. MIT would permit commercial internal use and modification; it would not, on its own, give you any warranty or support obligation from the author. Verify the actual file before you build a compliance case around it. This is a description of what the two sources say, not legal advice.

Editorial conclusion

Adopt ASP if you already run Splunk or ELK, your analysts drown in alerts, and you want one place where a Case holds the alert, the IOCs, the enrichment and the LLM report. Do not adopt it if you need a detection engine, if you cannot host an LLM inside your network, or if you want a vendor-held support contract. Before deploying, verify the license file in the repository, the Python and Node versions the deployment guide requires, and whether the Splunk and ELK connectors match your index layout.

Official sources

1. FunnyWolf/agentic-soc-platform on GitHub
2. Issues
3. Project website
4. README
5. Releases