System architecture

Jutsu is a set of small, single-purpose services connected by a message queue and a shared data plane. Raw security events enter through an ingest API, move stage by stage through AI agent workers, and leave as correlated incidents with automated responses and reports. This page maps every service and traces one event from arrival to closed incident.

Services

Jutsu separates user-facing APIs, the event-processing pipeline, and scheduled background jobs. Each runs as an independent deployable.

Edge and APIs

ServiceStackResponsibility
DashboardReact + ViteOperator UI — incidents, cases, AgentSOAR, reporting, settings.
Platform APIHonoApplication API behind the dashboard — orgs, users, incidents, cases, credentials, auth.
Ingest APIHonoAccepts raw events from SIEM forwarders and webhooks; validates and queues them.

Agent workers

Each agent is a queue consumer that reads one input, performs one job, and hands off to the next stage. The workers form the processing pipeline.

WorkerStageResponsibility
Normalizer1Reshapes raw records into the common event schema and writes them to OpenSearch.
Triage2Scores detections and decides what is worth pursuing.
Enrichment3Adds asset, identity, and threat-intelligence context.
Incident correlation4Groups related alerts into incidents (attack chains, shared alerts, same campaign).
Response5Decides on an action and dispatches it to AgentSOAR.
Incident report6Generates the human-readable summary of an incident and its response.

Background services

These run on their own schedules rather than on the event queue.

ServiceResponsibility
ReportingBuilds scheduled organization reports (daily, weekly, monthly, yearly).
Data archiverAges out and archives old event data.
Google Workspace email-logs pollerPulls Workspace email logs into the ingest path.
Backup / restoreOperational backup and restore tooling.
The exact set of agents and the order of triage and enrichment can evolve between releases. Confirm against your deployment.

Data flow

A single event travels a linear path. Every stage is scoped to one organization, so no record crosses tenant boundaries.

  1. Sources — Wazuh, Google Workspace logs, syslog forwarders, or custom webhooks emit raw events.
  2. Ingest API validates each event and publishes it to the queue.
  3. Normalizer maps the raw record into the common schema and writes it to OpenSearch.
  4. OpenSearch stores the normalized event in the per-organization weekly index.
  5. Triage scores the detection and decides whether it advances.
  6. Enrichment attaches asset, identity, and threat-intelligence context.
  7. Incident correlation groups related alerts into an incident.
  8. Response chooses an action and dispatches it.
  9. AgentSOAR runs the response playbook against your connected providers.
  10. Incident report summarizes what happened and what was done.
Sources (Wazuh / Workspace / syslog / custom)
        |
        v
   Ingest API ──▶ Normalizer ──▶ OpenSearch (per-org weekly index)


        Triage ──▶ Enrichment ──▶ Incident correlation


              Response ──▶ AgentSOAR ──▶ Incident report

How the workers connect

RabbitMQ is the backbone between workers. Each stage consumes from its input queue and publishes to the next stage's queue, so the pipeline is decoupled and asynchronous — a slow or busy stage queues work rather than blocking the one before it. This also makes scaling per-stage possible: a worker that falls behind grows its queue, and more replicas drain it.

OpenSearch holds the normalized events and alert documents that the triage, enrichment, and correlation stages read and update. PostgreSQL holds the transactional records — organizations, users, incidents, cases, and audit trails — that the platform API serves to the dashboard.