An autonomous AI sysadmin that guards your Ubuntu server 24/7, and only thinks when it has to.

Stops brute force and floods in seconds · investigates and fixes problems · follows them up until they're solved · emails you what happened

Quick start · How it works · What it catches · Cost · Safety · Contributing

Most monitoring tools tell you something is wrong at 3 a.m. and leave the rest to you. Warden handles the 3 a.m. part itself. It reads the logs, works out the cause, fixes what is safe to fix, keeps watching until the fix holds, and writes you a short report.

It does this without paying an LLM to stare at your server all day.

git clone https://github.com/dyablohunter/warden.git && cd warden cp .env.example .env && nano .env # LLM API key, EMAIL_TO, SMTP_*, WARDEN_ALLOWLIST sudo ./install.sh --extras # --extras adds lynis, debsums, needrestart, smartmontools

The installer:

Warden then onboards itself and emails you an introduction to your own server.

warden status # what it's watching, incidents, bans, token use warden ask "why is load high?" # give it a task journalctl -u warden -f # watch it think

Tip: start with WARDEN_AUTONOMY=observe for a few days. Warden investigates and reports but can't change anything until you trust it.

┌──────────────────────────── warden.service (root, Restart=always) ────────────────────────────┐ │ JOURNAL STREAM (real time) SENTINEL (every 10s, /proc only) MAIN LOOP (sleeps) │ │ ssh / postgres / mysql / mail SYN cookies, listen drops, conntrack, 1. notable events │ │ auth failures ──► ban pps, Mbps, disk fill ETA... 2. incident follow- │ │ log triggers ──► event per-IP floods ──► ban ups (backoff) │ │ new error signatures ──► db web: floods, scanners, credential 3. onboarding (1x) │ │ stuffing, exploits ──► ban 4. gated routines │ │ anomalies vs learned baseline ─┐ │ │ │ warden event "..." ─────────────── triggers ─────────────────── wake ▼ │ │ LLM AGENT + tools │ │ nftables inet warden · expiring bans · per-source SYN/conn/ICMP limits (shell, files, bans, │ │ + optional Cloudflare edge bans incidents, triggers) │ └───────────────────────────────────────────────────────────────────────┬───────────────────────┘ ▼ email: alerts + weekly report

Routines collect data without the LLM. Each data source has a gate. The LLM is called only when a gate fires, and then it sees a diff against what it last reviewed, not a full dump.

Triggers are deterministic watchers the agent creates for itself, for example "wake me if Postgres connections > 80", "if nginx logs 50 upstream timeouts in 5 minutes", or "if this file changes again". Kinds: metric, log (real time), command, service, port, file. Your own scripts can wake it too: warden event --severity high "backup failed".

Threat How it's detected (cheaply) What happens

SYN / connection / ICMP floods per-source kernel limits; SYN cookies, accept-queue drops, conntrack fill dropped in-kernel; floods banned; the agent can tighten limits live

Distributed floods new connections/s, packets/s, Mbps and HTTP rates vs a learned baseline anomaly wakes the agent with the top talkers

Volumetric DDoS inbound bandwidth vs link speed critical alert telling you to enable upstream mitigation

SSH / database / mail brute force sshd, PostgreSQL, MySQL, Postfix, Dovecot failures, streamed live escalating bans

Web / API abuse request floods, 4xx storms, credential stuffing, exploit probes, scanner user agents (sqlmap, nikto, nuclei…) in nginx/apache/Caddy logs ban on the host, and at the Cloudflare edge if configured

Disk trouble usage, time-until-full from the fill rate, I/O saturation, read-only remounts, kernel I/O errors the agent finds the writer or failing disk

Compromise / persistence changes to passwd, sudoers, root keys, ld.so.preload; new network processes (miners, reverse shells); deleted binaries; /tmp executables the agent investigates

Health new error signatures, failed units, OOM kills, memory, load the agent investigates and fixes

☁️ Cloudflare-aware

Warden works the same whether some sites, all sites, or none sit behind Cloudflare:

Measured on Ubuntu 26.04 with deepseek-chat. "Effective" counts cached prompt tokens at 10%, which is roughly how providers bill them.

Everything Warden stores is rotated automatically: events, audit trail, emails, error signatures, incident notes, config backups. Hard row caps mean even a sustained attack can't bloat the database.

Guardrail What it does

Autonomy levels observe (read-only; it can still tune its own watchers) → contain (+ bans) → full (+ system changes)

Denylist, always on blocks disk wipes, rm -rf /, curl | sh, flushing firewalls, stopping SSH or Warden, reboots (unless allowed), and reading secrets (.env files, private keys, /etc/shadow)

Read-only classifier everything that runs without LLM review (collectors, command triggers) must be provably read-only

Protected IPs never banned: your allowlist, the host's own addresses, recent successful SSH logins, Cloudflare, and private IPs in web logs (usually your proxy)

Config edits backed up, written atomically, validated (sshd -t, nginx -t, visudo -c, nft -c…) and rolled back on failure

Prompt-injection aware log lines, URLs and user agents are wrapped as untrusted data, and the model is told never to follow instructions found in them

Audit trail every tool call is recorded (warden log)

Honest limits: a host can't absorb a flood that saturates its uplink. Put serious targets behind upstream protection (your provider's DDoS filtering, or Cloudflare). Warden will detect the saturation and tell you. Warden is a powerful root process; read the code, start in observe mode, and use it at your own risk.

Everything lives in /etc/warden/warden.env. See .env.example for every knob.

LLM_PROVIDER=deepseek # deepseek | openai | anthropic | gemini | mistral | groq | openrouter | ollama | custom DEEPSEEK_API_KEY=sk-...

LLM_MODEL=... LLM_BASE_URL=... LLM_FALLBACK_PROVIDER=ollama

WARDEN_AUTONOMY=observe # observe | contain | full WARDEN_ALLOWLIST="203.0.113.7" # your IPs: never banned EMAIL_TO=you@example.com # alerts + weekly report SMTP_HOST=smtp.example.com CLOUDFLARE_API_TOKEN=... # optional: edge bans

CLI reference warden status routines, triggers, incidents, bans, token use, recent LLM runs warden onboard (re)run the host profile warden run <routine> [--force] run a routine now (--force calls the LLM even if nothing changed) warden ask "..." give the agent an instruction warden event [--severity S] "..." wake the daemon with an event warden incidents [ID] [--all] incidents / full history warden resolve ID "note" warden bans | ban IP | unban IP warden routines [-v] [enable|disable NAME] warden triggers [-v] [enable|disable|delete NAME] warden log -n 100 audit log of everything the agent did warden check | test-llm | test-email

🗺️ Roadmap

Ideas we'd love help with. Each one is a good place to start contributing:

Warden is young and contributions are very welcome, whether you're a sysadmin with war stories, a security person who wants to break it, or a Python developer who likes clean, dependency-free code.

Read CONTRIBUTING.md for the dev setup and design principles. The short version: stdlib only, cheap detection first, never weaken a safety invariant without discussion, and every parser comes with a test. python3 -m unittest discover -s tests -t . runs the full suite in a few seconds on any OS, with no root and no network.

If Warden saves you a night's sleep, ⭐ star the repo and tell a fellow sysadmin.

MIT © 2026 dyablohunter. Architecture notes for contributors (and AI coding assistants) are in CLAUDE.md.