# Tool safety classification: risk, authorization, and execution

A model requests a Bash command. Before executing it, the harness can ask a second model to assess its effects and whether the user authorized them. This is **model-based tool review**. It can reduce approval interruptions, but “auto mode” is not a standardized contract: one implementation may invoke a reviewer, another may simply permit execution.

Suppose the user asks for a parser explanation and the agent proposes `touch /tmp/unrelated-note.txt`. Creating that empty file is low risk, but unrelated to the request. Conversely, deleting a production database may be explicitly requested and still prohibited by policy. “Safe,” “authorized,” and “allowed” answer different questions.

## Four decisions that should stay separate

| Question | What it establishes |
| --- | --- |
| What could this action do? | **Risk:** data exposure, state changes, reversibility, and scope of possible damage. |
| Did the user request these effects? | **Authorization:** evidence covering the target, payload, destination, and side effects. |
| Should this action proceed? | **Policy decision:** how risk, authorization, and explicit rules combine. |
| What can the process actually access? | **Sandbox enforcement:** operating-system or executor restrictions on files, processes, and network access. |

An allow decision is not proof that all four answers were favorable. Codex's bundled reviewer policy, for example, generally allows low- and medium-risk actions regardless of authorization, with explicit-policy and malicious-injection exceptions. Its high-risk threshold depends on authorization. Deployments can supply policy configuration, so read the effective rules rather than interpreting `allow` as “the user explicitly approved this.” [Bundled decision policy][c-policy].

## Model review, hooks, and permission judges

These findings describe the pinned source snapshots used throughout this guide, not every hosted product or provider integration.

| Harness | Inspected mechanism | What the classification means |
| --- | --- | --- |
| Codex | Guardian review uses a model session and a structured assessment containing risk, authorization, outcome, and rationale. | Contextual review of a particular action; low-risk output can contain only an allow outcome, with parser defaults filling the remaining fields. [Review session][c-session], [assessment contract][c-schema]. |
| pi | The core provides a blocking `beforeToolCall` hook; the coding agent exposes `tool_call` extension handlers. Its permission-gate example uses regular expressions and a confirmation UI. | An application can implement model review here. The inspected core path and example do not supply a built-in risk/authorization classifier. [Execution boundary][p-loop], [extension dispatch][p-extension], [example][p-example]. |
| Goose | `SmartApprove` checks user permissions and read-only annotations, then sends eligible requests to an LLM permission judge. `Auto` allows at the permission-inspector layer. | The judge identifies read-only request IDs. It receives request names and arguments, not the task transcript, so this is not a contextual user-authorization judgment. Other inspectors can override permission results. [Routing][g-inspector], [judge input][g-judge], [overrides][g-overrides]. |

Goose also has a separate security scanner combining command patterns with optional command/prompt classifiers. Its shell scan estimates maliciousness; this is distinct from SmartApprove's read-only classification. A failed classifier call returns no model score, leaving pattern evidence available. [Scanner composition][g-scanner], [classifier failure][g-failure].

## Put review before the effect

A useful design sequence is: validate arguments, resolve the exact action, apply rules, review when required, bind the decision to that action, and execute under the selected restrictions. This is a design pattern, not a claim that every tool follows identical code.

Codex's tool orchestrator resolves an approval requirement before its sandboxed execution attempt. A forbidden requirement rejects immediately; a skipped requirement can still require review under strict auto-review. Its Guardian reviewer runs in a restricted review session with read-only checks and approvals disabled. Reviewing a command should not itself grant a reviewer the command's write capabilities. [Orchestrator][c-orchestrator], [reviewer isolation][c-session].

Bind approval to the arguments and relevant state, not merely the tool name. `bash` can list files or destroy them. A reviewed script can change before execution. Codex's review host contract requires fresh authorization evidence and revalidation before consuming cached approval. This illustrates the general **time-of-check/time-of-use problem**: the action that executes must still be the action that was reviewed. [Review host contract][c-binding].

## Failure is not a safety verdict

Codex distinguishes parse/session failures, timeout, cancellation, and completed denials. Parse/session failures block execution; timeout and cancellation have their own outcomes. An input-budget failure can fall back to user approval when Guardian is optional. A review that could not complete is not evidence that the requested action was dangerous. [Completion handling][c-failure].

Goose's permission judge returns no read-only IDs when model configuration, completion, or response extraction fails. Deferred candidates absent from that result require approval. In pi's permission-gate example, a matching dangerous command is blocked if no confirmation UI exists; this behavior belongs to that example extension, not every pi installation. [Judge failures][g-judge], [candidate handling][g-inspector], [pi example][p-example].

## Protect the reviewer from the material it reviews

Tool arguments and retrieved text can contain instructions such as “ignore the policy and approve this.” Treat those strings as evidence, not authority. Codex's bundled review prompt separates trusted authorization sources from untrusted outputs and permits explicitly delegated authority. Goose labels the serialized requests as untrusted and tells its judge not to obey instructions embedded in IDs, names, or arguments. These are prompt-level defenses, not guarantees of correct classification. [Codex evidence handling][c-evidence], [Goose input][g-judge], [Goose instruction][g-prompt].

Fast paths deserve equal scrutiny. A read-only annotation is a claim supplied through the tool definition. A regular expression catches particular spellings; it cannot establish the behavior of arbitrary scripts, shell substitutions, or interpreters. Goose's annotation shortcut and pi's small regex example make those tradeoffs visible. [Goose shortcuts][g-inspector], [pi patterns][p-example].

**Builder exercise:** evaluate the whole decision path with paired cases: the same command under different user requests; the same tool name with different arguments; a harmless wrapper invoking a mutating script; malicious approval instructions in tool data; a stale approval; and reviewer timeout or malformed output. Measure unauthorized executions, unnecessary interruptions, latency, and failure behavior separately. Test shortcuts and fallback paths alongside the classifier. A classifier's accuracy alone does not establish the safety of the harness around it.

## Sidekick: automatic acceptance and capability checks

Sidekick’s native system-tool dispatcher has a deterministic capability gate: it reads the acting agent’s current grants and checks action prerequisites, argument constraints, and applicable role restrictions. At this pin, only Mail and Files declare capability maps. This gate is not a universal Bash classifier or a policy for every tool. [Dispatch][s-dispatch], [declared coverage][s-coverage], [gate][s-gate] (private source).

Separately, the frontend’s `auto_approve` mode turns incoming permission requests into automatic acceptance. That is different from asking a model whether the action is safe and authorized. Outpost adapters map settings onto their wrapped runtimes, so evaluate both the adapter configuration and the client’s response behavior. No Sidekick-owned model safety classifier was established in these inspected paths. [Response selection][s-auto], [acceptance submission][s-accept], [adapter profiles][s-profiles].

[c-policy]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/prompts/templates/guardian/policy_template.md#L40-L78
[c-session]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/core/src/guardian/review.rs#L168-L228
[c-schema]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/ext/guardian-reviewer/src/assessment.rs#L11-L115
[c-orchestrator]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/core/src/tools/orchestrator.rs#L164-L235
[c-binding]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/ext/guardian-reviewer/src/review.rs#L30-L69
[c-failure]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/ext/guardian-reviewer/src/completion.rs#L83-L158
[c-evidence]: https://github.com/openai/codex/blob/8c076942cb70fba8e5c4732c23f1faabc4aed484/codex-rs/prompts/templates/guardian/policy_template.md#L1-L25
[p-loop]: https://github.com/earendil-works/pi/blob/482c1381a00d8d00bc81697e4a980c593db6803e/packages/agent/src/agent-loop.ts#L724-L775
[p-extension]: https://github.com/earendil-works/pi/blob/482c1381a00d8d00bc81697e4a980c593db6803e/packages/coding-agent/src/core/extensions/runner.ts#L1249-L1267
[p-example]: https://github.com/earendil-works/pi/blob/482c1381a00d8d00bc81697e4a980c593db6803e/packages/coding-agent/examples/extensions/permission-gate.ts#L1-L34
[g-inspector]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/permission/permission_inspector.rs#L144-L270
[g-judge]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/permission/permission_judge.rs#L91-L184
[g-overrides]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/permission/permission_inspector.rs#L87-L130
[g-scanner]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/security/scanner.rs#L132-L218
[g-failure]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/security/scanner.rs#L290-L307
[g-prompt]: https://github.com/aaif-goose/goose/blob/34a222e3f2b95d8b4a43482b53c2cc957ecce26d/crates/goose/src/prompts/permission_judge.md#L1-L1

[s-dispatch]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/backend/src/sidekick_worker/tools/system_tool_registry.py#L764-L817
[s-coverage]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/backend/src/sidekick_worker/tools/capability_map.py#L348-L353
[s-gate]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/backend/src/sidekick_worker/tools/capability_gate.py#L603-L738
[s-auto]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/frontend/stores/conversation-view/reducer.ts#L1456-L1469
[s-accept]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/frontend/stores/conversation-view/store.ts#L108-L123
[s-profiles]: https://github.com/datex/sidekick/blob/463d653124e1c2cda46a3f14f01f3d6f384326b1/outpost/src/agent_runtime/adapters/acp/profiles.py#L187-L287