Approvals & privacy

Muster bots do real work on real computers — which is exactly why consequential actions wait for you. This page is the control layer: approval cards, always-allow scopes, the evidence strip that informs your decisions, and what stays on your machine.

Approval cards Always-allow scopes Evidence strip Local-first Claim-gated access

Bots ask before they act

When a bot wants to run a shell command or edit a file, the request surfaces as an inline card in the thread. You have three moves: Allow, Deny, or answer in the thread — often "no, do this instead" is the fastest review of all.

While a card is open, the bot's activity reads waiting-on-you, so a glance at the presence bar tells you who needs a decision. You can answer from the desktop, the web app, or the mobile companions — thin clients built for exactly this: approvals and streaming replies on the go.

If you trust a bot's loop completely, auto-mode exists — but it is per bot and opt-in. Nothing runs unattended by default.

Always-allow scopes

Re-approving git status forty times a day isn't governance, it's friction. Pressing Always allow on a card grants standing permission per capability — and the grant is as narrow as the thing you actually looked at. Command tools are scoped by program: allowing Bash:git never hands the bot a permanent unattended shell.

The grant's key is computed once, server-side, and echoed back to the client, so the two sides can never disagree about what was granted.

Even with a standing grant, anything that reads as destructive stops and asks a human anyway:

Backstop	What trips it
Destructive	`rm -rf`, `mkfs`, `shutdown`/`reboot`, fork bombs, `git push --force`, `git reset --hard`, `DROP TABLE`, `sudo rm`, `chmod -R 777 /`
Sensitive	`.env` files, `.ssh` keys, `.aws/credentials`, `.netrc`, keychain access, service-account and credentials files — reads that are quiet, permanent, and unrecoverable

In plain terms: This backstop is deliberately literal. It is not a security boundary — an agent set on damage has a thousand spellings for rm. It's a "you probably didn't mean to hand this one over unattended" guard for the obvious catastrophes. Real containment is the sandbox and the bot's own computer.

The evidence strip

Before you answer a card, Muster shows how this bot's past went with this tool: how many times it was allowed, denied, or auto-settled, and when the last one was.

# what an evidence strip can say, rendered on the card itself:
Bash was allowed 12× before (last 3h ago) — never denied.
Bash history: 4 allowed, 2 denied (last 5d ago).

History is scoped to the tool family: what this bot did with Bash:git is evidence about a Bash:npm ask, because both are "this bot running shell commands". For non-command tools like Write or browser_click, exact matches count.

Evidence, not a verdict. A passed history only counts what it counted. The summary is rendered server-side so every client says it the same way — and the human still decides.

Budgets and the Privacy Shield

Control isn't only per-action. Every bot carries a per-agent token budget and a per-agent daily USD cap, so a runaway loop stops being your money problem before it starts.

On the privacy side, the on-device Privacy Shield masks emails, phone numbers, and secrets before prompts reach a cloud model — deterministically, with counts-only receipts. You learn the shape of what was redacted without Muster keeping a second copy of the sensitive data.

What stays local

Transcripts, keys, events. They live in ~/.muster on the machine running the server — not in a cloud.
Engine API keys. Provider keys are stored write-only and never echoed by the API. The voice (TTS) key runs on the harness, so it never reaches the UI either.
Your conversations. Thread history sits on your disk. The mobile companions own nothing — your computer stays the source of truth.

Grants work the same way: connected-app access and agent-mail mailboxes are unlocked only by invite links you approve, and inbound agent mail is treated as untrusted data by design.

Claiming a workspace is gated

muster up boots the server and prints a QR code encoding http://<lan-ip>:8799/claim#CODE. Scanning it signs your phone in as the owner — no account creation, no password to invent. The code is the credential, and it's engineered to be worthless to anyone else:

Property	What it means
Single-use	Redeemed once, then dead.
Five-minute TTL	Expired before a stranger could act on it.
Unambiguous alphabet	8 characters, no `0/O/1/I/L` — built to be read off a laptop screen by a phone camera. About 2⁴⁰ of entropy.
Per-IP lockout	Five failed redemption attempts lock that IP out for ten minutes.

The pairing itself never leaves your network. A claim code never redeems as a pairing code or vice versa — the two flows keep separate stores, so one front door can't be confused with the other.

Servers tighten further once exposed. The default is loopback-only: non-loopback hosts and origins are rejected (DNS-rebinding and CSRF protection), and on a desktop install, state-changing requests must carry a same-origin Origin/Host pair. Expose a self-hosted server and every /api/* route requires a session — only sign-in and health checks are excepted — with sign-in rate-limited to five attempts per minute per IP and passwords of at least twelve characters.

Sessions stay revocable: muster sessions lists every active sign-in (current one marked), and muster sessions --revoke kills one device, all the others, or everything.

The layers, in one line

Approval cards are the control layer. The Privacy Shield is the privacy layer. Routines and receipts are the audit layer. For the audit side — recurring bots, sentries, and the why-journal — see Automation. For running the whole server on hardware you own, see Self-hosting.