Prompt-based execution mode classifier with safe permission boundaries

[PierrunoYT]

Problem

Zero exposes several useful but separate controls:

• model modes such as smart, deep, and fast;
• execution posture/autonomy levels;
• permission modes such as plan, auto, ask, and unsafe.

Users currently need to understand these distinctions and select them manually before every task. It would be useful to offer an explicit automatic-routing option that inspects the prompt and recommends or selects an appropriate execution mode—for example, read-only planning, autonomous coding inside the sandbox, or approval-gated work.

Proposed behavior

Add an opt-in prompt classifier used only when the user selects an Automatic routing mode. Its result should contain two independent decisions:

1. Execution posture: low, medium, or high effort/turn budget.
2. Permission recommendation:
   • plan for explanation, investigation, and planning requests that should remain read-only;
   • auto for coding tasks that may edit the workspace and run sandboxed commands autonomously while retaining existing risk gates;
   • ask for ambiguous or sensitive tasks where mutating tool calls should require approval.

Explicit user selections must always override classifier output. The selected mode should be visible in the TUI/run metadata, and classification failure should fall back conservatively (for example, ask with medium posture).

Security boundary

Prompt classification must never grant authority:

• The classifier must not select unsafe or activate --skip-permissions-unsafe.
• It must not widen configured tool filters, sandbox policy, MCP grants, filesystem scope, or network access.
• Prompt content should be treated as untrusted routing input; instructions inside the prompt cannot override the classifier contract.
• Existing registry and sandbox checks remain the final authority for every tool call.
• If automatic routing is allowed to change permission mode at all, it should only choose among modes the operator explicitly allowed or reduce authority from the configured ceiling.

This keeps “autonomous coding” bounded to existing workspace/sandbox protections while destructive, networked, elevated, and out-of-workspace operations continue through the normal approval path.

Fit with the current architecture

Zero already centralizes permission modes, tool visibility, runtime permission prompts, and sandbox evaluation. The classifier can remain a small routing layer before the agent loop rather than introducing a second permission system. Model presets should remain separate because they answer which model runs, while the classifier answers how the run should proceed.

Alternatives considered

• Continue requiring manual mode selection: safest and predictable, but adds friction and requires users to understand several orthogonal controls.
• Let the model decide permissions during execution: rejected because prompt/model output must not be an authority source.
• Classify only effort and turn budget: useful, but does not address choosing between read-only, autonomous, and approval-gated workflows.

Open questions

• Should automatic routing apply the safe recommendation immediately, or show it for one-click confirmation before the run?
• Should the first version use deterministic heuristics, a small model call, or a hybrid with conservative fallback?
• Should the operator configure a maximum permission ceiling for automatic routing?