Docs / Architecture

Architecture

How a shell command becomes a finding in your SIEM.

Pipeline

Four stages, wired as a stream — a window doesn't wait on the next stage's queue to back up before earlier stages keep moving:

collector → windowing → detection → explainability → verdict

• Collector — captures execve events. On Kubernetes, this is eBPF via Tetragon: kernel-level process execution capture with nothing to instrument inside the build image. Off-Kubernetes or from a custom source, anything that can POST the documented event shape works — see Integrations.
• Windowing — groups a pod's command sequence into bounded windows for scoring, rather than judging one command at a time in isolation. Attack chains are sequences, not single commands.
• Detection — a model trained specifically on real execve command sequences scores each window. Every promotion is evaluated against a held-out benchmark before it can replace the current model in production — see Security for the promotion gate.
• Explainability — for a flagged window, identifies hit1_command (the single highest-attribution command, always computed) and, on entitled plans, the most likely full attack chain.

Two deployment topologies, same pipeline

On-prem: the full pipeline runs inside your own cluster, one instance per node, reading your own local event stream. Nothing about your build sessions leaves your network.

Cloud (free and paid tiers): a shared, multi-tenant deployment of the same pipeline. Your own collector (or any client speaking the documented ingest shape) authenticates with a per-account signed token and streams events to it; findings come back to your dashboard live over a streaming connection, and are not persisted server-side on either cloud tier — see Security.

What ships in a model bundle

A pulled bundle (see Getting started) contains the detection model and its supporting files, packaged and Ed25519-signed as one signed manifest, so your deployment can verify authenticity offline before loading anything.