Permissions and approvals

Every tool call a sub-agent wants to make is resolved to an outcome: allow, ask-a-human, or deny, before it runs.

The precedence ladder

• Per-tool overrides always win: An explicit deny always blocks the call; an explicit ask always requires human 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 overall agent mode or an explicit per-tool allow says otherwise.
• Unrecognized modes or risk classes fail closed to the most conservative option (ask), never silently to allow.

Non-interactive behavior

A run with no human available to answer an approval request (such as an automated schedule, or an agent-to-agent hop with nobody watching) converts every would-be "ask" into an automatic deny instead of blocking forever or silently proceeding.

(Note: What is available as a permission mode vs. how the host resolves it depends on the platform's authentication and approval-gateway configuration.)

Permission modes

Authoring implications

• Pick autonomous for unattended, scheduled, or agent-to-agent runs. Anything that would require human approval is simply denied instead of hanging, so design those paths with a non-interactive fallback.
• Use a per-tool ask/deny override for the specific tools you want gated even in an otherwise autonomous agent, rather than dropping the whole agent to always_ask.