A self-hosted AI SOC analyst: running the model on your own hardware
A self-hosted AI SOC analyst that reasons on your own hardware, with no GPU and nothing leaving the box. How SIROC runs local by default, what redaction happens before any cloud call, and how to refuse cloud models outright.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
Most AI SOC analysts are a hosted service: your case data — hostnames, usernames, IP addresses, sometimes the payload — leaves your estate to reach somebody else's model. For a European operator that is often the end of the evaluation, whatever the triage quality. A self-hosted AI SOC analyst reverses the default. SIROC reasons on a local open-licence model, on hardware you already own, with no GPU and nothing leaving the box unless you decide otherwise. This post is about that half: where the model runs, what would leave if you chose a cloud model, and how to refuse outright.
SIROC is the AI analyst inside Seculogik's Seculogik, and it is the Advanced AI module. It works the cases your stack has already produced, and returns four things on every one it reads: a verdict, a confidence score, a recommendation, and the reasoning behind all three. That is a position your analyst takes or overrules, not a summary — and it is what keeps tier 1 on the cases that deserve the hour.
It reads what your existing stack already gives it: market platforms such as Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne and Cortex XDR, and open-source SIEM and data stacks such as ClickHouse, Elastic / ELK, OpenSearch and Wazuh. Where a source is not on that list we build the connector, or you push events through the generic webhook and map them once. It never touches your sensors.
If you are still choosing between AI SOC analysts rather than deciding where one runs, the buyer's checklist is a separate piece: what to demand from an AI SOC analyst before you trust one. What follows assumes you have decided the reasoning has to happen on your own infrastructure.
The verdict comes last, on purpose
An analyst who states a conclusion and then looks for reasons is rationalising, not investigating. A language model that writes its verdict first does exactly that: everything it says afterwards is shaped by an answer it has already committed to, and it reads like reasoning.
SIROC works the other way round. It sets out the innocent explanations and the evidence on both sides first, and only commits to a verdict at the end. Your analyst watches the argument being made rather than decorated. When they disagree, they can point at the exact step where the argument went wrong, which is the difference between an assistant you can supervise and one you have to trust.
The evidence is checked against your own alerts
After SIROC answers, every specific it cites is checked against the alerts actually attached to the case. A verdict resting on evidence that is not in the case is downgraded, visibly, in front of the analyst, with the reason spelled out. The AI does not get to be confident about things your data does not contain. No grounding check catches every fabrication — this one catches the common ones, in front of the analyst, every time.
Those alerts are whatever your stack already produces: a market XDR or SIEM on one side, the open-source stack you run yourself on the other, and a connector we build for you where neither fits. SIROC reasons over the case, never over a particular sensor, so the argument and the evidence check are the same whichever source raised the alert.
Local by default: what running on your own hardware actually means
SIROC runs on a local, open-licence model, on ordinary CPUs, on your own box. No GPU, no API key, no data leaving the building. That is the default, not the premium tier.
If you want a larger cloud model for some tasks, you bring your own key and bind it per task — a large model on triage, a cheaper one on summaries. Four guardrails sit on the cloud path.
- Sovereignty. You decide whether an AI call may leave your infrastructure at all. Set it once for the whole deployment and nothing below can loosen it.
- Consent. An administrator approves a provider before it is reachable.
- Redaction. Secrets and personal data are stripped before anything leaves — cloud keys, tokens, private keys, bank identifiers, and, because we sell in France, SIRET and RIB. Redaction keeps the analysis coherent without the real values ever leaving your box.
- Spend. A spend cap, and a circuit breaker that stops SIROC and asks a person to restart it.
Above all four sits a tamper-proof ledger that records every cloud-bound call before it leaves: what left, where it went, and what was stripped before it did — never the content itself. Your DPO can export it, so what left your box is a matter of record rather than recollection. Local inference is not in the ledger, so we do not say "every AI call". We say every one that left your box.
Bounded autonomy: destructive actions always need a person
A recommendation is not an action, and SIROC does not close that gap on its own. Running a response end to end — and pushing the ticket into your service desk — is the Automations module, where every destructive step passes an approval gate.
SIROC planning that whole response itself, against an attack pattern it recognises — ransomware variants, credential abuse, insider drift — is built and switched off: in development rather than running.
What no setting changes either way: isolating a host, resetting credentials and the like always require a person. No playbook and no configuration can make those automatic. That is what bounded autonomy means here, and it is why no on-call analyst can take the person out of the loop at three in the morning to make the queue move.
Every limit on SIROC can be tightened and never loosened. Circuit breakers stop a model that starts misbehaving. A kill switch turns SIROC off across the deployment.
On the MSSP edition — the one for a managed SOC serving several customers — this is the whole point: you can offer AI-assisted response without a model ever touching a client's estate on its own authority.
How SIROC learns from your analysts
Your analysts' reviews are how SIROC improves. Their corrections are what teach it: an analyst who flips a verdict to false positive without saying why has closed a case and taught it nothing.
You decide how much past human judgement SIROC may consult, and every triage records what it was allowed to see. That is what makes the improvement you report to a board a measured thing rather than an assumed one — you can say what SIROC was shown when it was right, and when it was wrong. The SOC Reporting module turns that record into the scorecards and evidence packs a board or an auditor will ask for.
Where SIROC sits today, and the seat it does not have yet
In the app, SIROC is a button on a case: an analyst runs a triage when they want one, and watches the argument being built. That is the half that runs.
The other half is a seat of its own — an outside agent you already pay for, working your backlog through a governed gateway that reads cases, runs triage and submits verdicts and reviews. It is built and switched off. It is not part of what we would put in front of you today, and we would rather you read that here than find out after signing.
The design is worth stating anyway, because it is what makes that seat governed rather than open. The agent connects in; the platform opens no inbound port. Every write passes the platform's own authorisation and audit, every result is redacted on the way out, and if you turn sovereignty on, the door does not open at all. Bringing the model you already trust should never mean lock-in to ours.
The hardware a self-hosted AI SOC analyst actually needs
SIROC runs on CPU by design, because most SOCs do not have a GPU and should not need one to get an analyst that shows its work. One self-hosted box, no accelerator, no key to buy.
The agentic half — SIROC taking cases out of the queue itself and gathering further evidence before it answers — wants heavier hardware, and it is in development rather than running.
We publish no accuracy figure, because no cross-vendor benchmark exists to make one meaningful; building one is on our roadmap. What we will say is this: SIROC argues in the open, gets fact-checked against your own data, stays on your box unless you decide otherwise, and never acts destructively alone. Our own commitments are on the security and trust page, including what we do not hold: no third-party pentest report, no certification, no SLA. We are pre-GA, with no customers to name.
A better argument needs better context. Feeds and indicators reach the case through the Threat Intelligence module; your posture against known vulnerabilities gets its own discipline in the Vulnerability Operations Centre, which is included with the Client edition rather than sold on top. See the six modules and what each one takes off your week — then, when you want to watch SIROC argue one of your real cases, book a demo.