All research systems
VigiloActive

Can a host watch itself closely enough that an LLM analyst catches the attack before the irreversible action?

Motivation

Crypto infrastructure — validators, signers, bridge nodes — has an unusual property: the damage is final the moment a key is used. Detection after the fact is not detection. Vigilo is an OS-level daemon that watches file access, process spawns, and network connections in real time, and pairs a one-second alert path with a slower LLM pass that correlates event sequences into attack patterns.

Hypothesis

Cheap host-level collection plus a slower correlating LLM pass will catch multi-step attack chains that per-event rules structurally cannot, with overhead low enough to run on a signer and an alert volume low enough that operators keep reading it.

Threat model

  • Key exfiltration: a private key or keystore is read by a process that has no business reading it, then leaves the host
  • Remote code execution: a shell spawned from an application runtime (node, python) as the first foothold
  • Supply-chain compromise: a package install initiated by a running application process rather than a deploy
  • Privilege escalation from an application process toward root
  • Coordinated campaigns: the same sequence appearing across several monitored hosts, invisible to any single host's rules
  • Out of scope: kernel-level rootkits that defeat /proc and inotify, and physical or hypervisor-level compromise

Architecture

  • Go daemon: fsnotify file watcher, /proc process poller, /proc/net connection poller, suppression rules
  • SQLite event buffer with a signal-dedup table, so repeated noise does not become repeated pages
  • Two-tier alerting: immediate push (Slack, Telegram, email, generic webhook) for high/critical events
  • MCP server on :7070 exposing five tools, so the analyst reads events as a first-class interface rather than scraping logs
  • TypeScript analyst agent: multi-daemon aggregation, context compaction, inspector-and-retry loop, running every five minutes

Detection model

  • Tier one — immediate: single events with an unambiguous signature (keystore read by an unfamiliar process, secret written to a world-readable path) page in about a second
  • Tier two — correlated: the analyst reads a five-minute window and looks for shapes, not strings — read-then-connect, spawn-then-install, repeat-across-hosts
  • Severity is assigned by irreversibility, not by rarity: anything touching signing material is critical regardless of frequency
  • Suppression is explicit and configured per host, so known-noisy legitimate processes do not train operators to ignore the channel
  • Dedup keys collapse repeated identical signals into one page with a count
  • The analyst never acts: its output is an explanation and a severity, and every conclusion cites the events it rests on

Implementation

  • Single Go binary per host, no agent framework; state is one SQLite file
  • Collection by polling /proc and /proc/net plus inotify on watched paths — deliberately portable ahead of an eBPF path
  • MCP server is the only read interface; the analyst has no log-scraping fallback, which keeps the event schema honest
  • Analyst runs off-host on a five-minute cadence, aggregating several daemons and compacting context before each pass
  • Alert transports are pluggable: Slack, Telegram, email, generic webhook

Evaluation methodology

The interesting comparison is not detection rate in isolation — it is whether the five-minute correlation window catches chains that per-event rules structurally cannot, without drowning the operator in the process.

Workloads
  • Private key and keystore reads
  • Env dump followed by an outbound connection (exfiltration chain)
  • Shell spawned from node/python (RCE)
  • Package install from an app process (supply chain)
  • The same pattern appearing across multiple monitored servers
Baselines
  • Host metrics and log tailing with alert-on-keyword rules
  • Per-event rules with the LLM analyst disabled
Metrics
  • Time from first hostile syscall to a human-readable alert
  • False-positive rate per monitored host per day
  • False-negative rate against the scripted chain suite
  • Fraction of multi-step chains caught by correlation but missed by single-event rules
  • CPU and memory overhead on the monitored host
  • Event throughput ceiling before the buffer backs up
  • Analyst verdict latency and token cost per pass

Experiments

V1 — Detection latency

Scripted attack chains replayed on an instrumented host with timestamps at each stage.

Measures Time from first hostile syscall to immediate page, and to correlated analyst verdict.

V2 — Correlation gain over single-event rules

The same chains run with the analyst disabled, leaving only per-event rules.

Measures Fraction of chains detected only by correlation, and stage at which each was caught.

V3 — False positives over time

Daemon left running on normal production workloads for a multi-week window with no injected attacks.

Measures False positives per host per day, before and after suppression tuning; alert volume trend.

V4 — Host overhead

Signer-shaped workload benchmarked with the daemon on and off.

Measures CPU and RSS overhead, event throughput ceiling, SQLite write amplification.

V5 — Analyst cost and stability

Repeated analyst passes over identical event windows.

Measures Verdict latency, token cost per pass, and verdict consistency across runs on the same input.

Results

Evaluation in progress

Failure cases

  • Polling misses short-lived processes that start and exit between /proc samples
  • A legitimate deploy that installs packages from an app process looks exactly like a supply-chain event
  • Under heavy event volume the analyst's context compaction drops the very events that made a chain legible
  • Suppression rules written during an incident are rarely removed afterwards, quietly widening blind spots

Limitations

  • Linux-only: collection depends on /proc and inotify semantics
  • Single-host SQLite buffer; cross-server correlation happens in the analyst, not the storage layer
  • The LLM analyst is a detection aid, not a control — it does not block anything
  • False-positive characterisation is anecdotal so far, not measured over a long window

Current status

Daemon and analyst both running. Immediate tier fires in roughly a second; the analyst correlates on a five-minute cadence. Detection catalogue covers key reads, secret writes, RCE-shaped spawns, exfiltration chains, privilege escalation, and cross-host repeats.

Roadmap

  • eBPF collection to replace polling where the kernel allows it
  • Signed event chains so the buffer itself is tamper-evident
  • Response hooks: quarantine and key-rotation triggers behind human approval

Future research

  • Where the boundary sits between detection and structural prevention on an irreversible action
  • How much host context an LLM analyst needs before correlation beats a hand-written rule
  • Suppression as a learned rather than configured behaviour