Product line · HYDRA Network detection & response

It learns what
normal looks like.
Then it says why.

A KAN-native network detection engine. The core heads are unsupervised — trained on benign traffic only, with no attack labels — and every alert traces back to the signal that produced it.

Book a 15-minute call HYDRA technical deep dive →
Current baseline · code-frozen
6 detection heads on the DNS layer — v17, code freeze 2026-01-30
3 · FourierKAN autoencoders (unsupervised)
1 · XGBoost classifier (eval-only)
2 · deterministic rule heads
FUSION · OR-gate with feature attribution
Repo verified · architecture
Delivery modelOn-premise, customer-controlled
PositionPassive tap, agentless
A research and engineering programme with a working DNS-layer baseline. No customer production deployment.
01
Why KAN

Architecture,
not post-hoc

Explainability is a property of the architecture.

A Kolmogorov–Arnold Network places learnable functions on the edges. You read the contribution directly — you are not approximating a black box after the fact with a second model.

Unsupervised at the core

The autoencoder heads learn the manifold of normal behaviour and flag deviation. No attack labels — because labelling cannot keep pace with activity nobody has seen yet.

Deterministic where it should be

Two heads are plain rules, not models. Punycode distance and RFC1918/Bogon checks do not need a network, and pretending otherwise would only add uncertainty.

Multi-head by design

Each head learns a different near-orthogonal projection of normal. Something that hides inside normal in one view separates in another.

02 · The detection heads Measured 2026-08-07 on real Zeek data

Six detection heads. Evidence attached to each one.

Three carry measured detection evidence; three are explicitly limited to deterministic or evaluation-only roles. In August 2026 we re-measured every contested performance number on real traffic, with re-runnable scripts — the table below is what survived.

H1 TunnelFourierKAN autoencoder Cross-source held-out benign false-positive rate: median 1.39%. On a synthetic DNS tunnel positive control the head did not fire at all. Not verified
H2 BeaconFourierKAN AE + autocorrelation Cross-source held-out benign FPR median 1.14% across 9 captures. On real malware captures, 52.8% of channels flagged on average — TrickBot 96.8% — at 0.94% benign FPR: a 56× lift over benign. Re-measured
H3 FluxFourierKAN autoencoder, TTL-based Cross-source held-out benign FPR median 1.50% across 13 captures. No detection rate is claimed: the malware captures hold too few domains each to make one meaningful. Partial
H4 DGAXGBoost, lexical features AUC 0.923 · TPR 54.6% at 1% FPR on 649k samples across 50 families. On an unseen family, TPR median 53.5%. Supervised — and therefore barred from the detection path by our own architecture decision. Evaluation only
H5 Punycoderule + edit distance Look-alike domain detection by deterministic string distance. No model, no training data, no drift. Deterministic
H6 Resolution checksrule, RFC1918 / Bogon Flags resolution answers pointing where they should not. Deterministic by construction. Deterministic
The gap we are not hiding

H1 is the head a DNS-tunnelling story would lean on, and right now we cannot show that it detects tunnelling. On a synthetic positive control it stayed silent. Until we have a real tunnel capture to measure against, we make no tunnel detection claim at all — and we would rather you read that here than discover it in a proof of concept.

03
How it sits

Agentless
Nothing leaves

On-premise, and nothing leaves the network.

A co-located appliance fed by a passive tap or by the flow and DNS logs you already produce. Nothing installed on endpoints. Inference runs on CPU.

PASSIVE INPUT SIX HEADS IN PARALLEL FUSION OUTPUT SPAN / tap or Zeek logs 3 × unsupervised KAN AE 2 × deterministic rule 1 × supervised — eval only OR-gate + FEATURE ATTRIBUTION alert with its reason NO ENDPOINT AGENT · NO CLOUD DEPENDENCY FOR DETECTION · NO TRAFFIC LEAVES THE NETWORK
Detection path — the eval-only head is drawn outside it deliberately
Single-event latency
1.75 ms one event, one thread
Batched throughput
>200k/s events per second on one CPU core, batched
Trained artifacts
~244 KB all KAN models together

Those first two numbers describe two different regimes and do not hold simultaneously — single-event latency on one thread is not the batched figure. We print them apart on purpose.

Measured benchmark · 2026-08-07
04 · Evidence Demonstrated is not validated

What has been demonstrated, and by whom.

Our own lab

The engine runs end to end in our lab stack against a Juniper-format syslog pipeline. That is an internal demonstration on our own data. It is not third-party validation, and we do not present it as one.

Internal demonstration
HPE / Juniper lab

An NDR test plan (v1.3) was submitted into the JSEL process on 29 May 2026. Execution is pending. No result exists yet, so none is quoted here — and the plan's target numbers are not achievements.

Submitted · execution pending
Where it is today

Six MITRE ATT&CK techniques at the DNS layer are in scope in the current baseline. The wider roadmap adds TLS metadata, flow analytics and graph-based lateral-movement heads in later phases.

Phase 1 · DNS layer
Research partnership

A research partnership with the University of Szeged is in progress, aimed at the label-free direction — because supervised labelling does not scale against activity that has not been seen before.

In progress

Fifteen minutes, against your own network.

Tell us what your DNS and flow telemetry looks like, and we will tell you where HYDRA would help today and where it would not.

Book a 15-minute call HYDRA technical deep dive →