Hurricane Sentinel

Summary

Hurricane Sentinel is the secure agent harness for local AI. It runs AI agents on your own machine under real, enforced guardrails — routing every model call through Muzzle (the inspecting proxy) and running each agent as a Leash-leashed user (so the OS enforces what it can touch, reach, and run). On top of that it adds durable, resumable runs and a human approval queue: when an agent tries something flagged, the run pauses and waits for a person to approve before continuing.

Sentinel is the control center that ties the three Hurricane products together: Muzzle guards the model I/O, Leash guards the OS actions, and Sentinel orchestrates the agent and owns the human-in-the-loop.

Status

In the Lab. The core supervised-run engine and persistent-agent orchestration are built and validated end-to-end on Linux: agents run as the leashed user with model calls through Muzzle, flagged actions pause for operator approval and resume on a yes (including under live Leash filesystem enforcement), and a main agent delegates tasks to a roster of persistent specialist agents. The remaining milestones (memory + context compaction, saved workflows, a local web UI) are in progress. Linux only; no public download yet.

What works today

• Supervised runs as the leashed user. Each run executes as a dedicated Leash user; the OS enforces its file/network/command access per-UID, with model traffic inspected by Muzzle.
• Durable, resumable runs + async human approvals. Run state is checkpointed to disk; a needs_approval action pauses the run and enqueues an approval that an operator approves/denies via the CLI, after which the run resumes where it stopped.
• Persistent agents. A roster of on-disk specialists (~/.sentinel/agents/), each with its own soul (persona), bound model (from your configured list), extensible skills, and tools. sentinel agent create/list/show/add-skill/set-model and sentinel run --agent <name>.
• Orchestration. A main agent can delegate a task to a persistent specialist, or spawn_subagent to compose a temporary one when none fits — each as its own durable, enforced child run, with least-privilege grants and a configurable disposition (discard / save / ask).
• Memory + context compaction. Each agent has its own memory bank (private, or shared by scope) — a flat index plus an Obsidian-style note vault; it can remember facts and recall them across runs. Long runs auto-compact: older turns are summarized while the system prompt and recent turns are kept, so an agent never blows its context window.
• Small-model friendly. A tool-use prompt scaffold, forgiving tool-call parsing, arg normalization + validation with self-correction, automatic delegation context, duplicate-call dedup, and a bundled file-discipline skill keep things reliable on small local models (e.g. llama3.2, gpt-oss:20b).
• An interactive chat shell. sentinel chat opens a sleek REPL: a framed banner, colorized live progress, inline yes/no approvals, ↑/↓ history, and completion menus for / commands, @ targeted specialists, and $ skills. (Run it as the leashed user: sudo -u <user> sentinel chat.)
• Saved workflows. Define a named, multi-step pipeline in YAML where each step runs an agent on a task and outputs thread into later steps via {{input}} / {{<step>.output}} templating. Run it with sentinel workflow run <name> or let an agent trigger one with the run_workflow tool; every step is its own supervised run.
• A sentinel CLI. init, chat, run, runs, show, approvals, approve/deny, resume, agent …, workflow …, status, logs.

How it fits together

operator ── sentinel CLI ──┐
                           ▼
        Supervisor (root) ── spawns each run as the leashed user
                           │
        Agent worker (as leashed user)  ── model calls ──▶  Muzzle ──▶ provider
          loop: model → tool calls → policy(auto / needs-approval / deny)
            auto → run the tool        (file/net/exec enforced by Leash)
            needs-approval → pause + enqueue → (operator approves) → resume
            deny → tell the agent

Roadmap

M0 supervised runs + approvals ✅ → M1 persistent agents + orchestration ✅ → small-model robustness ✅ → memory + context compaction ✅ → interactive chat shell ✅ → saved workflows ✅ → next: local web UI.

See docs/plans/2026-06-25-sentinel-v1-design.md for the full design and docs/plans/2026-06-25-sentinel-m1-persistent-agents.md for the agent/orchestration design.