Guardrails and verification

An orchestrator owns the rules its workers run under. It can mark protected config: files a worker is not allowed to edit, so an agent cannot quietly loosen the settings it is working inside. Hook packs are installed into a worker at spawn time, so the checks apply from its first tool call rather than being remembered later. What comes back is scanned for prompt injection and for secrets, because content a worker read from an issue, a page or a dependency is untrusted input. Deny-tier tools are blocked even when the CLI is in always-approve, on Grok, Cursor, Codex, OpenCode, and Muse.

Separately, a thread can carry a verify command. The thread only settles green once that command exits 0; if it fails, the thread stays open with the output attached. It is the difference between an agent saying it is done and the build agreeing. After a PR merges, the same command can run again on a delay (post-merge verification) and reopen the thread if the build regressed.

Governance policies

An agent profile can carry a policy: a default of ask or allow, plus up to 40 rules. Each rule matches a tool, a bash command, a write path or a network target by glob, and blocks, denies, asks or allows. The most severe matching rule wins. A bash rule matches each subcommand, so npm publish also catches cd x && npm publish. A denied call is logged in the transcript with no card; an ask card says which rule raised it. If you edit a command on the card, the edited version is checked again before Allow goes through.

Every decision is written to a signed, chained audit log. Settings, Advanced shows the last 50 entries and a Verify chain button that detects tampering. Secrets are redacted before anything is written. In v1 policies apply to Claude threads, and only to calls the CLI asks about: Accept edits, Full access, and allow lists in your Claude settings skip the check.