Permissions and approvals

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.

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.

Recovery and audit#

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, Security and privacy.