The guard in your pocket.
Alerts only when they matter. Answers when you ask. And the dangerous buttons locked behind a code. One real day with the bot, annotated.
The notification gate pages you now only for an uncontained compromise or intrusion. Already handled? It waits for the daily briefing. Hard cap of 10 alerts per hour, and duplicates group for 4 hours.
Free text goes to the LLM you configured (/ask), your provider, your key. No LLM set up? The bot still answers the structured commands.
Every message the bot sends is appended to an audit file on the host (telegram-sent.jsonl). The chat is evidence too.
SSH brute force from 203.0.113.7
Repeated auth failures, spread over ports.
⚡ Handling. Stand by for action report.07:42
2 incidents today, both contained.
Next briefing 08:00.15:10
Periodic callbacks to a new domain
What happened: a user process calls the same unknown endpoint every 60s. Recommended checks: process lineage, first-seen domain age.
The Warden could not confidently decide this one. What should it do?
Slash commands answer from the machine's own state: status, threats, incidents, the sshd, sudo and firewall settings, health. The full deck is below.
This is the needs-human review from part 3, delivered: Block, Ignore or Dismiss, one tap, logged with your name on it. Off by default (needs_review_notify).
Only the exact configured chat id is heard; anything else is dropped, fail closed. Mode changes, unblocks and allowlist edits can demand a TOTP code on top.
What you can ask it
The bot can flip enforcement mode, release blocks and toggle capabilities, so it is treated as a privileged surface: it listens to one exact chat id and drops everything else, fail closed; the dangerous commands can demand a TOTP second factor; alerts are hard-capped and deduplicated so a flood cannot bury the one that matters; and every message sent is appended to an audit log on the host. Configure the two-factor: without it, whoever holds the chat holds the buttons.
Community notifies, one way: a deny always pings (review is opt-in) on Telegram, Slack, Discord or a webhook, with the verdict and risk, for example 🚫 InnerWarden guardrail: DENY `curl x | bash` (risk 90). Delivery has a 150 ms total budget so notifying can never slow a blocking verdict. The two-way remote control above is in Pro and Enterprise, and chat-button decisions are Telegram only; Slack and Discord are outbound alerts.
The two-way bot is in Pro and Enterprise, default off, configured with a bot token and one chat id. Inbound is fail closed: only the exact configured chat id is processed. TOTP two-factor guards mode changes, unblocks and allowlist edits when enabled; enable it, the default is off. Alert flow control: hard cap of 10 automated alerts per hour, duplicate incidents grouped for 4 hours, critical severity breaks the daily budget. The needs-human review push is off by default (needs_review_notify). Every outbound message is appended to telegram-sent.jsonl on the host. Community notifications are one-way (deny always, review opt-in) with a 150 ms total delivery budget. Slack and Discord are outbound only, in both tiers; buttons exist only on Telegram. The conversation above is reconstructed from the real message templates in the agent's code; the needs-review question and the Executed line are verbatim, the status and 2FA wordings are abridged. IPs shown are documentation-reserved addresses. Facts from the product source (telegram client, notification gate, notification config) as of 2026-08-15.