Stop reading alerts.
Start making decisions.
Seculogik sits above your Wazuh and SIEM telemetry and turns the flood into a handful of qualified cases — each with a persisted decision trace, a kill-chain position, and an AI analyst whose evidence is checked against your own alerts before its verdict stands. On your infrastructure. Without a per-GB meter.
illustrative console · verdicts, factors and names are examples of the engine's real vocabulary
Your SIEM already ingests enough to detect 90% of ATT&CK. It detects 21%.
CardinalOps measured live production SIEM configurations across roughly 2.5 million log sources, MSSPs included. Enterprise SIEMs had detections for only 21% of MITRE ATT&CK techniques, while the data already ingested could cover 90% — and 13% of the rules that did exist were silently broken.
The gap is not collection. It is detection engineering, correlation, and the discipline of turning what fires into something a human can decide on. That is the layer Seculogik is.
Source: CardinalOps, State of SIEM Detection Risk, June 2025 — derived from configuration metadata, not a survey.
One chokepoint. Every alert. One decision.
Every ingest path — Wazuh, connector webhooks, a passive poll of your own SIEM, our detection engine over OpenSearch — converges on a single pipeline. Nothing bypasses it.
A correlation engine that shows its arithmetic.
Nine strategies run concurrently on every alert: entity pivots, forward-only ATT&CK sequences, cross-source fan-out, slow-burn risk thresholds, five named attack storylines, attacker clustering across cases, explicit benign suppression — behind a mandatory scope guard that vetoes anything crossing a client boundary.
Their votes blend into one verdict with a fixed formula, and the per-factor breakdown is persisted with the case. An analyst never has to trust a black box, and a CISO can read why a case exists.
Inside the engine →An L2 analyst that argues in the open — and gets fact-checked.
SIROC reads a case, lists benign hypotheses, evidence for and against, and only then a verdict — because on an autoregressive model everything written after the verdict is rationalisation. Then a grounding gate checks its cited values against the case's own alerts. A true-positive with fewer than two grounded citations is downgraded, in front of the analyst, with the count.
It runs on a 4-billion-parameter Apache-2.0 model on your CPU by default. If you choose a cloud model, a sanitizer redacts secrets, SIRET and RIB before egress, and a write-once ledger records the call before it leaves.
{
"benign_hypotheses": ["scheduled backup", "admin RDP"],
"evidence_for": ["mapped.network.dest_ip …",
"process.command_line …"],
"evidence_against": ["no persistence artifact"],
"what_would_change_this_verdict": "…",
"corroborating_signal_count": 3,
"reasoning": "…",
"verdict": "true_positive",
"confidence": 84,
"recommended_actions": ["isolate_host ⟶ needs approval"]
}grounding gate: 3/3 cited values present in case alerts ✓
What you get that a stack of open-source tools never becomes.
Wazuh, taken to the next level
Keep the agent and the rules you know. Add cases, correlation, SLAs, response and reporting on top — with 72 MITRE-mapped packs to start from.
from Wazuh →Sovereign by design, not by slogan
One box, your jurisdiction. Local inference by default, a strict mode that refuses egress outright, and an attestation endpoint that reports which layer enforces it.
trust page →MSSP-native multi-client
One client = one case space, enforced four independent times. Cross-client reads return 404, not 403 — existence never leaks. White-label per tenant.
multi-client →Decision queue, not a monitoring wall
The default screen answers “what do I do now?”, not “what is happening?”. Awaiting triage, SLA breaching, high risk, unassigned critical — computed deterministically.
read the thesis →Evidence-backed numbers only
Every KPI carries the query that produced it. Insufficient data renders as “insufficient data”, never as a comforting zero. A zero must be explainable.
reporting →Response under human command
17 response handlers, workbooks that pause durably for approval, and eight destructive actions that no playbook author can auto-approve.
response →“A Decision Center should help analysts decide, not generate alerts they can't process.”— the sentence Seculogik was built on
Cyber decision, in writing.
The SOC is a decision system. Build it like one.
"Cyberdecision" is not a dashboard word. It is the claim that a security operations centre exists to produce decisions, not alerts — and that every tool in it should be judged on how it changes the next decision.
How it helpsHow Seculogik helps a small SOC do the work of a large one
Most fully staffed SOCs are two to ten people, and most of them run 24/7 anyway. Here is where the hours actually go, and what a decision layer gives back.
SIROCSIROC: an AI analyst that argues in the open and gets fact-checked
How we built an AI analyst for a sovereign SOC — the verdict-last output contract, the grounding gate, the sanitizer, the write-once egress ledger, and the eight actions no playbook can auto-approve.
Bring your Wazuh. Leave with cases.
A thirty-minute session on your own telemetry: the cases the engine would have opened, the decisions SIROC would have proposed, and the offer that fits your estate. No per-GB meter, no data leaving your perimeter.