Where ClickHouse and DDoS
Protection Meet AI.
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.
One solid foundation.
The AI layer is still an open question.
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.
Retrospective pattern analysis,
not just per-packet rules.
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.
ClickHouse event history + the 18-rule heuristics engine, both real and working now
(idea) look for trends across weeks, not just the current packet
(idea) notice a campaign that looks unrelated at any single gateway
(idea) suggested thresholds and rules — never auto-applied
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.
Ideas we're exploring —
not commitments or dates.
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.
Most "AI-powered" security
claims skip the hard part.
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.
What real-time rules miss
without a retrospective layer.
Exploratory, by design.
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.