Safety and Human in the Loop

Safety is the reason Fisk AI exists. Two ideas carry it: a command runs with no shell and no credentials so it is bounded by construction, and a tagged command can require a human to approve it before it runs. Both default to the safe outcome.

A command is sandboxed by construction

When the loop runs a tool, Tool.Execute passes an argument vector to exec.CommandContext. No shell is involved, so model-supplied arguments can never be interpreted as shell syntax; t.Model.ArgsFromJSON is the trust boundary that bounds input to the command’s schema. The child gets no stdin, a ten-second wait delay after cancellation, an environment with credentials stripped, and its combined output capped.

commandEnv removes five secret-bearing variables so a model-chosen command can never read the agent’s own credentials: ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_IDENTITY_TOKEN, ANTHROPIC_WEBHOOK_SIGNING_KEY, and ANTHROPIC_CUSTOM_HEADERS (fisk.go:511). It appends LLMFORMAT=1 so a fisk application can render output suited to a model rather than a terminal. Output is capped at 64 KiB, keeping the head and tail with a truncation marker, so a chatty command cannot flood the model’s context.

Two ways to put a human in the loop

The two mechanisms are distinct and address different needs.

ai:confirm

An application author gates a specific command. The operator must approve it before it runs; the command itself is unchanged. Always active, no configuration flag.

human_in_the_loop

A configuration flag that gives the model three `ask_human_*` tools so it can ask the operator a question it chose to ask.

Reach for ai:confirm when a normal command should run only with the operator’s say-so. Reach for human_in_the_loop when the model should decide when to check in. The harness.confirm_tags key extends the gate to any tag an application already uses, for example impact:rw.

The confirm gate defaults to deny

When the model calls a gated command, the gate runs the checks in a fixed order, and every failure is a denial.

1. Missing parameters first A structurally invalid call is rejected before the gate, so the operator is never asked to approve a broken command (`runner.go:608`).
2. Session-allow short-circuit If the operator earlier chose "allow for the session" for this command, it runs without asking again.
3. No terminal, no run Without an interactive terminal, or with a canceled context, the gate denies before any prompt is shown (`confirm.go:76`).
4. Prompt the operator The sanitized full command line is shown. Any prompter error, an interrupt, an end-of-input, or an Escape, is a denial.

A denial is returned to the model as an authoritative, non-error result whose reason ends with a note not to retry, so the model reasons about the refusal rather than routing around a tool failure. An “allow for the session” answer is remembered by command name, regardless of arguments, and lasts only for that run.

The ask_human tools

When human_in_the_loop is enabled the model gets three tools: ask_human_confirm (yes or no), ask_human_select (choose one option), and ask_human_input (a free-text value). Each denies by default: a missing terminal, an interrupt, or an end-of-input yields a negative answer rather than a guess. Each renders on stderr so a piped final answer stays clean, and the model-supplied text is stripped of terminal control sequences first, before any truncation, so a cut can never leave a dangling escape.