OpenClaw Security Hub Became Useful When Alerts Turned Into Work Items
Why I built a homelab security hub around OpenClaw, how the FastAPI service writes review notes, and why the human decision stays separate.
This project started from a small worry about AI-assisted security notes. A generated paragraph can look polished even when the evidence is thin. That is not helpful when the note might be used as a handover or a decision record.
So I built OpenClaw Security Hub around a different idea: do not make the alert sound smarter. Turn it into a work item.
The service is a small FastAPI app running in Docker on an Ubuntu homelab. It receives generic webhook alerts through a secret header, monitors repeated SSH failures, checks disk usage, watches OpenClaw gateway health, and runs host posture checks from /proc, SSH config, disk state, and reachable services.
Telegram is the noisy output. The OpenClaw workspace is the useful output.
Each alert becomes a Markdown review note with separate sections for summary, confirmed evidence, unknowns, suggested checks, OpenClaw review request, human decision, final outcome, and raw alert JSON. The separation is the point. If the evidence is missing, it stays visibly missing.
The project also writes queue JSON, event history, latest summaries, dashboard data, daily briefings, posture reports, and a NIST CSF 2.0-style self-assessment. That sounds like a lot for a homelab, but it made the workflow less like a toy. Alerts, evidence, gaps, and next actions now have places to live.
The most useful development lesson was operational, not just Python. I had to think about .env boundaries, Docker mounts, file ownership, Tailscale access, exposed ports, SSH hardening, and how to test alerts without pretending everything is an incident.
Next I want better sample alert types and a clearer dashboard view. I still do not want the system deciding whether something is safe. Its job is to collect facts, keep the queue readable, and make the next human check faster.