- Docs
- Architecture & operations
- System architecture
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
| Service | Stack | Responsibility |
|---|---|---|
| Dashboard | React + Vite | Operator UI — incidents, cases, AgentSOAR, reporting, settings. |
| Platform API | Hono | Application API behind the dashboard — orgs, users, incidents, cases, credentials, auth. |
| Ingest API | Hono | Accepts 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.
| Worker | Stage | Responsibility |
|---|---|---|
| Normalizer | 1 | Reshapes raw records into the common event schema and writes them to OpenSearch. |
| Triage | 2 | Scores detections and decides what is worth pursuing. |
| Enrichment | 3 | Adds asset, identity, and threat-intelligence context. |
| Incident correlation | 4 | Groups related alerts into incidents (attack chains, shared alerts, same campaign). |
| Response | 5 | Decides on an action and dispatches it to AgentSOAR. |
| Incident report | 6 | Generates the human-readable summary of an incident and its response. |
Background services
These run on their own schedules rather than on the event queue.
| Service | Responsibility |
|---|---|
| Reporting | Builds scheduled organization reports (daily, weekly, monthly, yearly). |
| Data archiver | Ages out and archives old event data. |
| Google Workspace email-logs poller | Pulls Workspace email logs into the ingest path. |
| Backup / restore | Operational backup and restore tooling. |
Data flow
A single event travels a linear path. Every stage is scoped to one organization, so no record crosses tenant boundaries.
- Sources — Wazuh, Google Workspace logs, syslog forwarders, or custom webhooks emit raw events.
- Ingest API validates each event and publishes it to the queue.
- Normalizer maps the raw record into the common schema and writes it to OpenSearch.
- OpenSearch stores the normalized event in the per-organization weekly index.
- Triage scores the detection and decides whether it advances.
- Enrichment attaches asset, identity, and threat-intelligence context.
- Incident correlation groups related alerts into an incident.
- Response chooses an action and dispatches it.
- AgentSOAR runs the response playbook against your connected providers.
- 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 reportHow 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.