One piece already exists: a ClickHouse-backed telemetry store holding historical firewall, DNS, and application events. Using AI to reason over that history for threat and DDoS pattern analysis is a direction we're exploring, not a built pipeline — the design is still open. This page describes where we might go, not a shipped feature.
It's worth being precise here: the data and the real-time detection are real, working code today. How an AI layer would read that data, and what it would actually do with it, is not decided — we don't want to describe a specific implementation as settled when it isn't.
Firewall (L3/L4), application-layer (Vaanvil), DNS (dnstap), traffic (Darkstat), and compliance (Elf-Owl) events are already durably ingested into ClickHouse via the Ramen pipeline — see ClickHouse Database.
18 detection rules across 5 categories, with fast pattern-counting techniques, already identify flood patterns and drive blocking right at the network card — see DDoS Threat Detection.
Which model, which provider, how it's invoked, and what output it produces are all open design questions right now — nothing here should be read as describing a specific implementation already committed to the codebase.
We think the direction — reasoning over historical data as a complement to real-time detection — is worth sharing even before the implementation is settled, as long as it's clearly labeled as exploratory.
The diagram below is a conceptual sketch of the direction, not an architecture diagram of something built — every stage past the first two is an open design question, not a committed implementation.
Rule-based heuristics are excellent at recognizing known flood signatures in real time — that's exactly what belongs at the packet path. What they're not built for is asking "has this source's behavior been trending toward an attack over the past two weeks?" or "does this traffic pattern resemble a campaign we saw against a different tenant last month?" Those are exactly the kind of long-horizon, pattern-across-history questions we think a future analysis layer reasoning over ClickHouse-aggregated event data could be well suited to answer — as a complement to real-time detection, not a replacement for it. How that layer is actually built is not yet decided.
Real-time blocking must stay fast and deterministic. Any future analysis over historical data would be a slower, higher-context layer that informs tuning and investigation — it would never sit on the packet-drop hot path.
Analyze months of ClickHouse traffic history to suggest DDoS rate-limit thresholds calibrated to a network's actual baseline, instead of one-size-fits-all defaults.
Compare attack signatures across gateways or tenants stored in the same ClickHouse instance to spot a coordinated campaign that looks unrelated at any single site.
Turn a raw burst of blocked-traffic events into a plain-language incident summary for a report or postmortem, grounded in the actual event data rather than a generic template.
Surface draft firewall rules based on observed attack patterns for a human to review and approve via the existing policy trace simulation workflow — never auto-applied without review.
Plenty of vendors market "AI-driven threat detection." Understanding what that usually means — and doesn't — is useful context before evaluating any roadmap claim, including ours.
| Common industry claim | What's often actually happening |
|---|---|
| "AI-powered anomaly detection" | Frequently a statistical threshold or simple ML classifier rebranded — genuinely useful, but not the same as a language model reasoning over historical context |
| "Machine learning threat scoring" | Often trained once on a vendor's aggregate dataset and never updated against your specific traffic — not adaptive to your actual environment |
| "Autonomous response" | Marketing language for pre-configured automated rules that were going to fire anyway — not a model making a judgment call |
| Vague roadmap language with no specifics | "AI is coming" without naming what data it reasons over, what it doesn't do, or what's already shipped — hard to evaluate, easy to oversell |
Our intent with this page is the opposite of that last row: name exactly what exists (ClickHouse history, rule-based heuristics, a working but disconnected LLM engine), exactly what doesn't (the link between them), and let you judge the gap for yourself.
This direction is being actively scoped and the implementation is expected to change as that scoping continues — we're deliberately not locking in specifics on this page. We'd rather tell you honestly that the design is still open than oversell a roadmap item as settled or shipped.