Fleet commands

Fleet operations let you run a single command across many selected hosts in one pass, with a preview and approval gate before anything executes and a per-host result afterward. It is a Team-and-above capability built on the brokered SSH path, so each host still authenticates with its own vault credential and every execution is audited.

Plan, then execute

Fleet runs are two explicit steps so nothing executes by surprise:

1. Plan. Select the connections to target and supply either an explicit command or a natural-language intent. VaultTerm resolves the command, classifies its risk, and saves a locked plan with one pending target per host. Nothing runs yet.
2. Execute. You approve the previewed plan explicitly. The locked command fans out concurrently across exactly that host set, each host’s result is recorded, and the run rolls up to completed, partial, or failed.

The command is locked at plan time, so execute approves precisely the command and host set you reviewed.

Natural-language to command (AI-assisted)

Instead of writing the command yourself, you can describe what you want and have it parsed into a command. The model only proposes the command — it never decides whether the command is safe. Risk classification is deterministic and separate, so no text injected into the description can downgrade the gate. The intent is scanned for injection and exfiltration before it reaches the model; an attempt to exfiltrate secrets is blocked and audited. Generation defaults to the self-hosted LAN model and reaches cloud only when the org has opted in. See Privacy-first AI.

You can always pass an explicit command instead, with no model involved.

Per-host preview and approval gate

Every plan shows the resolved command, a plain summary of what it does, its safety and risk classification, and the full list of target hosts with their login users — each starting as pending. Execution does not begin until you confirm. A target whose connection or credential has vanished by execution time is skipped, not run with the wrong context.

Risk-gated step-up

A high-risk fleet command requires a fresh WebAuthn step-up before it will execute — proven presence, not a self-declared flag. The block is audited if step-up is missing. This pairs with just-in-time access so a broad, risky action across many hosts can’t proceed on an ordinary session alone.

Per-host results, fully tracked

Each host is tracked independently. For every target you get its final status, exit code, and a truncated output excerpt, plus any error. The run as a whole records how many hosts succeeded, failed, or were skipped, and the rollup status reflects the worst outcome — so a partial failure is visible, not hidden behind an overall “done.” Planning the run, each host’s execution, and the run’s completion are all written to the audit trail.

Where to go next

• JIT access — scoped, just-in-time elevation for risky actions.
• AI overview — how natural-language assistance stays privacy-first.
• Session recording — capture and replay what ran.