Hurricane Sentinel in Plain English v8
This is the stored snapshot for the approved document version. The diff below shows what changed from the previous version.
Document snapshot
Hurricane Sentinel in Plain English
Summary
Sentinel is a safe place to run AI agents on your own computer. An agent is an AI that doesn't just chat — it takes actions: reading files, running commands, calling out to the network. Sentinel lets it do useful work while keeping it on a tight, enforced leash and keeping a human in charge of anything risky.
Just talk to it
You drive Sentinel from a clean little chat window in your terminal — or from a web
console in your browser, whichever you like. You type what you want; the agent works on
it and shows you, step by step, what it's doing — which AI it's asking, which tools it's
using, which teammates it's handing work to — and types out its answer at the end. When
it wants to do something you've marked as risky, it stops and asks you right there: yes
or no. In the terminal, start a line with a slash for commands (like switching agents or
picking a different AI model), with an @ to hand a job to a particular specialist, or
with a $ to browse the skills you can give an agent. The web console gives you the same
chat plus simple pages to set up your agents, teams, tools, models, and the guardrails —
all from the browser.
The three guards, working together
Sentinel is the conductor for the other two Hurricane tools:
- Muzzle sits in front of the AI model and checks everything going in and coming back out.
- Leash gives the agent its own user account on the machine and lets the operating system decide what it can touch, reach, and run.
- Sentinel runs the agent inside both of those guards, and adds the missing piece: a human approval step.
Because the agent runs as a real, leashed user account, the limits aren't a promise the AI makes — they're enforced by the computer itself.
When something's blocked, it says so
Guards only help if you can see them working. So when Muzzle stops something the AI tried to say or was handed, or when Leash blocks it from opening a file or reaching a website, Sentinel doesn't just fail quietly. The agent is told, in plain terms, what was blocked and why — so it adapts instead of getting stuck: it rewords a reply that crossed a line, stops and explains when it was given something it isn't allowed to handle, or tries an allowed folder or site instead of banging on a locked door. You see it too: a clear, color-coded note appears in the activity feed telling you exactly what got stopped and the real reason behind it. The agent even carries a short built-in cheat-sheet on what each kind of block means and how to handle it. None of this loosens the guards one bit — it just makes them legible, so a block becomes useful information instead of a dead end.
Stop and ask a human
This is the part that makes Sentinel different. You decide which actions are fine to do automatically, which are flat-out forbidden, and which should stop and ask. When the agent reaches for a "stop and ask" action, Sentinel freezes the task right there, saves its place, and waits. Later you look at what it wants to do and say yes or no. If you say yes, it picks up exactly where it left off and carries on. If you say no, it's told no and keeps working around it. Nothing risky happens without a person's say-so.
Never loses its place
Every task is saved as it goes. It can pause for an approval for as long as it needs and resume later from the exact same spot — nothing is lost, and you always have a record of what happened.
A team of specialists
You don't run one all-purpose AI — you build a small team. Each agent has its own personality, its own know-how (skills), and even its own AI model. One of them is the manager: when you give it a job, it picks the right specialist from your team and hands the task off, or — if nobody on the team fits — it creates a temporary helper just for that job. You can keep a good temporary helper around for next time, throw it away, or have Sentinel ask you. Every hand-off still goes through the same "stop and ask" approval, and each helper is held to only the abilities you've given it.
You can also group agents into a proper team with a leader. Hand the whole team a job and the leader breaks it down, parcels the pieces out to its members, lets them work in parallel, and pulls their answers back together for you. Each member works in its own sealed-off space and can't peek into another team's files — so a big job gets done by many hands without anyone stepping on anyone else.
Give it your own tools
Built-in tools not enough? Hand Sentinel a Python file of your own. It reads the file to see what's inside — without ever running it — and shows you the functions it found; you tick the ones you want to become tools, and from then on your agents can use them, still behind the same "stop and ask" approval. If your tool needs extra software to run, Sentinel spots that and installs it for you with one click. Your code only ever runs in the same locked-down, leashed space as everything else — never with the keys to the whole machine. And nothing it runs can run away with the machine: every command or tool gets a time limit and a hard stop, and if it exceeds them Sentinel kills it — along with anything it started — so a stuck or runaway job can't hog the computer or flood it.
Hand your whole team to someone else
Built a team you love? You can pack it up into a single file — the agents, their skills, their tools, your instructions, even the Python tools you added — and send it to someone else. They drop that file into their own Sentinel and get the exact same working team, minus your private keys (they add their own). It's like giving a friend a fully set-up marketing department in one download. Passwords and API keys never travel in the package.
Local or big-name AIs, your choice
Run everything on free models on your own machine, or plug in a paid one like OpenAI when you want more horsepower — you add it once from the console. Either way, every request still passes through Muzzle on the way out, so private details and secrets get scrubbed before they ever reach an outside company. Your API keys are held in one guarded place and are never shown back to you or handed to the AI.
Use Codex or Claude Code — on the plan you already pay for
If you already have a Codex or Claude Code subscription, you can put one of those coding assistants to work as an agent inside Sentinel — running on your subscription, not a pay-per-use API key. It joins teams, uses workspaces, and can call any Sentinel tools you hand it, just like any other agent. Best of all you can watch it work: its thinking, each command it runs, and what came back all show up as a tidy, expandable "steps" panel above its answer — so it's never a black box.
Setting one up is three steps, and Sentinel tells you which one you're on:
sentinel runtime install codex # once per machine
sentinel runtime auth codex # paste the credential; see below
sentinel runtime status # ✓ ready / ! needs a credential / ✗ not installed
The middle step needs a web browser, so you do it on your own computer — claude setup-token
prints a token, codex login signs you in — and paste the result into Sentinel. It keeps that
credential locked to your account on the machine and hands it to the assistant only for the
length of a single job, so one agent can never read another's. Different agents can even run on
different subscriptions.
One honest trade-off. These assistants bring their own sandbox and drive their own loop, so
two of Sentinel's guards step aside for them: the per-job filesystem lock and the model-traffic
inspection. What stays is real — they still run as the restricted user, still can't reach the
network beyond what Leash allows, and are still capped by the same resource limits. Because
that's genuinely less protection, a production setup refuses to run one until you say in
writing that you accept it (allow_cli_runtime: true), and every job records which guards were
in force so you can check later.
Two ways to run it — same thing underneath
On a Mac, Sentinel is an app that quietly runs a small Linux machine on your laptop, because the guards it relies on are Linux features. On a server, it installs directly.
Both are the same Sentinel, installed the same way from the same download. The only thing that
changes is how you type a command: on a server it's sentinel status, and on a Mac you put
sentinel-runtime cli in front — sentinel-runtime cli status. Everything after that is
identical, so any instruction you read for one works on the other.
Browse the files like a Finder window
There's a Files tab that shows you what your agents have actually been making. Pick a workspace — the shared one, or any single agent's or team's — and click through the folders just like a file window on your computer: open text and images to preview them, and drag in uploads, make folders, rename, delete, or download. It's the simple way to hand a file to an agent or grab a result back out. And it only ever lets you see inside that workspace — never the rest of the machine.
It remembers
Each agent keeps its own notebook. When it learns something worth keeping, it writes itself a note; later — even in a completely separate session — it can look that note back up and use it. The notebooks are private to each agent by default, but you can let a few agents share one. So your specialists actually get better over time instead of starting from scratch every run. And because a long task can fill up an AI's short-term memory, Sentinel quietly tidies up as it goes — summarizing the older back-and-forth while keeping the important recent bits — so nothing important gets lost and the agent never runs out of room.
Made to work with small AIs
You shouldn't need an enormous, expensive model to get reliable results. Sentinel does a lot of quiet work so even small models running on your own machine behave well: it tells the model clearly how to use its tools, understands a tool request even when the model phrases it sloppily, fixes up small mistakes and asks the model to try again, and makes sure a specialist always gets the full original request — so a manager's terse hand-off never drops the details.
Everyone signs in as themselves
Each person has their own account and their own sign-in — not one shared password passed around the team. Your conversations are yours. Nobody else sees them in their list, and a conversation from before accounts existed is kept for an administrator to hand to whoever actually ran it.
To let somebody in, open the conversation's share control, pick their account, and choose whether they can reply or can only read. They then see the whole transcript, including everything already in it — so share deliberately. You can take it back from the same place.
In a shared conversation you can type @ and somebody's name to pull them in:
they get told, they get access, and your message stays where it is. A message
whose only names are people is a note — it goes in the conversation and
nobody's AI is asked anything, because nobody asked it anything. Every message is
labelled with the person who wrote it (yours says you), and the agent is told
who it is talking to and who else can read what it says.
If you @ a colleague in a conversation whose agent their account is not allowed
to use, Sentinel asks you right then: let them take part in this conversation,
or leave them reading it? Allowing applies to that one conversation only.
Deciding what each person may do
An account's Access page is a plain list of things it may do, each one a sentence rather than a technical name: create and edit agents, set up workspaces and scheduled jobs, configure AI providers, set up API endpoints, edit the guardrails, read the record of who did what. A role (administrator, operator, approver, member, read-only auditor) ticks a sensible starting set and you adjust it from there.
Two of them also ask how far: AI providers and API endpoints can be allowed either for the ones that account set up or for everyone's. So someone can add and manage their own without touching anybody else's. The lists say who set each one up, so it is obvious at a glance. You can also limit an account to named agents, and then it can only talk to those.
Bringing another agent into a conversation
Mid-conversation you can bring in a different specialist. You say who, what you
want them to do, and then choose: just this task — they answer once and are
gone — or stay in the conversation, so you can keep calling on them with @
and let them leave when you are done. Either way they work in their own locked-down
space, not the conversation's, so inviting one never widens what it can reach. The
transcript says when they arrived and left, so a second voice never reads as the
first one changing its mind.
Hand it a whole code repository
You can attach a git repository as a codebase. Agents can search and read it, and when one needs to change something it gets its own private copy for that job — your working tree is never touched. Getting a change back out is deliberate: the agent can ask for a branch to be pushed, and a person with the authority approves it. The agent never pushes anything itself.
A record of who did what
Every change anybody makes is written to an append-only record: who asked, what they asked for, what it was about. It can be read in the console by an administrator or an auditor and verified from the command line, and it cannot be edited through the product — only added to. If the record cannot be written, the default is to refuse the action rather than let it happen unrecorded.
Save a recipe and reuse it
For jobs you do over and over, you can save a workflow — a little recipe of steps. Step one might be "have the researcher gather the facts," step two "have the writer turn them into a summary." Sentinel runs the steps in order and automatically hands each step's result to the next, so the writer gets exactly what the researcher found. You give it a starting input, run it by name, and it does the whole sequence — and every step still runs under the same guards and approvals as anything else.
Where it's at
Sentinel is in the lab, but wide and running on real machines. The whole thing works end to end on Linux: agents running under the guards with real operating-system enforcement actively blocking off-limits files, pausing for approval and resuming, managers and full teams delegating to persistent specialists, agents that remember across sessions, saved multi-step workflows, scheduled jobs — driven from either a clean chat window or a browser console. Since then it's grown: the web console is built, teams, paid AI providers alongside the free local ones, your own uploaded Python tools, packing up a whole team to hand to someone else, bringing an existing OpenClaw or Hermes assistant across, running Codex or Claude Code as an agent on your own subscription (with its full work shown step by step), and a Finder-like file browser for the workspaces. The whole platform has been through a security review and hardened against the problems that review turned up. You can install it today: on a Mac it's a single command that puts a Sentinel app in your Applications folder — nothing else to install first — and on Linux it installs on a server from source.
Since then it has become something a team uses rather than one person: named
accounts, conversations that belong to whoever started them and are shared on
purpose, @-ing a colleague into one, a per-account list of what each person may do,
and an append-only record of every change. Agents have grown up too — each one now
runs as its own operating-system account, so the guards confine them separately
rather than as one lump; a whole git repository can be attached for them to read,
with a person approving anything that goes back out; folders on another machine can
be mounted live instead of copied; one screen shows every log the deployment
writes; and Brenda, a 3D designer agent that drives Blender and exports print-ready
models, ships in the box. Downloads can be checked — each release is published
with a fingerprint and a signature, so you can confirm what you downloaded is
exactly what was published before you install it.
Diff from previous
--- PLAINENGLISH@7 +++ PLAINENGLISH@8 @@ -175,6 +175,70 @@ phrases it sloppily, fixes up small mistakes and asks the model to try again, and makes sure a specialist always gets the full original request — so a manager's terse hand-off never drops the details. + +## Everyone signs in as themselves + +Each person has their own account and their own sign-in — not one shared password +passed around the team. **Your conversations are yours.** Nobody else sees them in +their list, and a conversation from before accounts existed is kept for an +administrator to hand to whoever actually ran it. + +To let somebody in, open the conversation's share control, pick their account, and +choose whether they *can reply* or *can only read*. They then see the whole +transcript, including everything already in it — so share deliberately. You can +take it back from the same place. + +In a shared conversation you can type `@` and somebody's name to pull them in: +they get told, they get access, and your message stays where it is. A message +whose only names are people is a **note** — it goes in the conversation and +nobody's AI is asked anything, because nobody asked it anything. Every message is +labelled with the person who wrote it (yours says *you*), and the agent is told +who it is talking to and who else can read what it says. + +If you `@` a colleague in a conversation whose agent their account is not allowed +to use, Sentinel asks you right then: let them take part in **this** conversation, +or leave them reading it? Allowing applies to that one conversation only. + +## Deciding what each person may do + +An account's **Access** page is a plain list of things it may do, each one a +sentence rather than a technical name: create and edit agents, set up workspaces +and scheduled jobs, configure AI providers, set up API endpoints, edit the +guardrails, read the record of who did what. A role (administrator, operator, +approver, member, read-only auditor) ticks a sensible starting set and you adjust +it from there. + +Two of them also ask **how far**: AI providers and API endpoints can be allowed +either for *the ones that account set up* or for *everyone's*. So someone can add +and manage their own without touching anybody else's. The lists say who set each +one up, so it is obvious at a glance. You can also limit an account to **named +agents**, and then it can only talk to those. + +## Bringing another agent into a conversation + +Mid-conversation you can bring in a different specialist. You say who, what you +want them to do, and then choose: **just this task** — they answer once and are +gone — or **stay in the conversation**, so you can keep calling on them with `@` +and let them leave when you are done. Either way they work in their own locked-down +space, not the conversation's, so inviting one never widens what it can reach. The +transcript says when they arrived and left, so a second voice never reads as the +first one changing its mind. + +## Hand it a whole code repository + +You can attach a git repository as a **codebase**. Agents can search and read it, +and when one needs to change something it gets its own private copy for that job — +your working tree is never touched. Getting a change back out is deliberate: the +agent can *ask* for a branch to be pushed, and a person with the authority approves +it. The agent never pushes anything itself. + +## A record of who did what + +Every change anybody makes is written to an append-only record: who asked, what +they asked for, what it was about. It can be read in the console by an +administrator or an auditor and verified from the command line, and it cannot be +edited through the product — only added to. If the record cannot be written, the +default is to **refuse the action** rather than let it happen unrecorded. ## Save a recipe and reuse it @@ -201,10 +265,15 @@ your Applications folder — nothing else to install first — and on **Linux** it installs on a server from source. -Two more recent changes worth knowing. **Everyone signs in as themselves.** Instead of one -shared password that everybody passes around, each person gets their own account and their -own sign-in, and you choose what they're allowed to do: run things, approve risky actions, -just look without changing anything, or administer the system. You can disable someone's -account and they're signed out everywhere immediately. And **downloads can be checked** — -each release is published with a fingerprint and a signature, so you can confirm what you -downloaded is exactly what was published before you install it. +Since then it has become something a **team** uses rather than one person: named +accounts, conversations that belong to whoever started them and are shared on +purpose, `@`-ing a colleague into one, a per-account list of what each person may do, +and an append-only record of every change. Agents have grown up too — each one now +runs as its own operating-system account, so the guards confine them separately +rather than as one lump; a whole git repository can be attached for them to read, +with a person approving anything that goes back out; folders on another machine can +be **mounted live** instead of copied; one screen shows every log the deployment +writes; and Brenda, a 3D designer agent that drives Blender and exports print-ready +models, ships in the box. **Downloads can be checked** — each release is published +with a fingerprint and a signature, so you can confirm what you downloaded is +exactly what was published before you install it.