A permission mode sets the default posture for how an agent's tool calls are resolved. Every call is resolved to allow, ask, or deny before it executes.
The four modes
| Mode | Behaviour |
|---|---|
always_ask | Every tool call requires human approval (read-only built-ins exempt) |
ask_for_actions | Read-only tools run automatically; anything with side effects asks first |
autonomous | Everything runs except an explicit per-tool ask/deny override |
tools_disabled | No tools or skills available to the run at all |
The precedence ladder
Mode is the default, not the final word:
- Per-tool overrides always win. An explicit deny blocks the call; an explicit ask requires approval even in an otherwise fully autonomous agent.
- Read-only built-in platform tools are never gated. They always run.
- A destructive or open-world-acting tool generally requires approval unless the mode or an explicit per-tool allow says otherwise.
- Unrecognised modes or risk classes fail closed to
ask— never silently to allow.
Choosing a mode
Pick autonomous for unattended, scheduled, or agent-to-agent runs. Then use per-tool ask/deny overrides for the specific tools you want gated, rather than dropping the whole agent to always_ask.
That combination — autonomous mode plus targeted overrides — expresses "run freely except for these three dangerous things", which is almost always what production actually needs.
The pitfall
Expecting an ask-gated tool to work on an unattended run. There is no approver present, so it is denied — not silently allowed, and not left pending forever. See fail-closed. Design unattended paths with a non-interactive fallback, or they will simply stop at that tool.