Factory.ai Logo

Autonomy Level

Choose Off, Low, Medium, or High to control what Droid can do without repeated confirmations.

Autonomy Level sets the highest-risk work Droid can run without pausing for approval. It is separate from interaction mode: Normal Mode executes work, while Spec Mode plans before implementation.

Choose a level

Execute commands and MCP tools have a risk level (low, medium, or high). For shell commands, permission rules can allow execution, require approval, or block execution before autonomy fallback. Commands with no policy match run automatically when their risk is at or below your Autonomy Level. Sandbox checks can require separate approval.

Autonomy LevelWhat can run without approvalExamples
OffBuilt-in read tools and commands allowed by policyRead, LS, ls, pwd, git status
LowFile edits plus low-risk commands and MCP toolsEdit, Create, rg, showing logs
MediumEverything from Low plus reversible workspace changesnpm install, pip install, git commit, mv, cp, build tooling
HighHigh-risk actions unless safety checks require approvaldocker compose up, git push if allowed, migrations, custom scripts

Droid still streams output and highlights file changes at every level.

How approvals work

Autonomy Level controls automatic approval, not which tools are available. Tool policy, MCP configuration, model support, and organization controls can still restrict tools.

  • Normal vs. Spec Mode: In Normal Mode, Autonomy Level controls approvals. Spec Mode is read-only planning; after approval, Droid exits Spec Mode and returns to Normal Mode for implementation.
  • File changes: Low or higher lets Droid create, edit, and patch files without asking first.
  • Commands and MCP tools: Droid compares the tool risk level to your Autonomy Level. If the risk is higher, it asks before continuing.
  • Command policy: An effective allow skips command approval, ask requires it even at High, and block rejects the command with no approval path. Deprecated command lists still participate for backward compatibility.
  • Safety checks: Built-in runtime safeguards can require approval for recognized destructive operations. Sandbox read, write, and network checks can also prompt separately. An allow rule grants permission; it does not prove a command is read-only.
  • Allow always: Choosing an "always allow" option raises the current Autonomy Level to the level required by that prompt. Sandbox "allow always" options instead persist the allowed path or domain.
  • Spec approval: When approving a Spec Mode plan, choose Proceed with implementation to continue with manual approvals, or choose an available Low, Medium, or High option for implementation. Organization Maximum Autonomy Level can hide higher options.

Permission rules

Use permissionRules in Settings for new command policy. Rules match exact, ordered command arguments and include positive and negative examples. See Permission rules to create, test, and preview them.

After rule IDs are resolved across settings sources, matching blocks take precedence over requests for approval, which take precedence over allows. Commands with no match fall back to session approvals and the active Autonomy Level. Organization and project definitions with the same ID follow rule source precedence.

--skip-permissions-unsafe skips all permission prompts, but command blocks still apply.

Command allowlists, denylists, and blocklists

commandAllowlist, commandDenylist, and commandBlocklist are deprecated, not removed. Existing lists remain respected for backward compatibility. Use permissionRules for new configuration; immediate migration is not required.

The replacement decisions are allow, ask, and block, respectively. A native rule can replace a custom legacy restriction from the same settings source, while restrictions from other sources remain effective. Review migration and coexistence before changing existing policy.

Warning

Command rules are not operating-system isolation. Prefixes do not cover every equivalent command spelling or inspect arbitrary script behavior. Use sandboxing, managed hooks, and least-privilege credentials for additional protection.

Change the level

  • Press Ctrl+L to cycle Off → Low → Medium → High → Off. Organization policy can cap the highest available level.
  • Press Shift+Tab to switch between Normal Mode and Spec Mode.
  • Set a default in /settings for future sessions.
  • Change Autonomy Level before implementation, from the Spec Mode approval dialog, or any time after leaving Spec Mode.

Where Autonomy Level applies

  • Interactive CLI: droid uses the session's current Autonomy Level. droid "<prompt>" starts the same interactive CLI with an initial prompt, so the first task uses your configured default. See the CLI reference.
  • Factory App: Factory App sessions use the same Normal, Spec, Mission, and Autonomy Level controls as CLI sessions.
  • Droid Exec: droid exec is read-only by default. Use --auto low, --auto medium, or --auto high for non-interactive runs that need edits, local development commands, or broader automation. See Droid Exec.
  • Custom Droids (Subagents): Task-launched subagents inherit the parent session's Autonomy Level by default, or use the Subagent autonomy level setting (inherit, off, low, medium, high) when configured, always clamped to the organization's Maximum Autonomy Level. In Spec Mode they are read-only. Organization and Droid tool policy can still restrict them. See Custom Droids.
  • Factory Missions: Missions orchestration requires High autonomy or --skip-permissions-unsafe (unsafe: skips permission prompts, but not effective command blocks; use only in isolated sandboxes), and admins can restrict who can start Missions. See Factory Missions.

Enterprise Controls

Enterprise admins can set organization-wide autonomy boundaries with organization-managed settings. See Enterprise Controls & Managed Settings.

  • Default Autonomy Level sets the starting level for new sessions.
  • Maximum Autonomy Level caps how high members can raise autonomy. If the maximum is Medium, High is unavailable in the CLI.

These controls layer with permission rules, legacy command lists, MCP restrictions, sandbox settings, and Missions access controls.

Use it safely

  • Start new or high-stakes work with Off or Low until you trust the plan.
  • Match the minimum level to the work: use Low for file edits and generated reports, Medium when the run must install dependencies, build, test, or make local commits, and High for pushes, deployments, Task-launched subagents, Missions, or other orchestration.
  • Add defense in depth with blocking hooks, permission rules, MCP restrictions, least-privilege credentials, and isolated runners.
  • For CI workflows, choose the lowest droid exec --auto level that allows the workflow to complete. See Automated Code Review and Droid Exec.
  • If you spot a suspect command, interrupt, provide guidance, and resume at the Autonomy Level that fits the remaining risk.

Related resources

Interaction Modes

Understand Normal, Spec, and Mission Mode and how they relate to autonomy.

Hooks

Enforce deterministic policy and validation at every tool call.

Permission rules

Define and test command approval policy.

Sandbox

Add filesystem and network isolation.