Let’s be brutally honest for a second. Most of what our industry lovingly calls “Detection Engineering” is just taking a MITRE ATT&CK tag (like T1110), stapling it to a fragile KQL query, and praying the SOC analysts don’t unionize over the false positive rate. We see a bad event, we flag it. But what happens when the event itself is perfectly legitimate, and it’s the pattern that is absolutely cursed? Welcome to Volumetric Detection Engineering (VolumetricDE).
The core doctrine here is painfully simple: the event may be valid, but the pattern may not be. We aren’t talking about raw volume counts. We are tracking behavior shape over time and breadth—cardinality, acceleration, fan-out, and sequence compression. If your detection philosophy for brute force is still “alert when AuthFailure > 50,” you aren’t doing engineering. You are doing mathematical cosplay with a save button.
The Machine-Speed Reality Check
We need to talk about AI agent attacks. AI agents don’t move like human operators who need to drink copious amounts of caffeine and Google API syntax. They exploit credentials, execute API calls, and operate across multiple services in parallel at literal machine speed.
This is exactly where VolumetricDE earns its paycheck, specifically through our Sequence Compression analytic (VOLDE-SEQCOMP-MACHINESPEED-001). Imagine an ordered chain: Reconnaissance → Credential Access → API Use. The signal isn’t the volume of events; it’s the implausibly low inter-step gaps. If a threat actor executes a full attack chain in under 5 minutes with microsecond gaps between stages, it’s not a human. It’s a scripted chain or an AI agent having a field day in your environment.
But here is the cynical truth: if your telemetry’s timestamp fidelity, clock sync, or session joins are garbage, VolumetricDE will happily manufacture fake machine-speed chains and waste everybody’s time.
Enter Machina Velocity Engine (MVE) vNext
To actually build VolumetricDE without turning our platform into a giant, flat web form of decorative nonsense, we had to rethink the UX. Forcing volumetric modeling into a standard, ATT&CK-first Workbench is a great way to guarantee nobody ever uses it.
So, we pivoted our Machina Velocity Engine (MVE) vNext to be the primary VolumetricDE design surface.
Here is how we get things done:
- Model the Shape: We use MVE to define the behavior object, shape dimensions, measurement model, time/window logic, and baseline strategy.
- AI Generation: MVE feeds these structured constraints to generate a hardened rule in your target format (KQL, SPL, EQL, or Wazuh).
- Downstream Handoff: The generated rule is kicked over to the existing Monaco-based rule editor.
- Governance & Export: From there, it goes through the standard HEFAISTOS Rule Hub save flow, OpenTIDE YAML compilation, and peer review.
Why split it? Because building a second, half-broken rule editor and a duplicate review workflow inside MVE is the kind of stupid enterprise product mistake we actively avoid. MVE is the brain for velocity and chains; the existing Workbench is the downstream wrapper for governance and SOAR.
Still Breaking Things (In Testing Mode)
Now, before you start throwing your legacy SIEM out the window, a reality check: MVE is still very much in testing mode. We currently have the foundational vNext layer implemented—typed VolumetricDE draft fields, expanded node models, and rule-generation mutation wiring—but we are absolutely not done-done.
We need more use cases, we need more testing, and we need to validate these MVE-generated rules in our labs. We run our Symphony of Destruction scenarios strictly against our test environments, utilizing Ludus PRO v2 and PentAGI distros to ensure the detections hold up against both bursty and slow-and-low evasion variants. We don’t deploy anything until the precision is measured and the benign control activity is successfully suppressed.
VolumetricDE in HEFAISTOS isn’t just about making bigger graphs to impress executives. It’s about giving us the tools to map the actual physics of an attack. We are no longer at “a few text boxes and vibes,” but we still have a lot of work to do.