Why My Homelab Needed TRON
AI is good at spotting patterns and bad at knowing when to stop. Here's why I built a security layer where the AI only ever recommends, and a deterministic engine decides.
The problem
I run a homelab — real services, real exposure to the internet, more moving parts than I can watch manually. I wanted AI to help make sense of the noise: correlate what’s happening across different tools, reason about whether a pattern actually matters. What I didn’t want was to hand an AI the ability to act on my own infrastructure on its own judgement.
Most “AI security” tooling I looked at blurs exactly that line — detection, reasoning and action happen in the same breath, and you’re trusting the model’s judgement calls by default. I wanted to keep that line sharp on purpose.
Why the existing tools weren’t enough on their own
CrowdSec and Uptime Kuma already do their jobs well — they detect. What neither does is correlate across the other, reason about what a pattern of events actually means, or decide what should happen next in a way I’d trust unattended. I didn’t want to replace either of them. I wanted a layer on top that could think about what they were telling me, without getting to act on that thinking by itself.
What I decided
A fixed pipeline: Detection → Normalisation → Correlation → Reasoning → Policy → Execution → Audit. Each stage has exactly one job. Detection modules turn tool-specific alerts into a common shape. Reasoning — the only stage that touches an LLM at all — produces a recommendation, nothing more. A deterministic Policy Engine, plain rule evaluation with no model in the loop, makes the actual call every time. Execution only ever runs what Policy explicitly authorised.
The rules loader is fail-closed: if a rule can’t be loaded or validated, it doesn’t run on a best-effort guess — it refuses to apply that rule at all. Same instinct through the whole pipeline: an unclear or degraded signal means “don’t act,” not “act anyway.”
It’s built as a modular core plus independent modules, not an application hardcoded to CrowdSec and Uptime Kuma specifically, so the next tool plugs in the same way those two did.
Current result
Over 600 automated tests cover the pipeline end to end. Both real detection modules were validated against the live, running tools before I trusted them — not just against mocked responses — and both needed real fixes once connected to the genuine APIs, which is exactly what that step is for.
It’s active development, not a finished product. The core pipeline, both detection modules, the rules engine, and the AI reasoning stage are built and running on my own infrastructure; the policy/approval layer is still being extended. Full detail on the TRON project page.