Permissions
Tools declare capabilities, and a permission policy resolves a level for each call:
- Always: execute without prompting.
- Ask: prompt the user for approval.
- Never: block entirely; the tool is hidden from the agent, which doesn't know it exists.
Grants hierarchy
Permissions operate at three levels:
- Default grants: each tool ships with a default based on its risk profile (see boundaries below).
- Agent grants: the user overrides defaults per-agent in the permissions menu; these persist across chats.
- Chat grants: during a chat, "allow for this chat" avoids repeated prompts for a tool used frequently in one conversation.
Permission boundaries
Three boundaries set the default level:
- Read vs write: read-only tools (reading core docs, searching knowledge, getting time/location) default to always. Anything that modifies state (editing core docs, deleting knowledge, creating spaces) defaults to ask.
- Internal vs external: external tools (web search, web fetch, MCP servers) default to ask even for reads, because external data carries prompt-injection risk.
- User availability: the system knows whether the user can be prompted. In text chat, prompts show inline. In a live call, the phone may be in a pocket, so when prompting is unavailable and a tool needs permission, it's denied by default; the agent is told and can ask the user to open the app.
Setup conversations may use a restricted or customised tool set. During live calls, ask-level tools are blocked because the UI can't show prompts on the lock screen.