AiSOC needs connected telemetry before it can investigate
AiSOC's workspace built successfully in the supplied sandbox run, but the test command failed. Neither result establishes whether a real security event reaches an investigation with its evidence intact. That is the next question for a security team considering adoption.
The README describes an open-source, self-hostable system that ingests security telemetry, detects and correlates threats, and investigates them with AI agents. It says every prompt and tool call is recorded. These are project claims, separate from the repository commands exercised in the sandbox.
AiSOC is worth evaluating for teams that can connect known telemetry sources and supervise investigations. Keep an existing retention system: the README explicitly excludes replacing long-term log retention and compliance search. It also says there is no discovery of telemetry you have not connected.
What happened when we ran it
The October 28, 2026 sandbox run installed AiSOC's pnpm workspace at commit 7540638 in 33 seconds. It recorded 2,002 dependencies and 1,389 MB on disk. The build succeeded in 72 seconds. Tests exited 1 after 15 seconds.
The parser reported 19 passed and zero failed out of 19. The supplied log tail also contains other package-level passing summaries, followed by the web package reporting no tests and 100 errors before an ELIFECYCLE failure. Nineteen is therefore not an established total for the workspace. Passing assertions do not make the overall command successful.
The excerpt does not show the exceptions behind the web errors. It cannot establish whether an environment setting, package problem or application defect caused them. The complete log would be needed to investigate that failure.
The repository scan found 93 CI workflow files, a Compose file and no Dockerfile. Those observations establish file presence, not successful CI coverage. GitHub identifies Python as the primary language, while the measured run used the Node ecosystem. The build does not verify the Python services or the complete event pipeline.
The sandbox configuration listed 3 CPUs, 8 GB RAM and image lab-node:22. Actual runtime and operating-system versions remain unverified without raw toolchain logs. This run did not measure detection quality, agent accuracy or response safety.
Verify the deployed event path
The README specifies Docker Compose v2, Python 3.9+ and bash, with 8 GB memory and 20 GB free disk inside the Docker VM. It describes a deployment that downloads a local model and generates secrets. That deployment was not reproduced by the measured workspace commands.
The README says make smoke posts an event to the ingest API, follows it through Kafka, detection, correlation and Postgres, then reads the alert through the public API. That documented check is a useful next step after deployment. It was not executed in this run, and the README's example output is not a sandbox result.
For an evaluation, choose one telemetry source whose events you understand. Compare the original event with the resulting alert, including its host, user and source attribution. Then inspect the investigation record and verify how an approved response and a refused response behave. These are proposed acceptance checks, not completed tests.
Imported Splunk rules can lose thresholds
The migration guide says partial translations can preserve field matches while losing aggregation thresholds. A translated rule can therefore change what behavior triggers an alert.
The guide tells operators to treat partial output as a draft, read the unsupported list and check whether the engine can express the missing threshold or window. It calls for positive and negative fixtures, followed by approval from another person. Include that review in the migration work before relying on imported detections.
The translator also refuses constructs it cannot carry across. An emitted rule should not be treated as an equivalent replacement merely because translation produced output.
Read the repository audit as a dated record
The repository reality audit is dated September 23, 2026 against v8.1.0. It records that an earlier quickstart displayed fabricated incidents without exercising the full pipeline. That historical finding does not establish that the current default behaves the same way.
The document includes later corrections, and the supplied README describes a revised deployment. Together, they give an evaluator a concrete question: does an event traverse the actual services, and does the console distinguish real, sample and synthetic data?
The supplied GitHub metadata records a push on October 29, 2026. The supplied latest-release record identifies v20.2.1, published October 28, 2026. These observations do not establish production reliability. The sandbox results belong to commit 7540638; the evidence does not establish that it is the v20.2.1 release commit.
Choose alternatives by the immediate job
Wazuh documents an endpoint security agent and a management server that collects and analyzes the agents' data. Evaluate it when endpoint telemetry collection is the immediate requirement. No comparative performance or detection test was supplied.
Shuffle describes itself as an open source automation platform built for security professionals. Evaluate it when security workflow automation is the immediate requirement. Its inclusion here does not imply a measured reliability advantage over AiSOC.
For AiSOC, the next useful result is a verified event path on your deployment, followed by inspection of the investigation evidence and response controls. The successful workspace build leaves those adoption questions unanswered.