Reference · 3 min read

Permissions taxonomy

How workspace trust and steering modes combine to decide what the agent may read, write, and run — plus per-tool overrides and the session audit trail.

Product stage: Pre-release development
Last reviewed: 2026-07-23
Successful result: The change is visible in the active project.

Who this is for: anyone configuring workspace safety beyond picking a single steering mode.

Miton gates agent actions with two layers:

Workspace trust — per folder; set when you open a project
Steering mode — per chat session; see permission modes

Trust is the outer boundary. Mode is the inner policy. The stricter of the two wins.

Workspace trust levels

Set trust when you open a folder, or change it from the trust indicator in the title bar.

Trust	Plain English	Typical use
Trusted	Read, write, shell, and plugins allowed (mode still applies)	Your own projects
Restricted	Read and language-server only — no writes, shell, or plugins	Default for new folders
Untrusted	Read and language-server only; safest option	Cloned or unknown third-party code

Trust persists for that folder until you change it.

Steering modes (session)

Mode	Summary
Chat	Read-only
Plan	Read-only, planning prompts
Confirm	Ask before writes and shell/network
Autoedit	Auto write; ask before shell/network
Full access	Auto-all within trust gates

Full detail: permission modes.

How trust and mode compose

For each capability (read file, write file, run shell, load plugin, etc.):

Trust denies → action blocked, regardless of mode
Trust allows, mode asks → approval prompt in chat
Trust allows, mode allows → action proceeds without prompt

Example: Confirm mode in a Restricted workspace can read files but cannot write or run shell commands — restricted trust blocks those even though Confirm would only ask.

Trust cannot be overridden by a permissive mode.

Per-tool overrides (advanced)

In Settings you can pin individual tools to allow, ask, or block for a workspace. A per-tool rule beats the trust × mode table for that tool only.

Common uses:

Always allow read in a documentation-only repo
Always block bash in a sensitive folder

Per-surface overrides (advanced)

You can set different policies per surface (for example stricter in Writer, looser in Code) when your workflow needs it. Surface policy layers on top of trust and mode the same way per-tool rules do.

Audit trail

Every tool call is recorded in session metadata:

Tool name, input, output, and result status (allowed, gated, blocked)
Trust level and mode at call time
Any per-tool or per-surface override in effect

The trail lives for the session lifetime. Export the session to JSON if you need an external record.

Global defaults

Settings → Permissions → Global policy sets the default trust for new workspaces. Individual folders keep their own trust once set.

What the permission system does not cover

Cross-machine sync — trust and overrides are local
Inherited child folders — each workspace path has its own policy
Time-based schedules — use Automation workflows if you need timed policy changes