Detection where your data lives.
Detections don't break because rules are written too slowly. They break because the data underneath them is fragmented, dynamic, and fragile. AxoDetect starts at the first mile.
The industry is automating the wrong mile.
Rule generation is the last mile of the detection pipeline. Stabilizing the data those rules run on is the first. Almost all of the investment is going to the wrong one.
Faster rule generation doesn't close the gap.
Teams are producing more detection content than ever and still falling behind. When output goes up and coverage doesn't, the bottleneck is somewhere other than authoring — and pointing automation at the last mile only produces more rules that rest on the same unstable ground.
The data layer is fragmented, dynamic, and fragile.
Telemetry arrives from dozens of sources in dozens of shapes, spread across SIEMs, lakes, and cloud storage. Formats change under you when a vendor ships an update. A field silently renames, and a rule that passed review last quarter now matches nothing.
Engineers can't see the data, so the feedback loop never closes.
Writing a good rule requires looking at real telemetry, and that access is gated by another team. Rules get written blind, and nothing flows back from what the detection did in production to the person who wrote it. Breakage is discovered during an incident.
AxoDetect is integrated into the data layer so detection happens in stream and the data engineer, detection engineering feedback loop is closed.
Four beliefs about the first mile
Detection goes to the data, not the other way around.
The detection layer meets data where it already lives, SIEM, lake, or cloud storage, so detection happens immediately and onboarding a new source is a decision about signal rather than about budget.
Rules should be written against stable ground.
AxoFlow relies on Sigma rules and community detection rather than proprietary ones. Normalize first, then author against the normalized shape in an open, readable format—so a parser update becomes a pipeline event instead of a silent coverage loss.
Fragile means untested. Testing is the fix.
Both sides move: attacker behavior and the telemetry describing it. A rule is a hypothesis about both, so it should be testable against real sample data and versioned like code — making a change routine rather than something nobody wants to touch.
Coverage is a data question before it's a rule question.
A technique is only covered if a rule exists and the data feeding it is arriving in the shape that rule expects. Coverage should be measured against both, so a broken source shows up as a gap on the matrix rather than as silence.
An early look at what we're building toward
Stabilize the first mile, then write once
Normalize telemetry as it arrives, then author against that shape and target the environments you already run.
- In-stream Sigma rule detection
- Rule testing
- Findings forwarded to SIEM or AI SOC
- MITRE ATT&CK mapping and coverage matrix
See coverage, including where the data broke
Coverage is measured against attacker techniques and against source health, so drift surfaces as a gap.
- PAN-OS Threat / URL
- Windows Security 4104
- Auth brute force · corp-vpn
- Cobalt Strike beacon
The questions a skeptic asks first
What do you mean by first mile and last mile?
The last mile is rule generation — writing and tuning detection content. The first mile is everything the rule depends on: collecting telemetry, normalizing it, and keeping it stable as sources change. Most automation spend goes to the last mile. Our argument is that the first mile is where detections actually break.
Is AxoDetect available today?
Not generally. It is pre-GA and in active design with partners. Nothing on this page is a claim about a shipped feature set — where we describe capability, we describe what we are building toward.
Isn't this just a data pipeline product?
The pipeline is the foundation, not the point. What it buys you is detection logic written against a shape that does not move, and coverage numbers that account for whether the underlying source is still healthy. Pipeline without detection leaves the same gap in a different place.
Who is this for right now?
Teams with detection engineering already in place, running more than one data environment, who have watched a rule quietly stop matching after a source changed. If you are standing up a first SIEM, we are probably early for you.
What happens if the roadmap changes?
It will. Partners hear about it from us first, and the four pillars on this page are the part we intend to be held to — the specifics underneath them are what the program is for.