Mini SOC.

What the Mini SOC is for

The goal is to automate as much of home and small-business security and connectivity management as can be shown to be safe. Show it first. Then automate it.

Every kind of action climbs the same ladder, one step at a time.

An action moves up a step only on a measured record from the step below: how often it was wrong, and how often I overruled it. Today everything sits at observe or recommend. The first candidate for the upper steps is moving an unknown new device into an isolated network.

Why build it

Most homelab SOC projects on GitHub stop once the plumbing works. They skip the question a SOC manager would ask first: can the model's verdict be trusted, and where does a person have to stay in the loop?

After 25 years in cybersecurity, I've watched alert pipelines fail in the same place: the dismissal nobody reviews. An AI tier moves that point. It doesn't remove it. This build puts a local model into a real pipeline and measures where it helps, where it's wrong, and what it costs to keep a person in charge.

How the Mini SOC decides

The rules watch for a device the network has never seen, a changed device name, two devices reporting the same name, a configuration change, an admin login from a new address, and UniFi's own security detections. None of them reads what a device name says. They fire on change.

Thinking mode is off. Simon Willison's verdict on Qwen 3.8-27B's default setting, on 16 August 2026: "It's absolutely not a good way to run the model, especially on consumer hardware." For sorting an alert, it doesn't earn the wait.

The guardrails

• The model can't close, dismiss or silence an alert. Notifications come from the rules. If text inside the data talks the model into "benign", the alert still stands.
• Read-only by construction. The code can make eight kinds of request to the network controller, all of them reads. Two are queries sent as POST, for the event log and the flow log. Anything else raises an error before it leaves the machine. (The credential in use has more rights than the job needs. Replacing it is on the list.) Writes will come one earned action at a time, through a separate component with its own narrow credential, an allowlist per action, an undo and an audit log. The reader stays read-only.
• Every decision is on the record. Which rule fired and at what version, which model and quantisation, a hash of the prompt, the raw output, and what I decided.
• Nothing leaves the building. No cloud model, and no cloud fallback when the local one is down. An alert without an assessment says so.

What the traffic shows, and what it can't

The gateway logs every flow it routes. The Mini SOC reads that log every 15 minutes and keeps daily totals per device: which services, which domains, which countries, how much. Two things are built on it. A recommended VLAN for each device, where the device type comes first and traffic is the evidence. And a baseline of what normal looks like for each device.

The log has a blind spot. Two devices on the same network talk through the switch, and the gateway never sees it. On a flat network, "no local traffic seen" proves nothing. It becomes evidence once devices sit on separate VLANs, where every attempt to reach a neighbour crosses the gateway and shows up as blocked.

The first test made the case for fixed rules. Qwen put the game console in the media VLAN. The rule says a console needs the internet and nothing else. No traffic showed another device using it, so the rule won and the placement waits for me.

The baseline learns for 14 days, then runs in shadow mode. Deviations are listed and never sent as alerts, and I mark each one expected or suspicious. That gives a false-alarm rate for each kind of deviation before any of them is allowed to page. Measure it, then trust it.

Where the Mini SOC stands

Build log

• Oct 10, 2026

  Week two: fewer alerts, one incident view

  What did the Mini SOC do in its second week on a real network?

  4,878 polls, one failure, 13 alerts, 16 training labels. Threat alerts now group as an incident around the device they target, and closing an issue closes only what you saw.

• Oct 3, 2026

  Week one: from alerts to issues

  What did the Mini SOC learn in its first full week on a real network?

  5,318 polls, three failures, 36 alerts, 19 training labels. Alerts now group into issues, devices are learning a baseline, and a security review closed a way to quiet a look-alike network.

• Sep 26, 2026

  The first 26 hours

  What does a rules-first security monitor flag on its first day on a real network?

  778 polls, no failures, three alerts, zero attacks. Two false-alarm patterns the rules missed on day one, and a structuring choice that hid the one field the model needed.

The code is public in promise-and-risk-labs on GitHub, minus anything that identifies the network it watches. The raw output stays private for the same reason.