# Argus lists five headline capabilities and four modules > An agentic security operations platform with a Next.js frontend over a Django backend of eleven apps, an orchestrator, a workflow scheduler and an MCP tool registry. The page marks the primary datastore optional, names a scheduler only in the deployment section, lists three Kubernetes manifests for a four service platform, and exposes registration and one-time-password endpoints on a security console. **Sec-Link/Argus-Agentic-SOC-Platform** — An open source AI-native agentic SOC platform - Repository: https://github.com/Sec-Link/Argus-Agentic-SOC-Platform - Website: https://siem.seclink.info - Stars: 1,167 · Forks: 86 - Language: Python - License: Apache-2.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/sec-link-argus-agentic-soc-platform ## One of the five headline capabilities has no module The overview lists five things the platform provides. AI-powered investigation, security workflow automation, alert and incident management, threat intelligence enrichment, and asset context management. Four of those map cleanly onto something in the repository. Investigation maps to the assistant app, workflow automation maps to the workflows and orchestrator apps, alert and incident management maps to the alerts and tickets apps, and asset context management maps to the inventory app. The fifth does not. There is no threat intelligence app in the backend layout, no such entry in the list of product components, and no prefix for it under the versioned API. The component list has seven entries, alerts, tickets, the inventory, dashboards, correlation, workflows with the orchestrator, and the assistant, and none of them is threat intelligence. So one of the five claims on the first page of the readme has no named implementation anywhere in the repository description. Either enrichment happens inside the alerts app, in which case it is not broken, or it happens against a service the platform calls out to, in which case the page does not say which one. The architecture notes make the same point in a different way. They describe six layers, and the intelligence layer is described as the assistant offering conversation and tool calls, with no mention of an enrichment stage. For an evaluator, that is the line to ask about, because a security operations platform that enriches nothing is a ticketing system with a query language attached. ## The tech stack calls the primary datastore optional The architecture notes describe the data layer as PostgreSQL being the primary datastore, with Elasticsearch as an optional alert source. The tech stack section, further down the same page, lists both with the same annotation. PostgreSQL 16 is marked optional, and Elasticsearch is marked optional. So the datastore the architecture calls primary is marked optional in the component list. There is no third option listed, which means a reader taking the stack table literally would conclude that the platform runs with neither, or that the annotation is simply wrong. The rest of the stack is short enough to check for other mismatches. The frontend is a JavaScript application framework at version 15 with the React library at 18 and a component library at 5, using the App Router with its own route handler proxying API traffic. The backend is Django at version 6 with the REST framework and its token authentication. The token scheme is worth noting on its own. There is no session or cookie authentication and no OAuth mentioned for the API, only the REST framework's token authentication, which means one bearer token per client rather than an identity the backend can expire independently of the token store. Both optional markers also make a dependency survey awkward. The repository layout names a directory holding Kubernetes manifests and nothing about where Elasticsearch runs, and the deployment section covers compose files and manifests without mentioning a search service, so the optional search layer has no documented deployment path either. ## The workflow scheduler is named once and never declared The deployment section opens by saying that deployments register automatically from events emitted by a named scheduler, and that you select the execution deployment on each workflow. That scheduler appears nowhere else on the page. It is not in the tech stack, not in the six architecture notes, not in the repository layout, and not in the list of Docker Compose files. The orchestrator is described in the architecture as providing scheduled execution, orchestration and audit trails, as if the scheduling were its own responsibility rather than delegated. That delegation matters for an install. A workflow engine with its own database, its own worker process and its own deployment objects is not a library you can add to a compose file; it is a service you have to run, back up and upgrade. And the page says deployments register themselves from that engine's events, so the workflow objects in the database are not the source of truth for what will run. The second sentence of the same paragraph is a migration warning: existing installations have to follow a rollout procedure before upgrading, and that procedure is documented only at a link with a Chinese language suffix in its filename. The Windows story has the same shape. There is a Windows debugging guide at another Chinese-suffixed path, described as covering local editor debugging with two deployment and worker groups, and a Windows compose file exists at the repository root. The deployment section itself documents only the development and production compose files, so the Windows one is undocumented on this page. ## Three Kubernetes manifests for a four service platform The Kubernetes section is four lines long and calls its contents basic deployment manifests. There are three of them: one for the backend, one for the frontend and one for the database. What is not there is everything else a working install needs. No service objects, so nothing has a stable cluster address for the frontend proxy to reach. No ingress or route object, so nothing is exposed. No config maps or secret objects, and the hardening section explicitly asks you to set a secret key and host allow lists, which means those values have to be created by hand. No persistent volume claim for the database, so the deployment manifest's storage is whatever the cluster default gives. So the count is the point: three workloads for a platform that the page describes as having a frontend, an API layer, a primary datastore and a scheduler, and none of the four supporting objects. The word basic is doing real work in that sentence. The compose path is more complete, with a development file and a production file named in the deployment section, and a third file for Windows that the section does not mention. One more inconsistency in the same area. The repository layout diagram's last line is a bare entry called `docker-compose` with no extension and no comment, which does not correspond to any file in the repository, while the three real compose files are named with extensions. ## Registration and one-time passwords sit on the same prefix as everything else The API surface is one versioned prefix with eight areas under it, and the list is short enough to read as a whole. Auth covers login, logout, register and a one-time-password flow. Then alerts, tickets, the asset inventory, workflows, integrations for configuration and tests, the assistant and its tooling, and a model context protocol endpoint carrying the JSON-RPC connector and the tool registry. Two observations. First, self-registration and one-time passwords are available on a security operations platform, with no note anywhere on the page about disabling them, and the hardening section asks you to configure access boundaries for the assistant and protocol features without mentioning the registration route. A SOC console that anyone can create an account on is a different product from one you can hand to an analyst. Second, three of the seven product components have no listed API prefix. Dashboards, correlation and the orchestrator are components and are Django apps in the layout, but the prefix list jumps from the inventory to workflows, with no dashboards or correlation area. Either they are served under one of the listed prefixes or the list is incomplete, and either way a client author has to read the source. The frontend side is simpler and is stated once: the browser calls a route handler on the Next.js application, which proxies everything under the versioned prefix to the backend service, so there is one browser-facing entry point rather than direct calls. ## The hardening list asks you to back up storage the architecture never mentions The security section gives four recommendations for production, and they are short. Use a randomly generated application secret. Set the allowed host list and the trusted origins precisely rather than with a wildcard. Add backups and monitoring for the database, object storage and logs. And configure access boundaries, auditing and least privilege for the assistant and protocol features. Object storage is the one to stop on. It appears in that recommendation and nowhere else on the page. The architecture names PostgreSQL and Elasticsearch in the data layer, and storage does not appear in the tech stack, the repository layout, the compose list or the Kubernetes manifests. Either there is an object store that the page never introduces, which is the component most likely to hold uploaded artefacts, or the recommendation is boilerplate carried over from another deployment guide. The other three are the standard four and each is concrete: a generated secret rather than a committed one, two host lists set exactly, backups plus monitoring across three stores, and least privilege on the two features that can act on your behalf. What is absent is worth naming too. There is no recommendation about the authentication scheme, none about rate limiting on the register and one-time-password routes, none about where the assistant's model calls go, and none about which AI provider it uses or what data is sent to it. For a platform whose assistant can query tickets and pull observables, that last one is the gap. ## The release tags jump from 0.72 to 0.8 with no changelog The three most recent releases are a bare 0.8 from 2026-10-01, then 0.72 from 2026-07-08 and 0.71 from 2026-07-05. Read as semver those are 0.8.0, 0.7.2 and 0.7.1, so the ordering is fine. Read as written they are 0.8 and 0.72, and the patch component of the older two is written without a separator. The newest tag also carries no release name while the two older ones do, so the tag that jumped the most is the one with the least attached to it. The gap between the July releases and the October one is three months, during which the default branch was pushed on 2026-10-02, the day after that release. There is no changelog file at the repository root. The top-level listing has a licence, a code of conduct, an agent instruction file, the two readmes, the three compose files, the environment example, a makefile and a scripts directory, and no changelog and no release documentation. So the only record of what changed in the version that skipped two minors is the repository history and whatever was written into the commit messages. The rest of the root is consistent with a Django and Next.js project of this size: a documentation directory holding the architecture page, the API overview and the two rollout guides, a Kubernetes directory, and a backend directory of eleven apps plus the project settings module. ## Conclusion Argus covers the seven objects a SOC actually works with, which is the right starting point: alerts, tickets, an asset inventory, dashboards, correlation, workflows and an assistant. The detection story is the part with real depth behind the claims, with out-of-the-box use cases, detection as code, rule versioning and Sigma rules for portable detection content. The assistant is wired as tools rather than as a chat box bolted on, with ticket-context queries, similar-case retrieval, asset queries and observable extraction behind a tool registry, which is the shape that makes an assistant auditable. Four things to check before you point an incident at it. The overview promises threat intelligence enrichment and there is no module, app or API prefix for it anywhere in the repository layout, so find out what feeds it before you rely on that line. The tech stack marks PostgreSQL, which the architecture calls the primary datastore, as optional, which is the kind of labelling mistake that makes a dependency survey unreliable. The Kubernetes directory lists three deployment manifests and nothing else, so it is not a working install on its own. And the hardening section tells you to back up object storage, which appears nowhere in the architecture. On the security posture, the four recommendations are sensible but the list of exposed endpoints is not obviously aligned with them: public registration and a one-time-password flow sit under the same prefix as everything else, and token authentication is the only scheme named. Set the allowed hosts and trusted origins precisely, and treat the registration route as something to disable unless you have a reason for it. ## FAQ ### What is the Argus Agentic SOC Platform? An open source AI-native security operations platform. It consolidates seven SOC capabilities into one product: alerts, tickets, an asset inventory, dashboards, correlation rules, workflows with an orchestrator, and an AI assistant with a model context protocol tool registry. ### What does Argus use for its database and search? PostgreSQL 16 as the primary datastore and Elasticsearch as an optional alert source. The tech stack section marks both as optional, including the one the architecture notes call primary. ### What schedules Argus workflows? A named workflow engine that emits events from which deployments register automatically, with an execution deployment selected per workflow. The engine is not listed in the tech stack, the architecture notes, the repository layout or the compose files. ### How do I deploy Argus with Kubernetes? The k8s directory contains three deployment manifests, for the backend, the frontend and the database, described as basic. No service, ingress, config map, secret or volume claim manifests are listed, so the directory is not a complete install on its own. ### What authentication does the Argus API use? The REST framework's token authentication. The auth prefix also exposes login, logout, register and a one-time-password flow, and the page does not describe how to disable public registration. ### What detection formats does Argus support? Sigma rules, described as write-once run-anywhere detection, alongside detection-as-code with rule versioning and out-of-the-box use cases for detection and correlation rules. ## Sources - [License: Apache-2.0](https://github.com/Sec-Link/Argus-Agentic-SOC-Platform/blob/main/LICENSE) - [Project website](https://siem.seclink.info) - [README](https://github.com/Sec-Link/Argus-Agentic-SOC-Platform/blob/main/README.md) - [Releases](https://github.com/Sec-Link/Argus-Agentic-SOC-Platform/releases) - [Sec-Link/Argus-Agentic-SOC-Platform on GitHub](https://github.com/Sec-Link/Argus-Agentic-SOC-Platform) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sec-link-argus-agentic-soc-platform