Governed command capability matrix

Every ROST command that changes state — through the human app, the CLI, an MCP client, or the in-app AI Chief of Staff — carries the same registry-derived governance classification. This guide answers the question every agent and every human operator eventually asks: what can my agents do right now, and how do I change that? Which commands ask a human every time, which can automate under Trusted mode, and which stay off-limits to automation no matter what.

The full command-by-command table is generated directly from the command registry and lives at docs/reference/governed-command-capability-matrix.md. A drift test keeps it honest: it fails CI the moment the registry changes without the table being regenerated, so the table can never quietly go stale. This guide is the curated companion — read it first to understand the classification scheme, then open the generated table to look up any specific command's exact row.

The four confirmation classes

Every command declares one of four confirmation classes:

• None — no human gate at all. The command runs immediately (for example a status update, a work log entry, or a task creation the acting seat already owns).
• Human required — the durable-change default. The command mints a pending confirmation a human must approve before it takes effect, unless it qualifies for Trusted auto-band execution (below).
• Credential flow — the command routes through the vault-backed credential flow. A raw secret never appears in a prompt, a log, or a CLI argument.
• Dangerous — an irreversible or high-blast-radius action (for example decommissioning an agent) that always asks, with extra confirmation friction.

The Trusted-eligibility classes

Turning on Trusted mode for a seat does not change a command's confirmation class. It changes whether that seat may execute a human_required command's proposal automatically, under a standing authorization a human deliberately established. Every action taken this way is still recorded as its own human-authorized decision — Trusted mode automates the button-press, not the accountability. Every command falls into one of four Trusted-eligibility classes:

• Auto — a small, confirmation-free allowlist of low-risk worker actions (status updates, task creation, work logging, and similar) that already run without a human gate and are safe for a Trusted agent to keep doing unattended.
• Auto-bounded — a human_required command that may auto-execute under Trusted, but only for a narrow, founder-approved bounded sub-case of its input (the five-command auto band, below). Every other input on the same command still mints a normal human confirmation.
• Always ask — a command carrying a protected risk category (credential, spend, external send, production/go-live, destructive, self-approval, or admin) or otherwise gated. Trusted mode never changes this; it always asks a human.
• Not applicable — a discovery or read command with no durable action to automate.

The five-command auto band

Exactly five commands carry an auto band today — a founder-approved, narrow bounded sub-case where a human_required command may auto-execute under a standing Trusted grant on a human-initiated turn. Any input outside the described bound still mints a human confirmation:

1. `agent.update_schedule` (schedule set) — setting or changing a seat's routine schedule. Clearing a schedule is out of band and still asks. 2. `goal.bind_measurable` (informs Signal bind) — binding a Signal in the conservative "informs" role, which never drives goal status. A "drives status" binding is out of band and still asks. 3. `skill.assign_to_seat` (published skill assign) — assigning an already-published, immutable skill version to a seat. A proposed (non-approved) assignment, or a version that does not resolve to a published skill, is out of band and still asks. 4. `friction.resolve` (routine Friction resolve) — resolving a Friction the acting seat already owns within its own member-seat subtree. A Friction outside that subtree, or a turn with no identifiable human initiator, is out of band and still asks. 5. `agent.run_now` (same-seat run now) — re-running the acting seat's own live agent as production_manual. A cross-seat dispatch, where one seat runs a different seat's agent, is out of band and still asks.

Widening this set, or adding a sixth command, is a deliberate founder decision — not something a code change alone can slip in. The registry enforces it: a command cannot carry an auto band unless it is one of these five ids.

The always-human floor

A command carrying any of these risk categories always asks a human, even under Trusted mode: credential handling, spend or billing changes, external sends (invitations, outbound messages), production or go-live actions, destructive actions, self-approval of your own confirmation, or an admin-scope change. No autonomy setting removes this floor. It is a deliberate, conservative-by-default boundary — see confirmations-guide for how human gates work end to end.

Where to look up a specific command

• The generated, authoritative table: docs/reference/governed-command-capability-matrix.md — one row per command with its required scope, confirmation class, Trusted mode, autonomy class, auto-band class (when it has one), MCP exposure, CLI availability, and whether the AI Chief of Staff can reach it as a governed tool call.
• A single command's exact schema and classification: rost command schema <id> (CLI) or rost_describe_command (MCP).
• How pending confirmations are approved or rejected: confirmations-guide.
• How Trusted grants are created, inspected, and revoked: agent-staffing-playbook.