---
title: Permissions and approvals
group: Use Escanor
order: 6
summary: How provider permissions, automation policy, desktop capabilities and machine session modes limit what the assistant and your agents can do.
updated: 2026-10-07
---
Escanor has several permission layers. A provider's OAuth scope, a workspace role, an automation decision, a desktop capability switch and a Claude Code session mode do different jobs. An approval in one layer does not grant access through every other layer.

## Before granting access

Connect only services you can administer. Start with a test project and a read-only request. Check the active workspace, the provider account and the target environment. A successful read verifies connectivity; it does not prove that a write is authorized or safe.

For example, ask the assistant: “List the last three deployments for the staging project. Do not redeploy or change anything.” Compare its answer with the provider's dashboard before moving to changes.

## Provider and MCP permissions

Provider permissions control which resources a stored connection can reach. Escanor MCP uses the workspace's connection for supported providers. A missing scope or restricted provider project remains restricted even if the agent has an MCP key.

OIDC separates `mcp:read` from `mcp:invoke`. Read access can list descriptions without granting invocation. The MCP gateway also supports read-only tokens and limited allowed-write policies. The gateway does not treat unknown operations as reads. Some destructive provider operations require `confirm=true` in their arguments; inspect the tool schema and intended resource before supplying it.

Confirmation is an argument in the tool request. It does not prove that a human reviewed the change, and it does not replace workspace or provider authorization. See [MCP](/docs/mcp).

## Automations

Open **Automations > Settings** to review enabled state, autonomy rules, verification, notifications and budgets. **Runs** records the steps and pending decisions. An owner or manager can approve, deny or stop a run according to the controls the page exposes.

Check the proposed action, target and evidence. An assistant summary can be incomplete. Approve one bounded change, then inspect the provider result and health check. A run waiting for approval has not hung. Use **Stop everything now** to pause automation when scope is unclear; inspect in-progress work before resuming.

## Desktop capabilities

The desktop app registers each operation by group and risk (`read`, `write`, `destructive`). Phones have shell, file, app-install, background-job and OS-control groups disabled by default. Voice and agent callers have their own defaults. Enabling a group permits that caller to request its operations; destructive actions still require approval.

You approve pairing and capability escalation on the computer. A phone cannot grant itself those permissions. If an approval is required but there is no approver, the registry denies the operation. Review denied outcomes in the computer's audit view instead of repeating the same request.

## Machine session modes

Machines run Claude Code under their session mode and managed policy. Start with default or plan mode. Modes such as bypass reduce prompts; choose them deliberately, for an isolated environment. They do not fix an expired account, offline agent or invalid provider credential.

The project root keeps sessions working in one folder, but it does not isolate them from the rest of the system. Use an unprivileged service account and limit filesystem/provider access independently. See [Connect a VM](/docs/connect-a-vm).

## Recovery and audit

| Outcome | Next step |
|---|---|
| Provider says forbidden | Check account, project and OAuth scopes at the provider. |
| Computer group disabled | Review the relevant switch on the computer; ask its owner. |
| Waiting for approval | Open the pending decision and inspect the exact action. |
| Approval denied | Revise scope or stop; do not silently retry with broader credentials. |
| Request timed out | Inspect activity/provider state before retrying a write. |

Audit views help explain what happened. They do not guarantee that every external action was captured or that its effects can be undone. Export only what is needed and redact credentials or personal data. Related: [Automations](/docs/automations), [Security and privacy](/docs/security-privacy).
