Roadmap
Everything on this page is roadmap — in design or development, not yet shipped. We publish it because buyers deserve to know where a platform is going, and because each item builds directly on the investigation layer that exists today.
What we build next
These are numbered by build order, not by pipeline stage — 01 is what the team is working towards now. Each one extends the approve-then-execute loop that already runs in production for detection tuning: agents open the change, a human applies the ones that reach a live system.
Policy-driven response actions executed through the same secure, audited tool layer the investigation agents use: block traffic, isolate a system, lock a compromised account — in minutes from first signal, within boundaries you define, with every action on the record and reversible procedures documented.
Qualified incidents delivered into your on-call and CSIRT channels, each carrying its response agent: recommended actions become one-approval executions, with the full investigation attached.
Close the loop with the people who know: "Did you just log in from a new device?" Verified user responses feed incidents directly, resolving ambiguous signals in minutes instead of analyst-hours.
Sequencing and availability are subject to change; roadmap items are not commitments to deliver by a given date. If one of these capabilities is decisive for your evaluation, talk to us — pilot feedback directly shapes priority.
Also in development
The items above extend what the platform does. These two change where it can run — and for some organisations that is the more consequential axis.
The AI-assisted workflows currently reach a cloud model provider. That means a fully disconnected deployment can ingest, detect, correlate and search, but cannot onboard a new source — setup is the part that needs a model. Pointing the platform at a model running inside your own network closes that gap and makes air-gapped operation complete rather than partial. The plumbing is the straightforward half; establishing that an open-weight model does this job well enough is the actual work, and we would rather validate that than announce it.
Qvasir consumes from the streaming backbone it deploys with. If you already operate Kafka, reading it in place — with your authentication, your topics and your ACLs — avoids running a second backbone alongside the one you have, and a duplicate copy of telemetry already on your disks.