Technology | RX-OS Cognitive Security Platform

Pillar 01 — Drive

The perceptual engine

Drive is the sensory system of RX-OS. It captures raw network traffic at wire speed using eBPF/XDP hooks in the Linux kernel, then parses the data through protocol-specific decoders to produce structured observations.

eBPF/XDP zero-copy packet capture in kernel space
30+ industrial protocol parsers (Modbus, S7comm, BACnet, OPC UA, EtherNet/IP, MQTT, and more)
Passive only. No active scanning. No packets injected onto the wire.
Processes gigabit traffic on a compact edge appliance

Pillar 02 — Router

The nervous system

Router is the internal event bus that distributes observations across all subsystems in real time. It ensures every pillar has the context it needs, with guaranteed delivery and ordering.

Internal publish-subscribe event bus with guaranteed ordering
Sub-millisecond message delivery between subsystems
Backpressure handling to prevent observation loss under load
Topic-based routing so each pillar receives only relevant events

Pillar 03 — Causal

The reasoning engine

Causal builds directed acyclic graphs linking devices, behaviors, and anomalies. It does not just flag deviations — it traces the chain of events to explain what happened and why it matters.

Builds causal graphs connecting observations to root causes
Distinguishes between correlation and causation in anomaly chains
Provides human-readable explanations for every alert
Continuously refines understanding as new evidence arrives

Pillar 04 — Memory

Institutional knowledge

Memory is the hash-chained evidence store. Every observation is recorded as a SHA-256 linked block, creating a tamper-evident chain. If any record is modified, all subsequent hashes break.

SHA-256 hash-chained evidence blocks — tamper-evident by design
Cryptographic proof that records were not modified post-hoc
Enables NIS2 Article 21(2)(j) audit trail compliance
Management liability defense: prove your security posture at any point in time

Pillar 05 — Council

The decision authority

Council is a multi-agent consensus system. When anomalies are detected, multiple specialized AI agents independently analyze the evidence and debate before escalating. No single model owns the verdict.

Multiple AI agents analyze each anomaly independently
Consensus-based verdict reduces false positives dramatically
Each agent specializes: protocol behavior, device identity, network topology, temporal patterns
Full reasoning trace available for every escalated alert

Pillar 06 — Sense

The awareness layer

Sense maintains a continuously updated mental model of the entire OT environment. Device identities, communication relationships, behavioral baselines, and risk posture — all in one living representation.

Live topology map of all discovered OT/IT devices
Device identity tracking across IP changes and reboots
Behavioral baselines per device: timing, protocols, data volumes, communication partners
Continuous risk scoring based on exposure, firmware age, and anomaly history

Kernel

eBPF/XDP: zero-copy capture

Traffic capture happens directly in the Linux kernel, before the networking stack allocates socket buffers. Zero copies, zero overhead, zero risk of packet loss.

Why eBPF?

Traditional packet capture (libpcap, DPDK) operates in userspace, requiring expensive copies for every packet. eBPF/XDP runs directly in the kernel, processing packets at the earliest possible point in the networking pipeline. This enables gigabit throughput on modest hardware with zero packet loss.

// Simplified XDP program structure
SEC("xdp")
int rxos_xdp_prog(struct xdp_md *ctx) {
  // Parse packet headers in kernel
  struct ethhdr *eth = parse_eth(ctx);
  struct iphdr *ip = parse_ip(ctx);

  // Extract OT protocol metadata
  extract_ot_metadata(ctx, &meta);

  // Push to ringbuf for userspace
  bpf_ringbuf_submit(&meta, 0);
  return XDP_PASS;
}

Six pillars.One cognitive system.

Why eBPF?

Six pillars.
One cognitive system.